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' }
    ]
  }
}

Figure: which Azure option

flowchart TD A[Deploying Redis on Azure] --> B{New deployment, or\nmigrating off legacy\nAzure Cache for Redis?} B -->|Migrating off Basic/Standard/Premium\nor Enterprise/Enterprise Flash| C[Plan migration to\nAzure Managed Redis\nbefore the retirement date] B -->|New deployment| D{Need RediSearch, vector\nsearch, RedisBloom, or\nRedisTimeSeries?} D -->|Yes| E{Throughput vs.\nmemory priority?} D -->|No, RedisJSON\nis enough, dataset is\nvery large and mostly cold| F[Azure Managed Redis:\nFlash Optimized tier] E -->|Memory-heavy, cost-sensitive| G[Azure Managed Redis:\nMemory Optimized tier] E -->|Balanced workload| H[Azure Managed Redis:\nBalanced tier] E -->|Throughput-critical| I[Azure Managed Redis:\nCompute Optimized tier] B -->|Standardizing on Redis's\nown managed service,\nAzure-native billing preferred| J[Redis Cloud on Azure\nMarketplace] C --> K{Which legacy tier?} K -->|Enterprise / Enterprise Flash| L[Azure Managed Redis tier\nmatching current module/HA needs] K -->|Basic / Standard / Premium| L