Plan reliability and durability for Azure Managed Redis

Azure Managed Redis offers several capabilities that each protect against a different kind of failure: high availability, availability-zone distribution, data persistence, active geo-replication, and application-level backup and rebuild strategies. These capabilities complement each other rather than substitute for one another, and no single capability covers every failure scenario. This article helps you understand the purpose and failure scope of each capability, how they work together, the constraints that apply to tiers and modules, and the questions you need to answer when you plan for recovery point objective (RPO) and recovery time objective (RTO).

High availability

High availability (HA) deploys your cache with primary and replica shards distributed across at least two nodes. If a node or shard becomes unavailable, a replica shard promotes itself to primary automatically, without any action from your application beyond handling the resulting connection interruption.

• What it protects against: Node, VM, or shard failures within a single cache deployment, including failures caused by planned maintenance and patching.
• What it doesn't protect against: Availability-zone outages (unless the cache is also zone redundant), region-wide outages, or data corruption. HA also doesn't create any backup you can restore from.
• Constraints: You can enable HA on an existing cache, but you can't disable it after it's enabled. Running without HA is only appropriate for development and test scenarios because it removes access to the availability SLA and increases the risk of data loss and downtime.

Availability-zone distribution

Availability-zone distribution (zone redundancy) spreads the nodes of an HA-enabled cache across multiple physically separate availability zones within a region. If a zone becomes unavailable, the service redirects traffic to nodes in the remaining healthy zones.

• What it protects against: Datacenter or availability-zone outages within a region.
• What it doesn't protect against: Region-wide outages, or data written after the most recent replication cycle between zones.
• Constraints: Zone redundancy requires HA and is available in regions that support availability zones and where Azure Managed Redis is available. All Azure Managed Redis tiers support it in those regions. By default, zone redundancy is applied automatically when you deploy an HA cache there, with no extra configuration step. You can't turn off zone redundancy after it's applied because you can't reverse HA on a cache.

Automatic redundancy mode (preview)

Automatic redundancy mode allows new high-availability caches to use locally redundant placement when zone-redundant placement is unavailable. Azure first attempts zone-redundant placement. If that placement isn't available, Azure might deploy the cache with locally redundant high availability. Locally redundant high availability protects against node failures but not availability zone failures.

To enable this behavior, register the preview feature by using the portal, Azure CLI, or Azure PowerShell. Search for provider namespace Microsoft.Cache and feature name AllowAutomaticRedundancyMode. Registration is subscription-wide and enables the redundancy mode fallback behavior for every new high-availability cache created in the subscription. It doesn't affect existing caches, and you can't select the redundancy mode for individual new caches. Registration doesn't guarantee that a cache can be deployed.

After deployment, inspect the cluster resource's properties.redundancyMode property to determine which redundancy mode was applied.

Data persistence

Data persistence writes snapshots (RDB) or a continuous write log (AOF) of your cache data to a managed disk. If both the primary and replica shards fail, the service automatically rehydrates the same cache instance from the most recent persisted file when it comes back online.

• What it protects against: Loss of in-memory data when both the primary and replica shards of the same cache fail.
• What it doesn't protect against: Region-wide outages, data corruption or accidental deletion (because the persisted file reflects whatever was written, including bad writes), or point-in-time recovery to an earlier state.
• Constraints: Persistence requires HA. It's available on the Memory Optimized, Balanced, and Compute Optimized tiers, and in preview on the Flash Optimized tier. Persistence and active geo-replication can't be enabled on the same cache at the same time.

Active geo-replication

Active geo-replication links up to five Azure Managed Redis instances across Azure regions into a single active-active replication group. Every linked instance can accept both reads and writes, and changes sync bidirectionally across all instances using conflict-free replicated data types (CRDTs).

• What it protects against: Region-wide outages. If one region becomes unavailable, applications can continue operating against a linked instance in another region.
• What it doesn't protect against: Data corruption, accidental deletion, or a guaranteed sync time between instances. Replication is eventually consistent, and the service doesn't provide an SLA on sync time.
• Constraints: Requires HA on every linked instance, and all instances in a group must share identical configuration, including SKU, capacity, eviction policy, clustering policy, modules, and TLS setting. It's not supported on the Balanced B0 and B1 SKUs or on the Flash Optimized tier. Only the RediSearch and RedisJSON modules are supported alongside active geo-replication, and RediSearch additionally requires the Enterprise clustering policy and the NoEviction eviction policy. Active geo-replication can't be combined with data persistence.

Application-level backup and rebuild strategy

Import and export lets you save an RDB snapshot of your cache data to Azure Blob Storage, and restore that snapshot to the same or a different cache instance. Because Azure Managed Redis doesn't include a built-in backup scheduler, you're responsible for building your own automation (for example, with Azure CLI or Azure PowerShell scripts) to export data periodically and manage retention of the resulting blobs.

• What it protects against: Data corruption, accidental deletion, and the need to repopulate a cache or rebuild it in a new region or subscription from a known-good point in time.
• What it doesn't protect against: Real-time failures. Import and export is a manual or scripted operation, not an automatic failover mechanism, and a cache is unavailable to clients for the duration of an import.
• Constraints: Available on all tiers, including Flash Optimized. Individual keys larger than 2 GB fail an import.

How these capabilities complement each other

These five capabilities address different but sometimes overlapping failure scopes. Most production caches need more than one because no single capability protects against every failure scenario:

• High availability and availability-zone distribution protect the infrastructure underneath a single cache instance and are managed entirely by Azure Managed Redis.
• Data persistence adds durability for the data inside that same instance, but only for automatic recovery of the same cache after a failure, not as a portable backup.
• Active geo-replication protects against the loss of an entire region by giving your application another live instance to use, but it requires your application to detect the failure and route around it.
• Application-level backup and rebuild (import/export) is the only capability that protects against data corruption, accidental deletion, or the need to restore to a point in time, and it's the mechanism to use when persistence or geo-replication isn't enabled or isn't sufficient to meet a recovery requirement.

Because persistence and active geo-replication are mutually exclusive on the same cache, choose the one that matches your primary risk: use persistence when your main concern is losing an entire cache to a node failure within a region, and use active geo-replication when your main concern is losing an entire region. If you need recovery from data corruption, accidental deletion, or a known point in time, plan an independent import/export backup process.

Production defaults

For production Azure Managed Redis deployments:

• Enable high availability. It's required for the availability SLA, for zone redundancy, for persistence, and for active geo-replication.
• Deploy into a region that supports availability zones and where Azure Managed Redis is available so that zone redundancy applies automatically to your HA cache at no extra configuration step.
• Add data persistence if your primary concern is recovering the same cache automatically after a node-level failure, and you don't need active geo-replication.
• Add active geo-replication for mission-critical workloads that must keep operating through a regional outage, and build the application logic needed to detect a failed region and redirect traffic.
• Build a recurring import/export process if the cache data can't be reconstructed within your recovery objectives, or if you need recovery from data corruption, accidental deletion, or a known point in time.

Tier, SKU, and module constraints

Plan for the following additional constraints:

• You can't enable active geo-replication and data persistence on the same cache.
• Active geo-replication requires every linked instance to use identical SKU, capacity, eviction policy, clustering policy, modules, and TLS settings.
• You can only use the RediSearch and RedisJSON modules with active geo-replication. RediSearch also requires the Enterprise clustering policy and the NoEviction eviction policy, which rules out the OSS clustering policy for that combination.

RPO and RTO considerations

Azure Managed Redis doesn't publish a guaranteed RPO or RTO, and the service's SLA covers connectivity to the cache endpoint, not protection from data loss. Use the following documented, typical behaviors to inform your planning; treat them as design inputs, not commitments:

• Planned failover (patching, scaling, and other management operations) typically completes in under one second.
• Unplanned failover within a region (an undetected node or shard failure) typically completes within 10 to 15 seconds, because a replica must first confirm the failure isn't transient before promoting itself.
• Availability-zone failure: nodes in the affected zone typically fail over to healthy zones within about 10 to 15 seconds. You can lose any writes that didn't yet replicate to a shard in another zone; replication lag between zones is typically measured in seconds but depends on your workload.
• Region failure with active geo-replication: downtime depends on how quickly your application detects the failure and redirects traffic, typically ranging from seconds to a few minutes. You can lose writes that didn't replicate out of the failed region before the outage, and the potential loss scales with replication lag at the time of failure.
• Region failure without active geo-replication: there's no platform-managed regional failover. Recovery time and recovery point depend entirely on how recently you exported a backup and how quickly you can provision a new instance and import it.

To be eligible for the availability SLA, a cache must use an HA configuration and must not be undergoing a documented, temporary-unavailability management action. Higher availability SLA tiers can apply when a cache is zone redundant, and in some tiers, when zone-redundant instances are deployed across at least three regions using active geo-replication. For current SLA terms, see the Azure Managed Redis SLA. Treat the timing and eligibility details in this article as planning inputs, not guarantees.

Plan for regional failures

Azure Managed Redis has two distinct paths for a region-wide outage, and the path you get depends on whether active geo-replication is configured:

• With active geo-replication configured, your application can redirect requests to a linked instance in another region. You're responsible for monitoring the health of the replication group (for example, using the geo-replication healthy metric), deciding when to fail over, and redirecting traffic. During an extended outage, consider force-unlinking the affected instance if metadata buildup creates memory pressure on the remaining instances. If the instance remains linked, Azure Managed Redis automatically reintegrates and resynchronizes it when the region recovers. If you force-unlink it, you must delete the affected cache, create a replacement, and add the replacement to the replication group.
• Without active geo-replication configured, there's no automatic regional failover. Data persistence only rehydrates the same cache in the same region, and persisted files can't be moved to a new instance. To recover from a full regional outage in this scenario, you must provision a new cache in a surviving region and restore your most recent import/export backup, so your recovery time and recovery point depend on your backup cadence and provisioning automation.

Application routing and failover responsibilities

Azure Managed Redis automates failover within a single cache and across availability zones: it detects node, shard, and zone failures, promotes replicas, and reroutes traffic to healthy nodes without requiring you to take action. Beyond that scope, your application owns failover:

• Your application must implement retry, backoff, and circuit-breaker patterns to handle the connection interruptions that occur during any failover, planned or unplanned. For more information, see connection resilience.
• Azure doesn't automatically notify you when a zone or region is unhealthy. Use Azure Service Health alerts and the geo-replication healthy metric to detect problems that require your attention.
• With active geo-replication, your application is responsible for choosing which linked instance to use for reads and writes, detecting a failed region, redirecting traffic to a healthy instance, and reconfiguring routing back to the original region after it recovers.
• Without active geo-replication, your application (or an operator) is responsible for provisioning a replacement cache and restoring an import/export backup after a regional outage.

Decision matrix

Production planning checklist

Related content

• Azure Managed Redis architecture
• Failover and patching for Azure Managed Redis
• Configure data persistence for an Azure Managed Redis instance
• Configure active geo-replication for Azure Managed Redis instances