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.

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. That makes it useful when a slower durable data store remains the source of truth while Redis handles fast access, transient state or specialized real-time queries.

How do the Azure Managed Redis tiers differ?

Microsoft currently offers four tier families. Memory Optimized is intended for workloads that need more memory per vCPU and do not require the highest throughput. Balanced provides a middle ground between memory capacity and compute. Compute Optimized targets throughput-heavy workloads with more CPU relative to memory. Flash Optimized combines RAM with NVMe storage to reduce the cost of very large data sets, with lower performance than a fully in-memory design.

Tier choice affects available memory, CPU, network bandwidth, maximum connections and feature availability. Active geo-replication is available on the in-memory tier families but not Flash Optimized. Search and vector-search capabilities are also not available on Flash Optimized according to Microsoft's current comparison. Some of the largest in-memory and Flash Optimized SKUs remain in preview, so production buyers should check the exact SKU status in their target region before committing.

How does pricing work?

Azure Managed Redis does not have one universal monthly price. Microsoft prices the service by tier, instance size and whether high availability is enabled. The pricing page also offers one-year and three-year reservations for selected high-availability SKUs. The smallest Balanced configurations are the lowest-cost entry points, while high-memory, high-throughput and Flash Optimized configurations can cost substantially more.

Pricing should be modeled using the exact region, size, availability setting and reservation choice. Microsoft states that caches are billed from creation until deletion and there is no stop or pause option that suspends billing. High availability costs more because additional nodes are deployed. For predictable production workloads, reservations can reduce cost, while pay-as-you-go remains more flexible for workloads that may change size or architecture.

What should buyers know about availability, scaling and geo-replication?

High availability can be enabled across all current Azure Managed Redis tiers. In regions that support Availability Zones, Microsoft distributes high-availability nodes across zones by default. Buyers should not disable high availability for important production workloads simply to reduce cost, because Microsoft warns that doing so can increase downtime and data-loss risk.

The service also supports scaling, though scaling down has documented limitations in some cases. Active geo-replication can provide multi-region read and write access for supported in-memory tiers, but the design should be planned before deployment. Microsoft requires active geo-replication to be enabled during provisioning for a cache that will participate in a geo-replication group. Balanced B0 and B1 do not support active geo-replication.

What security and network controls are available?

Microsoft Entra ID is enabled by default on new Azure Managed Redis deployments, while access-key authentication is disabled by default. Microsoft recommends Entra ID with managed identities where possible instead of relying on shared keys. Private endpoint support is available across the current tier families for network isolation.

Security decisions made during creation matter. Redis modules must be selected when the instance is created and cannot simply be added later. Clustering policy also cannot be changed after deployment. If Redis Search or other modules are used, Microsoft requires the Enterprise clustering policy. Buyers should review those choices before production rollout rather than assuming every setting can be changed later.

How is Azure Managed Redis different from Azure Cache for Redis?

Azure Managed Redis is Microsoft's current strategic Redis service. Microsoft announced retirement timelines for all Azure Cache for Redis SKUs and recommends migrating workloads to Azure Managed Redis. Azure Cache for Redis Enterprise and Enterprise Flash retire on March 31, 2027. Basic, Standard and Premium tiers retire on September 30, 2028, with new-resource creation already being restricted in phases.

That makes Azure Managed Redis the better choice for new Redis deployments unless a documented compatibility or migration constraint requires the older service temporarily. Existing Azure Cache for Redis customers should treat migration as a planned lifecycle project, especially where modules, clustering, networking, authentication or application behavior differ.

What are the main limitations and tradeoffs?

Redis is optimized for low-latency data access, not as a universal durable database replacement. Teams still need to decide what data can be transient, what must be persisted elsewhere, what eviction behavior is acceptable and what recovery objectives apply. Memory-heavy designs can become expensive quickly if the workload is sized poorly.

Several deployment choices are also sticky. Modules cannot be added after creation, clustering policy cannot be changed after creation, and active geo-replication requires advance planning. Very large SKUs and some Flash Optimized sizes remain preview. Buyers should also verify regional availability because Azure Managed Redis is still expanding to more Azure regions.

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 data 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 with very small or infrequent workloads may also find a dedicated managed Redis instance difficult to justify economically, especially because the service keeps billing while deployed and cannot simply be paused. Existing Azure Cache for Redis customers should migrate toward Azure Managed Redis rather than creating more dependence on a retiring service.