Home / AWS

AWSHow-toIntermediate

ElastiCache for Redis/Valkey high availability: Multi-AZ, replicas and cluster mode

Configure replication groups with automatic failover across AZs, choose cluster mode, test failover and make clients reconnect cleanly, with notes on backups and Global Datastore for DR.

Deepak Bhardwaj2 min read

Applies toAmazon ElastiCache for Redis OSS and Valkey (node-based); ElastiCache Serverless

Options

Option HA behaviour
Single node No failover; node replacement loses cached data
Replication group, Multi-AZ, cluster mode disabled 1 primary + up to 5 replicas; automatic failover to a replica in another AZ
Cluster mode enabled Data sharded over up to 500 shards, each with its own primary and replicas
ElastiCache Serverless Multi-AZ replication and scaling managed for you

1. Create a Multi-AZ replication group

aws elasticache create-replication-group --replication-group-id sessions-prod \
  --replication-group-description "session store" \
  --engine valkey --cache-node-type cache.r7g.large \
  --num-node-groups 1 --replicas-per-node-group 2 \
  --multi-az-enabled --automatic-failover-enabled \
  --cache-subnet-group-name cache-private --security-group-ids sg-cache \
  --transit-encryption-enabled --at-rest-encryption-enabled \
  --snapshot-retention-limit 7 --snapshot-window 19:00-20:00

Put replicas in different AZs from the primary (the subnet group must span 3 AZs).

2. Use the right endpoint

  • Cluster mode disabled: primary endpoint for writes, reader endpoint for reads. Never hard-code node endpoints.
  • Cluster mode enabled: configuration endpoint with a cluster-aware client.

3. Test failover

aws elasticache test-failover --replication-group-id sessions-prod --node-group-id 0001
aws elasticache describe-events --source-type replication-group --source-identifier sessions-prod --duration 60

Failover usually completes in under a minute; the primary endpoint DNS points at the promoted replica.

4. Client settings

  • Connection and command timeouts (for example 1–2 s), and retry with backoff.
  • Reconnect on errors such as READONLY You can't write against a read only replica (seen briefly after failover when a client is still connected to the old primary).
  • Short DNS caching.
  • Cluster clients refresh topology on MOVED/ASK responses.

5. Memory headroom

Set reserved-memory-percent (default 25%) so snapshots and replication buffers don't push the node into swap or evictions during failover and resync.

6. DR

  • Daily snapshots, exportable to S3 and copyable to another region.
  • Global Datastore: cross-region replication with a secondary cluster you can promote (RPO typically under a second; manual promotion).

Note

If Redis is only a cache, the real HA question is whether the database behind it survives a cold cache. Load-test a "cache empty" scenario at least once.

Related fixes