Azure Cache for Redis
Every SKU of this service is on Microsoft's announced retirement path toward Azure Managed Redis — any resiliency plan built today should target the replacement service. Geo-replication here has no guaranteed recovery point.
Basic tier
Single node, no replica, no SLA.
- Replication
- None
- RPO
- N/A — cache data loss on node failure is expected by design
- RTO
- No guarantee
- Failover trigger
- N/A
Premium tier with zone redundancy
Replicas spread across zones with platform-managed primary/replica failover.
- Replication
- Asynchronous
- RPO
- Near-zero but not guaranteed — Redis replication is asynchronous even within a region
- RTO
- Seconds — automatic platform-managed failover
- Failover trigger
- Automatic
Passive geo-replication (Premium)
Active-passive link between two Premium caches, usually in different regions. Continuous asynchronous replication, but Microsoft's own documentation states no recovery point is guaranteed, and persistence is disabled entirely while the link is active.
- Replication
- Asynchronous
- RPO
- Not guaranteed — Microsoft explicitly states 'no recovery point is guaranteed' for unlinked/failed-over data
- RTO
- A few minutes once manually triggered
- Failover trigger
- Manual (customer-triggered)
Gotchas
The whole service is being retired
Microsoft has announced a retirement timeline for all Azure Cache for Redis SKUs (Basic, Standard, Premium) and is directing customers to Azure Managed Redis. Any resiliency documentation, architecture diagram, or tier-mapping exercise built against Azure Cache for Redis today needs a migration plan, or it will need re-validating against Azure Managed Redis before this service reaches end of life.
Geo-replication explicitly has no guaranteed recovery point
This isn't 'typically low RPO' language — Microsoft's own docs state plainly that no recovery point is guaranteed after an unlink/failover, and persistence (disk-backed durability) is disabled entirely while geo-replication is active.
Treat cache as rebuildable, not as a system of record
For most architectures, the right DR answer for a cache isn't geo-replication at all — it's accepting the cache is rebuildable from the actual source of truth, and sizing warm-up time into your RTO instead of engineering cache-layer DR.