Deploying Redis on Azure
|
This content was generated with the assistance of AI and should be verified against the official Redis documentation before being relied on in production. This section’s bibliography lists the reference material consulted while preparing these pages. |
This page covers deploying and consuming Redis as a managed Azure service as of September 2026, distinct from
running docker run redis:8 locally for development, which the rest of this section’s pages target. Azure
offers three ways to run Redis: Azure Managed Redis (the current first-party offering), the older Azure Cache
for Redis (now retiring), and Redis Cloud on Azure Marketplace (Redis’s own managed service, hosted on Azure
infrastructure). For the broader Azure platform view — deploying and managing partner/marketplace databases
(Elastic Cloud, Couchbase Capella, Neo4j AuraDB, Qdrant Cloud, MongoDB Atlas) alongside Azure Managed Redis — see Redis and Partner Databases on Azure.
Azure Managed Redis
Azure Managed Redis (AMR) is Azure’s current first-party managed Redis offering, built on Redis Enterprise software rather than the community edition Azure Cache for Redis was built on. It runs a current Redis Enterprise release tracking the Redis 7.4.x line, and is clustered by default. See What is Azure Managed Redis?.
Tiers
Four tiers cover different memory-to-vCPU ratios and storage strategies, chosen at creation time and not changeable afterward:
-
Memory Optimized — an 8:1 memory-to-vCPU ratio, the lowest price point among the in-memory tiers, suited to memory-heavy workloads that don’t need top throughput, and to dev/test environments.
-
Balanced — a 4:1 memory-to-vCPU ratio for standard workloads that need a healthy mix of both.
-
Compute Optimized — a 2:1 memory-to-vCPU ratio for throughput-heavy workloads that need maximum performance per byte of data.
-
Flash Optimized — extends effective capacity beyond RAM by moving less-frequently-accessed values to NVMe flash storage: roughly 20% of the cache footprint stays in RAM (all keys, plus hot values) while the remaining 80% is flash-backed, trading some latency and module support for a much larger, cheaper dataset.
An instance can’t be rescaled between the Flash Optimized tier and any of the three in-memory tiers — moving between them means provisioning a new instance and migrating data. See Choosing the right Azure Managed Redis tier.
Module support by tier
Memory Optimized, Balanced, and Compute Optimized all support the full Redis module set — RediSearch (the
Query Engine and vector search), RedisJSON, RedisBloom (probabilistic types), and RedisTimeSeries. The Flash
Optimized tier trades that breadth for its larger, cheaper dataset: only RedisJSON is supported there, so
Query Engine indexing, vector search, probabilistic types, and time series are unavailable on Flash-backed
instances. RediSearch specifically also requires the Enterprise clustering policy (below) and a NoEviction
eviction policy, and only RediSearch and RedisJSON can run alongside active geo-replication. See
Using Redis modules with Azure Managed Redis and
Best practices for the Flash
Optimized tier.
High availability, geo-replication, and persistence
High availability replicates each shard to a replica within the same region and fails over automatically; it can be disabled for a lower-cost, non-HA configuration suited to dev/test or other non-production instances, an option Azure Cache for Redis never offered. Active geo-replication links up to five Azure Managed Redis instances across regions in an active-active configuration, so each region accepts local writes and the instances converge, giving both lower cross-region read/write latency and resilience against a full regional outage. Two independent persistence mechanisms protect against data loss on top of replication: RDB snapshots the dataset to a managed disk on a configurable schedule, and AOF logs every write once per second to a managed disk — on an HA-enabled instance, AOF only runs on replica shards, so primary shards avoid the associated write overhead. See Configure data persistence and the active geo-replication coverage in What is Azure Managed Redis?.
Networking, authentication, and clustering policy
Azure Managed Redis is reached at <cachename>.<region>.redis.azure.net on port 10000, not Redis’s usual
6379. Private endpoints are fully supported (up to 84 private links per cache), backed by an automatically
created *.privatelink.redis.azure.net private DNS zone. Alongside legacy access keys, Azure Managed Redis
is built around Microsoft Entra ID authentication — a managed identity or service principal authenticates to
the cache directly, without a long-lived shared key sitting in configuration. See
Azure Managed Redis with Azure Private Link and
Microsoft Entra ID authentication with
Azure Managed Redis.
Every instance also picks a clustering policy at creation, which — like the tier — can’t be changed later:
OSSCluster (the default) exposes the cluster the way open source Redis Cluster does, giving the highest
throughput to clients that are cluster-aware, while Enterprise fronts the whole cluster behind a single
proxy endpoint, trading a little throughput for compatibility with clients that don’t implement Redis Cluster
routing themselves; a non-clustered option is also available up to 25 GB, mainly for compatibility with older
client configurations. See
Azure Managed Redis architecture.
Azure Cache for Redis retirement
Azure Cache for Redis — the older offering, built on a fork of Redis OSS rather than Redis Enterprise — is being retired in two waves, confirmed live against Microsoft’s retirement FAQ while writing this page. The Enterprise and Enterprise Flash tiers retire first: existing instances stay available through March 31, 2027, and any instance not migrated by then is disabled starting April 1 of that year. The Basic, Standard, and Premium tiers have a longer runway, retiring on September 30, 2028, with disablement starting October 1 of that year. (A note for reserved-pricing holders: Microsoft separately states existing Enterprise reservations are supported through March 30, 2027 — one day short of the tier’s own retirement date — so don’t rely on the reservation date as the instance’s own deadline.)
| Tier being retired | Retirement date | Instances disabled from |
|---|---|---|
Enterprise / Enterprise Flash |
March 31, 2027 |
April 1, 2027 |
Basic / Standard / Premium |
September 30, 2028 |
October 1, 2028 |
Both waves point at the same destination: Microsoft’s stated recommendation is to migrate to Azure Managed Redis well ahead of the deadline rather than waiting for it, since Azure Managed Redis is also positioned as faster and more cost-effective than the tiers it replaces. Microsoft publishes separate migration guides for each source tier family — one path for Basic/Standard/Premium instances, a different one for Enterprise and Enterprise Flash instances — covering endpoint cutover and data retention during the move; because retirement dates and migration tooling can shift, reconfirm both against the current retirement FAQ before planning around them. See Azure Cache for Redis retirement FAQ, Migrate Basic, Standard, and Premium tiers to Azure Managed Redis, and Migrate Enterprise tier to Azure Managed Redis.
Redis Cloud on Azure
Redis Cloud — covered generically in
Redis Software, Redis Cloud, Kubernetes & Valkey — is also available directly through
Azure Marketplace, provisioned and billed through the customer’s existing Azure subscription rather than a
separate Redis account. It’s the option to reach for when a team wants Redis’s own managed service (the same
Essentials/Pro tiers, Active-Active, and auto-tiering described on that page) with Azure-native procurement and
billing, rather than Azure’s own first-party offering; that page’s coverage of Redis Cloud’s tiers, networking,
and Terraform/redisctl tooling applies unchanged on the Azure Marketplace listing. See
Redis Cloud on Azure Marketplace.
Choosing an option
| Option | Module support | High availability | Retirement timeline | Typical use case |
|---|---|---|---|---|
Azure Managed Redis — Memory/Balanced/Compute Optimized |
Full (RediSearch, RedisJSON, RedisBloom, RedisTimeSeries) |
Optional, on by default; active geo-replication across up to 5 regions |
None — current offering |
New deployments needing Query Engine/vector search, or any workload with full module needs |
Azure Managed Redis — Flash Optimized |
RedisJSON only |
Optional, on by default; active geo-replication across up to 5 regions |
None — current offering |
Very large, mostly cold datasets where RAM cost dominates and modules beyond RedisJSON aren’t needed |
Azure Cache for Redis (Enterprise / Enterprise Flash) |
Modules supported (legacy Redis Enterprise feature set) |
Available |
Retires March 31, 2027 |
Existing workloads pending migration only — don’t deploy new instances here |
Azure Cache for Redis (Basic / Standard / Premium) |
None (OSS-fork core commands only) |
Standard/Premium only |
Retires September 30, 2028 |
Existing workloads pending migration only — don’t deploy new instances here |
Redis Cloud on Azure (Marketplace) |
Full, per Redis Cloud’s Essentials/Pro tier feature set |
Available (Pro); 99.999% SLA on Pro |
None — current offering |
Teams standardizing on Redis’s own managed service with Azure-native billing |
Spring Boot: Microsoft Entra ID authentication
redis-authx-entraid (artifact redis.clients.authentication:redis-authx-entraid) lets a Jedis or Lettuce
client authenticate to Azure Managed Redis with a Microsoft Entra ID token instead of an access key: it
acquires a token for a managed identity or service principal, caches it, and proactively refreshes and
re-authenticates the connection before the token expires, so the application never handles a raw credential or
a manual refresh loop. TLS is mandatory on Azure Managed Redis’s public endpoint, so both clients also enable
it explicitly.
package com.example.bookshop.config;
import com.azure.identity.DefaultAzureCredential;
import com.azure.identity.DefaultAzureCredentialBuilder;
import redis.clients.authentication.entraid.EntraIDTokenAuthConfigBuilder;
import redis.clients.jedis.DefaultJedisClientConfig;
import redis.clients.jedis.RedisClient;
import redis.clients.jedis.authentication.AuthXManager;
public class RedisEntraIdConfig {
public RedisClient jedisClient(String hostname, String scope) {
DefaultAzureCredential credential = new DefaultAzureCredentialBuilder().build();
var authConfig = EntraIDTokenAuthConfigBuilder.builder()
.tokenCredential(credential)
.scopes(scope) // e.g. "https://redis.azure.com/.default"
.build();
return RedisClient.builder()
.hostAndPort(hostname, 10000)
.clientConfig(DefaultJedisClientConfig.builder()
.ssl(true)
.authXManager(new AuthXManager(authConfig))
.build())
.build();
}
}
The equivalent with Lettuce, wired through Spring Data Redis’s LettuceConnectionFactory:
package com.example.bookshop.config;
import com.azure.identity.DefaultAzureCredential;
import com.azure.identity.DefaultAzureCredentialBuilder;
import io.lettuce.core.RedisCredentialsProvider;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisStandaloneConfiguration;
import org.springframework.data.redis.connection.lettuce.LettuceClientConfiguration;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import redis.clients.authentication.entraid.EntraIDTokenAuthConfigBuilder;
@Configuration
public class RedisEntraIdConfig {
@Bean
public LettuceConnectionFactory redisConnectionFactory(
@org.springframework.beans.factory.annotation.Value("${redis.azure.host}") String host,
@org.springframework.beans.factory.annotation.Value("${redis.azure.scope}") String scope) {
DefaultAzureCredential credential = new DefaultAzureCredentialBuilder().build();
RedisCredentialsProvider credentialsProvider = redis.clients.authentication.entraid.lettuce
.LettuceEntraIDCredentialsProviderFactory.create(
EntraIDTokenAuthConfigBuilder.builder()
.tokenCredential(credential)
.scopes(scope)
.build());
RedisStandaloneConfiguration serverConfig = new RedisStandaloneConfiguration(host, 10000);
LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
.useSsl()
.build();
LettuceConnectionFactory factory = new LettuceConnectionFactory(serverConfig, clientConfig);
factory.setShareNativeConnection(false);
return factory;
}
}
Both snippets assume spring-boot-starter-data-redis plus the redis-authx-entraid dependency and the
azure-identity SDK for DefaultAzureCredential; wiring application.yml properties and the workload’s
managed identity assignment are outside this page’s scope. This derives from
jvm-redis-authx-entraid and
Microsoft Entra ID authentication with
Azure Managed Redis.
Provisioning: Bicep
A minimal Azure Managed Redis instance — a Balanced-tier cluster with HA enabled, plus a default database using the OSS clustering policy on port 10000:
param location string = resourceGroup().location
param cacheName string = 'bookshop-cache'
resource redisEnterprise 'Microsoft.Cache/redisEnterprise@2025-04-01' = {
name: cacheName
location: location
sku: {
name: 'Balanced_B1'
}
properties: {
highAvailability: 'Enabled'
minimumTlsVersion: '1.2'
}
}
resource defaultDatabase 'Microsoft.Cache/redisEnterprise/databases@2025-04-01' = {
name: 'default'
parent: redisEnterprise
properties: {
clientProtocol: 'Encrypted'
clusteringPolicy: 'OSSCluster'
evictionPolicy: 'VolatileLRU'
port: 10000
modules: [
{ name: 'RedisJSON' }
]
}
}
This derives from
Deploy Azure Managed Redis using
Bicep and the
Microsoft.Cache/redisEnterprise
template reference.
Figure: which Azure option
Related pages
-
Redis Software, Redis Cloud, Kubernetes & Valkey — Redis Cloud, Redis Software, and Valkey concepts that apply the same way on Azure as on any other cloud.
-
Deploying Redis on AWS — the equivalent managed-Redis landscape on AWS.
-
Deploying Redis on Google Cloud — the equivalent managed-Redis landscape on Google Cloud.
-
Performance and Caching —
AddStackExchangeRedisCacheand ASP.NET Core’s own distributed-cache wiring, which applies unchanged when the backing cache is Azure Managed Redis or Azure Cache for Redis. -
Comparing Vector Databases — how this cloud’s managed Redis vector search compares with pgvector, Qdrant and the other engines on price and availability.
References
-
Azure Managed Redis architecture — tiers, clustering policies.
-
Migrate Basic, Standard, and Premium tiers to Azure Managed Redis