Azure Managed Redis and Caching Patterns

Caching improves performance and scalability by keeping frequently accessed data in fast storage close to the application. It's most effective when a client repeatedly reads the same data, especially where the original store is relatively static, heavily contended, or far enough away that network latency makes access slow.

Redis is how you do that on Azure — but which Redis has changed. Azure Cache for Redis is being retired, and a design started today should target Azure Managed Redis instead. That reframing runs through everything below.

The retirement, and what to design against instead

Azure Cache for Redis has announced a retirement timeline for all SKUs:

Tier	Retires	Instances disabled
Enterprise and Enterprise Flash	31 March 2027	1 April 2027
Basic, Standard, and Premium	30 September 2028	1 October 2028

Microsoft's recommendation is to migrate now rather than waiting for the deadline.

Azure Managed Redis is built on Redis Enterprise software rather than a fork of Redis OSS, supports Redis 7.4.x, and can be deployed standalone or alongside Azure Container Apps, App Service, Functions, Azure SQL, or Cosmos DB. Any application inside or outside Azure can use it.

For a migration, the practical shape is: mostly a hostname and credential change, but client libraries need configuring for a clustered instance, and cross-slot commands are the one category of application code likely to break. That's the work to budget for.

The four Azure Managed Redis tiers

Three tiers hold data in memory, differentiated by their memory-to-vCPU ratio:

Tier	Memory:vCPU	Size range	Best for
Memory Optimized	8:1	12–1,920 GB	Memory-intensive workloads not needing peak throughput; a lower price point, and a good fit for dev and test
Balanced	4:1	0.5–960 GB	Standard workloads — a healthy balance of memory and compute
Compute Optimized	2:1	3–720 GB	Performance-intensive workloads requiring maximum throughput

The fourth stores data on disk as well as in memory:

Flash Optimized (250–4,500 GB) lets Redis clusters automatically move less frequently accessed data from RAM to NVMe storage. That reduces memory use and cost for large datasets, at some performance cost. Two things to be clear about: storing data on disk this way doesn't increase resiliency, and it's distinct from the data persistence feature, which keeps an on-disk backup copy for recovery after an outage and is available on every tier.

What each tier supports

All four tiers carry an SLA, encryption in transit via private endpoint, replication and failover, network isolation, Microsoft Entra ID authentication, scaling, data persistence, connection audit logs, and import/export. The differences that matter:

Feature	Memory Opt.	Balanced	Compute Opt.	Flash Opt.
Active geo-replication	Yes	Yes	Yes	No
Non-clustered instances	Yes	Yes	Yes	No
Search, including vector search	Yes	Yes	Yes	No
JSON	Yes	Yes	Yes	Yes
Bloom, TimeSeries	Yes	Yes	Yes	No

Two caveats worth carrying: the Balanced B0 and B1 SKUs don't support active geo-replication, and scaling down is limited in some situations — plan capacity with that asymmetry in mind rather than assuming you can walk a tier back.

Instances over 350 GB are currently in preview across the in-memory tiers, as are Flash Optimized A2000 and A4500.

High availability

With high availability enabled, an instance is deployed with primary and replica shards distributed across at least two nodes. In regions supporting availability zones, Azure Managed Redis distributes nodes across zones by default — a meaningful change from the older service, where zone redundancy was a Premium-and-above feature you opted into.

High availability can be disabled, which lowers the price but results in data loss and downtime on failure. That's a dev/test-only choice.

Availability on the retiring service

For existing Azure Cache for Redis estates, the availability model was tier-dependent and worth recording while it's still running:

Standard (99.9%) — two VMs replicated within a single data centre with automatic failover, protecting against node-level failures: rack, server, power supply. A load balancer handles traffic during failover.
Zone redundancy (99.99%) — four nodes across three availability zones with automatic failover. Premium or Enterprise tiers only.
Geo-replication (99.999%) — Redis running in multiple regions, primarily for disaster recovery. Premium or Enterprise only, and failover is manual.

That last point is a deliberate design choice rather than a gap. Automatic cross-region failover isn't supported because Redis is an in-memory store: failing over automatically risks silently serving an empty or stale cache to an application that believes it's warm. Keeping the decision under human control is the safer default.

The caching patterns

These hold whichever service you're on.

Pattern	Scenario	Solution
Data cache	Databases are often too large to load directly into a cache.	Use the cache-aside pattern to load data only as needed. When the system changes data it can update the cache, which is then distributed to other clients. Expiry or an eviction policy triggers updates.
Content cache	Web pages generated from templates with static headers, footers, and banners that rarely change.	An in-memory cache serves static content far faster than a back-end datastore, reducing processing time and server load, and potentially the number of servers needed. Redis provides an Output Cache Provider for ASP.NET.
Session store	Shopping carts and user history a web application associates with cookies. Storing too much in a cookie hurts performance as it grows and is validated on every request.	Use the cookie as a key and hold the data in Redis — far faster than querying a relational database for it.
Deduplication	Determining whether something already happened: is this username taken, was this customer already emailed?	Bloom filters rapidly identify duplicates — not available on the Flash Optimized tier.
Leaderboards	Ranked scoreboards of any kind.	The sorted set data structure, with active geo-replication sharing one leaderboard globally.
Job and message queuing	Long-running operations that would otherwise block unrelated work.	Applications queue tasks for sequential processing, often on another server. Redis provides a distributed queue.
Distributed transactions	A series of commands that must all succeed or all roll back.	Redis executes a batch of commands as a single transaction.

Cache-aside, specifically

Where the problem is reducing database load with minimal development effort, cache-aside is the right answer: read from the cache when the data is there, query Azure SQL Database only on a miss, and populate the cache with the result.

The alternatives don't solve the same problem. Adding App Service instances scales compute but doesn't reduce database requests unless paired with an effective caching pattern. Adding more Redis instances may improve cache scalability, but distributing keys across them usually requires application changes — more development effort, not less.

The caveat the course material skips: cache-aside introduces staleness and an invalidation problem. You now own the question of when cached data stops being true, and getting that wrong produces bugs that are hard to reproduce.

Session store, specifically

This pattern is the fix for a problem worth naming from the other direction. Session affinity on a load balancer pins a user to one backend server, which undermines even load distribution and loses the session entirely when that server fails. Externalising session state to Redis removes the need for affinity altogether — I covered the affinity side of this in Azure Application Gateway: Layer 7 Load Balancing, TLS Termination, and WAF.

Job queuing, with a caveat

Redis can act as a queue, but it's an in-memory store first. It offers none of the dead-lettering, duplicate detection, or transactional guarantees that Service Bus provides, and durability depends on the persistence feature. Use it for deferring work inside an application you control, not as the integration backbone between services — that's what Azure Messaging and Events: Service Bus, Event Hubs, Event Grid covers.

Two things a cache is not

A cache isn't durable storage. Data in it can be evicted, lost on failover, or absent after a restart. Anything that must survive belongs in a database that promises it.

A cache doesn't fix a slow query, it hides one. That's often the right trade, but it's worth making deliberately rather than reaching for Redis as the first response to a performance problem.