Size and estimate costs for Azure Cache for Redis across Basic, Standard, Premium, and Enterprise tiers with sharding support.
Last verified: May 2026
Standard Tier Features
| Tier | SLA | Max Memory | Replication | Clustering | Persistence | Geo-Repl. | Price Range |
|---|---|---|---|---|---|---|---|
| Basic | None | 53 GB | No | No | No | No | $16–$799/mo |
| Standard | 99.9% | 53 GB | Yes | No | No | No | $20–$1,183/mo |
| Premium | 99.9% | 1.2 TB (10 shards) | Yes | Up to 10 shards | RDB / AOF | Active-passive | $404–$64,707/mo |
| Enterprise | 99.999% | 100 GB | Yes | Built-in | Yes | Active-active | $681–$4,925/mo |
| Enterprise Flash | 99.999% | 1.4 TB | Yes | Built-in | Yes | Active-active | $3,346–$11,117/mo |
The Premium tier is built on open-source Redis and supports clustering via hash-slot sharding (up to 10 shards), VNet isolation, active-passive geo-replication, and RDB/AOF persistence. The Enterprise tier is powered by Redis Ltd.'s Redis Enterprise and includes active-active geo-replication, built-in Redis modules (RediSearch, RedisJSON, RedisBloom, RedisTimeSeries), and a 99.999% SLA with zone redundancy.
Premium-tier clustering partitions your keyspace across multiple shards using CRC16 hash slots (16,384 total). Each shard is a primary/replica pair. Adding shards scales both memory and throughput linearly. Cost is multiplied by the shard count. For example, a P2 (13 GB) with 5 shards provides 65 GB usable memory at 5× the P2 price.
RDB (snapshot): Periodic point-in-time snapshots written to Azure Storage. Lower performance impact but potential data loss between snapshots. AOF (append-only file): Logs every write operation. Higher durability (minimal data loss) but more I/O overhead. Both options are available on Premium and Enterprise tiers.
Active-passive (Premium): One-way replication from a primary cache to a secondary cache in another region. Manual failover required. Active-active (Enterprise): Multi-region read/write with conflict-free replicated data types (CRDTs). Automatic conflict resolution and near-zero RPO.
Enterprise Flash uses a combination of DRAM and NVMe flash storage to offer large cache sizes (up to 1.4 TB) at a lower cost per GB than pure in-memory tiers. Ideal for workloads with large datasets where sub-millisecond latency is not critical for every operation. Hot data stays in DRAM while warm data is on flash.
All prices shown are for the East US region and represent list (pay-as-you-go) pricing. Actual costs may vary by region. Reserved pricing (1-year or 3-year) can save 30–55% on Premium and Enterprise tiers. Data transfer and storage for persistence are billed separately.
The sizer takes your inputs (memory needed, expected throughput, connection count, HA requirements) and matches them to the smallest Azure Redis tier+SKU that meets all requirements. It costs out by tier (Basic single-node, Standard primary+replica, Premium with shard count, Enterprise/Enterprise Flash) and applies multipliers for clustering shards, geo-replication, and zone redundancy.
The Azure Redis Cache Sizer helps you select the right Azure Cache for Redis tier and configuration based on your performance, capacity, and high availability requirements. It covers Basic, Standard, Premium, and Enterprise tiers with options for clustering, sharding, geo-replication, and data persistence. Enter your expected memory requirement, connection count, and throughput needs to get tier recommendations and monthly cost estimates. The tool also helps you understand the tradeoffs between single-node Basic for development, replicated Standard for production, and Premium or Enterprise for advanced features like VNet injection, active geo-replication, and Redis Modules.
Your team is sizing Redis for a session store across 50,000 concurrent users averaging 4 KB per session = ~200 MB working set. The sizer recommends Standard C1 (1 GB, ~$80/month) with 4x headroom for growth. You initially considered Premium P1 (6 GB, ~$420/month) for VNet integration, but realize the session store doesn't need VNet isolation — public endpoint with TLS + access keys is fine for non-PII session data. You save $340/month by starting at Standard and scaling to Premium only if requirements change.
Basic tier has no SLA and a single-node deployment. A reboot, patching event, or hardware failure means full cache loss with no failover. Anything writing to Basic-tier Redis for production state will eventually have an incident — always start at Standard for any user-facing workload.
Premium tier's data persistence (RDB or AOF) does NOT eliminate the need for application-level backups. RDB snapshots are point-in-time and AOF can be corrupted by abnormal shutdowns. If your cache is also your source of truth (which it shouldn't be), you need a real backup strategy regardless of tier.
Enterprise tier offers active-active geo-replication across multiple Azure regions, which Premium does not. For globally distributed apps where every region must be able to write, Enterprise is the only option — and it's significantly more expensive than the equivalent Premium SKU.
Premium tier is needed when you require data persistence (AOF or RDB snapshots), Redis clustering for more than 53 GB of data, VNet integration for network isolation, or zone redundancy. Standard tier provides a replicated cache with an SLA but lacks these advanced features.
Sharding splits your data across multiple Redis nodes (up to 10 shards in Premium, more in Enterprise). Each shard is a primary-replica pair. More shards increase aggregate memory, throughput, and connection limits linearly. The sizer calculates the total cost based on your shard count and cache size.
Enterprise tier uses all DRAM for maximum performance. Enterprise Flash uses a combination of DRAM and NVMe flash storage, offering up to 2x the capacity at a lower per-GB cost with slightly higher latency. Flash is ideal for large datasets where sub-millisecond latency is not required for every operation.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.