ElastiCache Redis Replication Groups and Cluster Mode

An ElastiCache Replication Group is a logical grouping of one primary Redis node and up to 5 read replicas. The primary node handles all write operations; replicas receive asynchronous replication from the primary and serve read traffic. Replication groups enable two key capabilities: read scaling (distribute read requests across multiple replicas) and high availability with automatic failover (promote a replica to primary if the primary fails). All nodes in a replication group share the same dataset.

ElastiCache provides two DNS endpoints for a replication group: the primary endpoint always points to the current primary node (automatically updated during failover) — use this for all write operations. The reader endpoint load-balances read requests across all available replicas — use this for read operations to distribute load. Your application should maintain two connection pools: one for the primary endpoint for writes and one for the reader endpoint for reads. This is the recommended connection pattern for ElastiCache Redis replication groups.

When the primary node fails (detected by ElastiCache within seconds via health checks), automatic failover selects one of the read replicas to promote to primary. The promotion process: (1) the selected replica is promoted to primary, (2) the primary endpoint DNS record is updated to point to the new primary (TTL ~1 second), (3) the old primary is replaced with a new replica. Total failover time is typically 30-60 seconds. Applications using the primary endpoint DNS reconnect automatically once DNS propagates — no hardcoded IP addresses needed.

For maximum resilience, distribute replicas across multiple Availability Zones. When you enable Multi-AZ on a replication group, ElastiCache automatically places the primary and replicas in different AZs. If an entire AZ goes offline, failover promotes a replica from a surviving AZ. You can also explicitly specify the preferred AZs for each node when creating the replication group using the --preferred-cache-cluster-a-zs option.

Redis Cluster Mode Enabled (CME) partitions the dataset across multiple node groups (shards), each containing a primary and up to 5 replicas. This is Redis's horizontal sharding solution. Cluster Mode allows you to exceed the memory of a single node — you can have up to 500 node groups each with 500 GB, allowing a single Redis cluster to hold up to 500 × 500 GB = 250 TB of data. Cluster Mode also multiplies write throughput since each node group independently processes writes for its key range.

Redis Cluster Mode divides the key space into 16,384 hash slots. Each node group owns a contiguous range of hash slots. When a key is written, Redis computes CRC16(key) % 16384 to determine the hash slot and thus the node group responsible. Your application must use a cluster-aware Redis client (like redis-py-cluster or Jedis in cluster mode) that knows the slot map and routes each command to the correct node. Standard clients will return MOVED redirection errors if they send a key to the wrong shard.

For the SAA-C03 exam, choose non-cluster mode when: your data fits on a single node (< ~400 GB after headroom), you need simple primary/replica setup, or your application uses complex multi-key operations (transactions spanning multiple keys require all keys to be on the same slot). Choose cluster mode when: your dataset exceeds a single node's memory, you need horizontal write throughput scaling, or you anticipate future growth that will require online resharding. Cluster mode supports adding shards without downtime (online resharding).

ElastiCache Global Datastore extends Redis replication across multiple AWS Regions. You designate one Region as the primary cluster and add secondary clusters in other Regions. Writes go to the primary; secondaries receive asynchronous replication with typical lag under 1 second. Secondary clusters can serve local reads with very low latency. Global Datastore enables global applications where users in different continents read from the nearest Region and cross-region DR where you can promote a secondary cluster to primary if the primary Region fails.

In a non-clustered Redis replication group, pub/sub messages are distributed to all replicas — any subscriber on any node receives messages published to a channel. However, in Cluster Mode, pub/sub is limited to keyspace notifications and channel-based pub/sub only works within a single shard unless you use Redis 7+ with Pub/Sub sharding (SSUBSCRIBE / SPUBLISH for shard-aware pub/sub). This is an important limitation when designing pub/sub at scale with cluster mode.

Monitor the ReplicationLag CloudWatch metric on read replicas to ensure they are keeping up with the primary. A lag above a few seconds indicates a bottleneck on the replica (overloaded node, network issues, or too many writes for the replica to process). In global datastore scenarios, monitor GlobalDatastoreReplicationLag. High replication lag means read replicas may return stale data — important for applications that expect eventual consistency within tight bounds.

You can scale vertically (change node type) or scale horizontally (add or remove replicas). Changing node type requires a modify-replication-group call and causes a brief failover when applied immediately — the primary is replaced with a new node of the new type. Adding replicas is online with no downtime. When scaling from non-cluster to cluster mode, you must create a new cluster-mode group and migrate — there is no in-place conversion between cluster and non-cluster mode.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: replication groups provide read scaling via replicas and high availability via automatic failover with primary/reader endpoints, Cluster Mode shards data across up to 500 node groups using 16,384 hash slots to scale horizontally beyond a single node's memory, and Global Datastore replicates data across Regions for global low-latency reads and cross-region DR. Next up we explore caching strategies: lazy loading and write-through.