Azure Managed Redis

About Azure Managed Redis

Azure Managed Redis is Microsoft's current fully managed Redis Enterprise service for applications that need very low latency, high request throughput, in-memory data access, caching, session storage, messaging, leaderboards, vector search and related real-time patterns. It is the strategic successor to Azure Cache for Redis, whose existing tiers are on published retirement timelines. Azure Managed Redis is best evaluated as an application data and performance service, not as a primary system of record for every workload. Buyers should size it around working-set memory, throughput, client connections, clustering behavior, availability requirements and the migration characteristics of the application that will use it.

What workloads is Azure Managed Redis designed for?

Azure Managed Redis is designed for workloads where application response time depends on keeping frequently accessed data close to the application. Common patterns include cache-aside for databases, session storage, data ingestion, deduplication, leaderboards, messaging, distributed coordination and other low-latency application patterns. Microsoft also documents Redis Search, JSON, Bloom and TimeSeries capabilities on supported tiers, which expands the service beyond simple key-value caching.

The service can sit alongside Azure App Service, Azure Functions, Azure Container Apps, Azure Kubernetes Service, Azure SQL Database and Azure Cosmos DB. A durable store can remain the source of truth while Redis handles fast access, transient state or specialized real-time queries. That separation is important because Redis should not automatically become the authoritative database simply because it is fast.

How do the Azure Managed Redis tiers differ?

Microsoft currently offers four tier families. Memory Optimized targets workloads that need a high memory-to-vCPU ratio. Balanced provides a middle ground between memory capacity and compute. Compute Optimized provides more compute relative to memory for throughput-heavy workloads. Flash Optimized combines RAM with NVMe storage for very large data sets at a lower cost per GB, but with lower performance than a fully in-memory design.

Microsoft currently describes the approximate memory-to-vCPU ratios for the in-memory families as 8:1 for Memory Optimized, 4:1 for Balanced and 2:1 for Compute Optimized. Buyers should still use the current SKU tables and performance testing guidance rather than assuming those ratios alone predict application performance.

Some large SKUs remain preview. Microsoft currently marks in-memory tiers using more than 350 GB as preview, including Memory Optimized M500 and higher, Balanced B500 and higher, and Compute Optimized X500 and higher. Flash Optimized A2000 and A4500 are also preview. Production teams should verify both SKU status and regional availability before committing architecture to one of those sizes.

Which clustering policy should a buyer choose?

Azure Managed Redis is internally clustered across its tiers, but Microsoft exposes three clustering policies for client behavior: OSS, Enterprise and Non-clustered. OSS clustering generally offers the best throughput and lowest latency because cluster-aware clients can connect directly to shards. It requires a client library that supports the Redis Cluster API.

Enterprise clustering presents a simpler single endpoint and internally routes requests to the correct shard. This can improve compatibility with clients that are not cluster-aware, but the proxy path can become a throughput bottleneck. Enterprise clustering is required for RediSearch.

Non-clustered is intended for compatibility scenarios that need a nonsharded topology. Microsoft limits it to caches of 25 GB or smaller, and it is generally less performant because the service cannot use sharding to parallelize work. The clustering policy is an important design choice because Microsoft does not allow it to be changed after instance creation in normal deployment flows.

How does pricing work?

Azure Managed Redis does not have one universal monthly price. Microsoft prices it by tier, instance size and whether high availability is enabled. The live pricing page also lists one-year and three-year reservations for selected high-availability SKUs. Pricing was rechecked on September 5, 2026.

The smallest Balanced configurations provide the lower-cost entry points, while large in-memory, high-throughput and Flash Optimized configurations can become materially more expensive. Microsoft states that a deployed cache continues billing from creation until deletion and there is no stop or pause action that suspends billing. High availability costs more because additional nodes are used.

Buyers should model the exact Azure region, size, availability setting and reservation option in the Azure pricing calculator. Reservations can reduce cost for predictable production workloads, while pay-as-you-go is more flexible for workloads that may change size or architecture.

What should buyers know about availability and active geo-replication?

High availability is supported across current Azure Managed Redis tiers. In Azure regions that support Availability Zones, Microsoft distributes high-availability nodes across zones by default. Important production workloads should normally keep high availability enabled because disabling it increases exposure to downtime and data loss during failures or maintenance events.

Active geo-replication is supported on Memory Optimized, Balanced and Compute Optimized tiers except Balanced B0 and B1. Flash Optimized does not support active geo-replication. Microsoft also requires geo-replicated instances to use high availability.

Geo-replication groups require matching configuration across participating caches, including SKU, capacity, eviction policy, clustering policy, modules and TLS settings. Only RediSearch and RedisJSON modules are supported with active geo-replication. Data persistence is not supported in an active geo-replication group because Microsoft positions the active-active replication model as the resilience mechanism for that configuration.

What should Azure Cache for Redis customers verify before migration?

Microsoft is retiring all Azure Cache for Redis SKUs and recommends moving existing workloads to Azure Managed Redis. Enterprise and Enterprise Flash retire on March 31, 2027. Basic, Standard and Premium retire on September 30, 2028.

The migration details differ by source tier. Microsoft made migration tooling for Enterprise generally available in April 2026. Tooling for Basic, Standard and Premium entered public preview in April 2026. In July 2026 Microsoft removed the previously planned October 2026 creation block for existing Basic, Standard and Premium customers in public cloud. New customers have been blocked from creating those tiers since April 1, 2026, while qualifying existing customers can continue creating them until retirement.

A critical compatibility difference is database count. Azure Managed Redis supports only database 0. Applications that use multiple Redis logical databases must refactor to one database or use key prefixes before migration. This should be checked early because it can require application changes rather than a simple infrastructure swap.

Geo-replication behavior also differs. Azure Managed Redis uses active geo-replication with read and write access across linked instances. Premium Azure Cache for Redis uses passive geo-replication with a read-only secondary. Azure Managed Redis does not provide an explicit Failover command, so applications need a strategy for switching to another geo-replicated instance when a region is unavailable.

What scaling limitations matter in production?

Scaling is supported, but not every source and destination combination is valid. Microsoft states that you cannot move between the in-memory families and Flash Optimized by ordinary scaling. Moving from Memory Optimized, Balanced or Compute Optimized to Flash Optimized, or the reverse, requires a different migration approach.

When scaling down memory, current memory usage must already fit within the target size. Scaling down CPU or memory is also restricted to SKUs whose vCPU and shard configuration is compatible with the current instance. Geo-replicated caches have additional scaling restrictions, and scaling geo-replicated instances is currently preview.

Scaling can also change the underlying IP address. Microsoft updates DNS so most correctly configured applications continue working, but applications, firewall rules or network security configurations that hardcode the cache IP can experience connection problems after a scale operation. Clients should resolve the documented hostname rather than depend on an underlying address.

High-availability caches remain available during scaling, although brief connection interruptions can occur. If high availability is disabled, Microsoft states that the instance is offline during scaling. Redis clients therefore need connection retry and reconnection behavior even when the service is configured for high availability.

What security and network controls are available?

Microsoft Entra ID is enabled by default on new Azure Managed Redis instances, while access-key authentication is disabled by default. Microsoft recommends Entra ID with managed identities where possible. Entra authentication requires SSL connections, and Microsoft currently does not support Entra groups for this service.

Applications using Entra authentication must refresh tokens before expiry and reauthenticate the Redis connection. Teams should build this into the client implementation rather than assuming one login token lasts for the connection lifetime.

Private endpoint support is available for network isolation. Module and clustering choices also affect security and operability because modules must be selected when the instance is created and cannot be added later. If RediSearch is used, Microsoft requires Enterprise clustering and the NoEviction policy.

What are the main limitations and tradeoffs?

Redis is optimized for low-latency access, not as a universal durable database replacement. Teams need to decide what data can be transient, what must be persisted elsewhere, what eviction behavior is acceptable and what recovery objectives apply. Large memory footprints can become expensive quickly when the working set is poorly sized.

Several choices are difficult or impossible to change later. Modules are selected at creation, clustering policy is fixed after creation, active geo-replication needs advance planning, and some scaling paths are restricted. The service also supports only logical database 0, which can be a material migration issue for applications that currently use multiple Redis databases.

Clustered deployments can expose CROSSSLOT behavior for multi-key commands. With OSS clustering, all keys used by a multi-key command must map to the same hash slot. Enterprise clustering allows only a limited set of multi-key commands across slots. Applications that rely heavily on cross-key transactions or multi-key operations should test this behavior before migration.

Who should choose something else?

Choose a durable database such as Azure SQL Database, Azure Database for PostgreSQL or Azure Cosmos DB when the primary requirement is long-term authoritative storage, transactional integrity or database-native query behavior rather than ultra-low-latency access. Choose Azure Service Bus when durable enterprise messaging, queues, transactions and brokered delivery are the core problem rather than in-memory state.

Teams that require many logical Redis databases without refactoring should also evaluate whether Azure Managed Redis is currently the right migration target because the service supports only database 0. Applications that depend on unsupported cross-slot command behavior, specific clustering semantics or unsupported geo-replication combinations may need redesign before adoption.

Very small or infrequent workloads may find a dedicated managed Redis instance difficult to justify economically because billing continues while the cache exists and the service cannot simply be paused. Existing Azure Cache for Redis customers should still plan migration because the older service is on a published retirement path.