cloudnative wiki

Azure Cache for Redis Architecture, Clustering, and Enterprise Tiers

8 min read

Azure Cache for Redis Architecture, Clustering, and Enterprise Tiers ⚡🧠

Azure Cache for Redis is a fully managed, in-memory data store engineered for sub-millisecond data retrieval, session caching, pub/sub messaging, and distributed locks. Based on open-source Redis and Redis Enterprise, the service scales from simple standalone caches to 10-shard clustered instances with data persistence (RDB/AOF), VNet isolation, and planetary-scale Active-Active multi-region replication using Conflict-Free Replicated Data Types (CRDTs).

1. Architecture & Tier Comparison

Azure Cache for Redis offers four distinct architectural tiers:

                           CLIENT APPLICATION / MICROSERVICES
                                           │
                                           ▼ (Port 6380 TLS / 6379 Non-TLS)
       ┌────────────────────────────────────────────────────────────────────────┐
       │               ENTERPRISE CLUSTERING PROXY / LOAD BALANCER              │
       │  - Routes hash slots (0-16383) across active master nodes              │
       │  - Enforces TLS 1.2+ encryption in transit                             │
       └───────────────────────────────────┬────────────────────────────────────┘
                                           │
       ┌───────────────────────────────────┴────────────────────────────────────┐
       │                      PREMIUM CLUSTERED REDIS NODES                     │
       │                                                                        │
       │  ┌────────────────────────┐         ┌────────────────────────┐         │
       │  │ Shard 1: Master (AZ 1) │         │ Shard N: Master (AZ 1) │         │
       │  │  Slots: 0 - 5460       │         │  Slots: 10923 - 16383  │         │
       │  └──────────┬─────────────┘         └──────────┬─────────────┘         │
       │             │ Async Replication                │ Async Replication     │
       │  ┌──────────▼─────────────┐         ┌──────────▼─────────────┐         │
       │  │ Shard 1: Replica (AZ 2)│         │ Shard N: Replica (AZ 2)│         │
       │  │  Standby Failover Node │         │  Standby Failover Node │         │
       │  └────────────────────────┘         └────────────────────────┘         │
       └───────────────────────────────────┬────────────────────────────────────┘
                                           │ Persistence
                                           ▼
       ┌────────────────────────────────────────────────────────────────────────┐
       │                 AZURE MANAGED STORAGE (RDB / AOF)                      │
       │  - Hourly automated RDB memory snapshots to Azure Blob Storage         │
       │  - Continuous Append-Only File (AOF) write journaling                  │
       └────────────────────────────────────────────────────────────────────────┘

Architectural Tiers Breakdown

CapabilityBasic TierStandard TierPremium TierEnterprise / Enterprise Flash
Node ArchitectureSingle VM node (No HA)Primary + Secondary (HA)Primary + Secondary (Multi-Zone)Multi-node active-active mesh
SLA Guarantee0.0% (None)99.9%99.95% (Multi-Zone)99.999% (Active-Active)
Data PersistenceNoneNoneRDB & AOF supportedRDB & AOF supported
ClusteringNot supportedNot supportedUp to 10 Shards (1.2 TB)Up to 2 TB RAM / 4.5 TB Flash
Virtual NetworkPublic endpoint onlyPublic endpoint onlyVNet Injection / Private LinkPrivate Link integration
Redis ModulesCore Redis onlyCore Redis onlyCore Redis onlyRediSearch, RedisJSON, RedisBloom
Multi-RegionPassive manual copyPassive manual copyPassive geo-replicationActive-Active Multi-Region CRDT

2. Core Concepts: Persistence, Clustering, and CRDT Active-Active

Clustering Mechanics

  • Hash Slot Distribution: Redis Cluster splits the key space into 16,384 logical hash slots. Every key is mapped to a slot via CRC16(key) % 16384.
  • Sharding: In a 3-shard Premium cluster, Shard 1 owns slots 0-5460, Shard 2 owns 5461-10922, and Shard 3 owns 10923-16383.
  • Hash Tags ({...}): To execute multi-key operations (like MGET or Lua scripts) on a clustered Redis cache, keys must map to the same hash slot. Wrapping the common identifier in curly braces (e.g., {user_101}.profile and {user_101}.orders) forces Redis to hash only the enclosed string, co-locating the keys on the exact same shard.

Enterprise Multi-Region Active-Active (CRDTs)

Traditional geo-replication in Redis is one-way passive: writes to a secondary region fail. The Enterprise Tier implements Conflict-Free Replicated Data Types (CRDTs):

  • Applications read and write locally to their nearest regional Redis cluster (East US and West Europe) with sub-millisecond response times.
  • Clusters synchronize asynchronously over the Azure global backbone.
  • If concurrent conflicting writes occur (e.g., two users modifying the same set or counter in different regions), the underlying CRDT mathematical algorithms deterministically resolve the conflict without human intervention or data corruption.

3. Production Deployment & CLI Operations (az)

1. Deploy a Premium Tier Clustered Redis Cache with Zone Redundancy

Deploy a 3-shard Premium Redis instance (P1 tier = 18 GB RAM total) with multi-zone HA and automated RDB persistence:

az group create --name rg-cache-prod --location eastus
 
# Deploy Premium Redis Cache with 3 shards
az redis create \
    --name redis-core-production-eastus \
    --resource-group rg-cache-prod \
    --location eastus \
    --sku Premium \
    --vm-size P1 \
    --shard-count 3 \
    --zones 1 2 \
    --minimum-tls-version 1.2 \
    --enable-non-ssl-port false \
    --redis-configuration '{"maxmemory-policy":"allkeys-lru"}'

2. Configure Automated RDB Persistence to Blob Storage

# Obtain Blob Storage Primary Connection String
BLOB_CONN=$(az storage account show-connection-string \
    --name stfinancedataprod01 \
    --resource-group rg-data-prod \
    --query connectionString -o tsv)
 
# Enable hourly RDB persistence snapshots
az redis update \
    --name redis-core-production-eastus \
    --resource-group rg-cache-prod \
    --set redisConfiguration.rdb-backup-enabled=true \
          redisConfiguration.rdb-backup-frequency=60 \
          redisConfiguration.rdb-storage-connection-string="${BLOB_CONN}"

3. Deploy Private Endpoint for Redis Cache

REDIS_ID=$(az redis show \
    --name redis-core-production-eastus \
    --resource-group rg-cache-prod \
    --query id -o tsv)
 
# Create Private Endpoint
az network private-endpoint create \
    --name pe-redis-core-prod \
    --resource-group rg-cache-prod \
    --vnet-name vnet-spoke-prod \
    --subnet snet-private-endpoints \
    --private-connection-resource-id "${REDIS_ID}" \
    --group-id redisCache \
    --connection-name conn-pe-redis

4. Test Connectivity via Redis CLI (TLS Mode)

# Retrieve Primary Access Key
REDIS_KEY=$(az redis list-keys \
    --name redis-core-production-eastus \
    --resource-group rg-cache-prod \
    --query primaryKey -o tsv)
 
# Connect via stunnel or redis-cli with TLS enabled
redis-cli -h redis-core-production-eastus.redis.cache.windows.net \
    -p 6380 \
    -a "${REDIS_KEY}" \
    --tls \
    PING
# Output: PONG

4. Quotas, Performance, and Configuration Limits

Parameter / DimensionBasic / StandardPremium TierEnterprise Tier
Max Cache SizeUp to 53 GB (C6)Up to 1.2 TB (10 shards × 120 GB)Up to 2 TB RAM / 4.5 TB Flash
Max Connections20,000Up to 400,000Up to 1,000,000 concurrent conns
Max ShardsN/A (Single shard)1 to 10 shardsDynamic auto-sharding
Max Network Bandwidth1,000 MbpsUp to 10,000 Mbps40+ Gbps dedicated throughput
Backup Frequency (RDB)Not supported15, 30, 60 minutesSnapshot / Continuous
Redis VersionRedis 6.0Redis 6.0 / 7.0Redis Enterprise 7.2

5. Official References & Documentation

6. Realistic Pricing Scenarios

Azure Cache for Redis pricing is billed hourly per cache instance:

  1. Standard Tier (C3 - 13 GB RAM): ~197.10/month).
  2. Premium Tier (P1 - 6 GB RAM per shard): ~$0.56 per hour per shard.
  3. Enterprise Tier (E10 - 12 GB RAM): ~$0.72 per hour.

Scenario A: High-Availability Session & Metadata Cache (Standard Tier)

  • Architecture:
    • Standard C3 instance (13 GB RAM, Primary + Secondary HA replication across zones).
    • Used for web session state, shopping cart caching, and rate limiting.
    • Data transfer: 500 GB egress/month.
  • Monthly Cost Calculation:
    • Cache Compute: 197.10**
    • Egress: Negligible inside VNet ($0.00)
  • Total Monthly Cost: $197.10 / month

Scenario B: High-Throughput E-Commerce Clustered Cache with Persistence

  • Architecture:
    • Premium Tier P2 (13 GB RAM per shard) configured with 4 Shards.
    • Total Memory: .
    • Multi-Zone HA enabled across Zone 1 and Zone 2.
    • Hourly RDB Persistence enabled to Azure Blob Storage ($0.02/GB).
  • Monthly Cost Calculation:
    • Shard Compute: 4 shards × 3,270.40**
    • Storage Snapshot Storage (50 GB blobs): 50 \times \0.02 = \mathbf{$1.00}$
  • Total Monthly Cost: $3,271.40 / month

7. Battle-Tested Nuggets & Production Gotchas

  1. The Basic Tier Has ZERO Availability SLA: Deploying the “Basic” tier in production is a critical vulnerability. The Basic tier consists of a single virtual machine with no replica. Any routine host operating system patch, hypervisor reboot, or physical hardware degradation results in immediate cache downtime and 100% data loss. Always use Standard Tier or higher in production.
  2. Clustered Redis Requires Cluster-Aware Client Libraries: When clustering is enabled on Azure Cache for Redis, the cache does not act as a monolithic Redis server. The client library must understand Redis Cluster topology, inspect MOVED and ASK redirects, and maintain local hash slot routing maps. Legacy libraries (or naive connection wrappers) will throw StackExchange.Redis.RedisServerException: MOVED 12182 10.0.0.5:6380. Ensure your application library (e.g., StackExchange.Redis in .NET, Jedis/Lettuce in Java, redis-py in Python) initializes with cluster-mode enabled.
  3. maxmemory-reserved Setting Prevents Memory OOM Crashes: When Redis memory reaches 100%, background operations like RDB snapshotting, AOF writes, or replication buffer synchronization require additional RAM. If all memory is allocated to data, the OS kills Redis or write operations fail with OOM command not allowed when used memory > 'maxmemory'. Always configure maxmemory-reserved (e.g., 20% of memory) and maxmemory-policy = allkeys-lru to allow graceful eviction.
  4. VNet Injection Deprecation in Favor of Private Endpoints: In older documentation, Redis Premium used legacy “VNet Injection,” which required dedicated subnets and complex NSG rule openings (ports 15000-15001). Microsoft has deprecated VNet injection for Azure Cache for Redis in favor of Azure Private Link & Private Endpoints. Private Endpoints operate over standard subnets with zero custom inbound NSG rules required.
  5. AOF Persistence Severely Degrades Write Throughput: While Append-Only File (AOF) persistence guarantees maximum durability by journaling writes every second, it incurs a 20% to 40% throughput penalty on write-heavy workloads compared to in-memory caching or hourly RDB snapshots. If your cache can survive regenerating state from PostgreSQL or Cosmos DB upon disaster recovery, use RDB snapshots instead of continuous AOF.
  6. Threadpool Starvation in .NET StackExchange.Redis: In .NET applications, a sudden burst of Redis queries can saturate the .NET CLR ThreadPool, resulting in Timeout awaiting response... ThreadPool: (worker: 4, completion: 0). The error message appears to blame Redis latency, but the bottleneck is actually client-side thread starvation waiting to dequeue response bytes. Fix this by pre-allocating ThreadPool threads at application startup (ThreadPool.SetMinThreads(200, 200)).

Across the wiki

Graph View

Backlinks