Amazon ElastiCache (Redis, Memcached)
Key concepts
Redis vs Memcached
Caching strategies
Cluster mode enabled
Replication groups
Cache-aside pattern
Overview
Amazon ElastiCache is a fully managed in-memory caching service. It runs two engines: Redis (now offered as ElastiCache for Redis and ElastiCache for Valkey, an open-source Redis-compatible fork) and Memcached. An in-memory cache stores frequently accessed data in RAM so applications read it in microseconds instead of querying a slower disk-backed database every time. ElastiCache handles provisioning, patching, failure detection, and recovery so you operate the cache without managing servers.
This topic is high-yield on the SAA-C03 exam through "make this database faster" and "reduce read load" scenarios. You should know when to pick Redis versus Memcached, the common caching strategies (lazy loading and write-through), how cluster mode enabled shards data, what a replication group provides for high availability, and how the cache-aside pattern works end to end.
Microsecond Reads in Front of a Slower Database
ElastiCache puts an in-memory layer between your application and a backing store such as RDS or DynamoDB. Use Redis when you need persistence, replication, failover, or advanced data structures, and Memcached when you want a simple, multi-threaded cache that scales out horizontally.
Map the keyword to the engine. Persistence, replication, Multi-AZ failover, pub/sub, sorted sets, or geospatial means Redis. Simple key-value caching that needs to scale out across many cores and nodes points to Memcached. Cluster mode enabled means sharding across multiple node groups for write scaling and larger datasets.
Key Concepts
Redis vs Memcached
Picking the Engine
Redis (and the Valkey fork) is a feature-rich engine with rich data types (strings, hashes, lists, sets, sorted sets, streams, geospatial), persistence options, replication, automatic failover, backups, and pub/sub messaging. Memcached is a simpler, multi-threaded key-value store with no persistence, no replication, and no failover, designed to scale out by adding nodes and to use multiple CPU cores on a single node. Choose Redis when durability, high availability, or advanced operations matter. Choose Memcached for a plain, large, horizontally scalable cache.
Redis vs Memcached
| Dimension | ElastiCache for Redis | ElastiCache for Memcached |
|---|---|---|
| Data types | Rich (sorted sets, hashes, streams, geo) | Simple key-value |
| Persistence | Yes (snapshots and AOF) | None |
| Replication and failover | Yes (Multi-AZ with automatic failover) | None |
| Multi-threaded | Limited | Yes (uses multiple cores) |
| Backups | Yes | No |
| Pub/sub and transactions | Yes | No |
| Best for | HA, durability, advanced operations | Simple horizontally scaled cache |
Caching Strategies
How Data Gets Into the Cache
A caching strategy defines when the cache is populated and refreshed. Lazy loading (the basis of cache-aside) loads data into the cache only when an application requests it and finds a miss, which keeps the cache small but causes a cache miss penalty on first access and risks stale data. Write-through updates the cache every time the database is written, so reads almost always hit fresh data, at the cost of extra write latency and caching data that may never be read. A TTL (time to live) sets an expiration on each key so stale entries are evicted automatically, and the two strategies are often combined with a TTL.
Lazy Loading vs Write-Through
| Dimension | Lazy Loading (cache-aside) | Write-Through |
|---|---|---|
| When cache is written | On a read miss | On every database write |
| Cache size | Only requested data | All written data |
| Stale data risk | Higher (use a TTL) | Lower |
| Read miss penalty | Yes (first read is slow) | Rare |
| Write latency | Normal | Higher (writes cache plus DB) |
| Best for | Read-heavy, tolerant of first-read latency | Data that must stay fresh on read |
Cache-Aside Pattern
The Cache-Aside Flow
The cache-aside pattern is the most common ElastiCache access pattern and is built on lazy loading. The application checks the cache first. On a cache hit it returns the cached value. On a cache miss it reads from the database, writes the value into the cache (often with a TTL), and returns it. On an update, the application writes the database and either updates or invalidates the cached key so the next read refreshes it. This keeps the application in control of consistency and only caches data that is actually requested.
def get_product(product_id):
key = f"product:{product_id}"
# 1. Try the cache first
cached = redis_client.get(key)
if cached is not None:
return json.loads(cached) # cache hit
# 2. Cache miss: read the backing database
product = db.query_product(product_id)
# 3. Populate the cache with a TTL so it cannot go stale forever
redis_client.set(key, json.dumps(product), ex=300) # 300s TTL
return product
def update_product(product_id, changes):
db.update_product(product_id, changes)
# Invalidate so the next read repopulates from the database
redis_client.delete(f"product:{product_id}")Replication Groups
High Availability for Redis
A replication group (Redis and Valkey only) is a set of nodes where one primary node accepts writes and one or more read replicas asynchronously copy its data. Spreading replicas across Availability Zones and enabling Multi-AZ with automatic failover lets ElastiCache promote a replica to primary if the primary fails, usually within seconds, and update the DNS endpoint automatically. Read replicas also offload read traffic and increase read throughput. Memcached has no replication groups, so a lost node loses its data.
Replication Group Roles
| Role | Accepts writes | Purpose |
|---|---|---|
| Primary node | Yes | Source of truth, handles writes and reads |
| Read replica | No | Offloads reads, candidate for failover |
| Multi-AZ failover | After promotion | Promotes a replica when the primary fails |
Cluster Mode Enabled
Sharding for Scale
With cluster mode disabled, a Redis replication group is a single shard: one primary plus up to five read replicas, so all writes go to one node and the dataset must fit on that node. With cluster mode enabled, data is partitioned across multiple shards (node groups), each with its own primary and replicas. This scales writes and storage horizontally beyond a single node and supports up to 500 shards per cluster. Cluster mode enabled uses a configuration endpoint, and clients must be cluster-aware to route keys to the correct shard.
Cluster Mode Disabled vs Enabled
| Dimension | Cluster Mode Disabled | Cluster Mode Enabled |
|---|---|---|
| Shards (node groups) | One | Up to 500 |
| Write scaling | Single primary | Across many primaries |
| Dataset size | Fits on one node | Partitioned across nodes |
| Read replicas per shard | Up to 5 | Up to 5 |
| Client endpoint | Primary and reader endpoints | Configuration endpoint (cluster-aware client) |
| Best for | Smaller datasets, simpler clients | Large datasets, high write throughput |
Best Practices
1. Match the engine to the requirement
├── Redis or Valkey for persistence, HA, and advanced data types
└── Memcached for a simple, multi-threaded, scale-out cache
2. Use cache-aside (lazy loading) with a TTL
├── Cache only data that is actually requested
└── A TTL bounds staleness from updates that bypass the cache
3. Enable Multi-AZ with automatic failover for Redis
└── Place replicas in separate Availability Zones for resilience
4. Turn on cluster mode enabled when one node is not enough
└── Shard for write scaling and datasets larger than one node
5. Secure the cache
├── Deploy in private subnets with tight security groups
└── Enable encryption in transit, encryption at rest, and Redis AUTH
6. Right-size and monitor
└── Watch evictions, CPU, and memory; scale before eviction thrashCommon Pitfalls
Pitfall 1: Choosing Memcached When High Availability Is Required
Mistake: Selecting Memcached for a workload that must survive node loss and stay available.
Why it fails: Memcached has no replication, no failover, and no persistence, so a failed node loses its cached data with no automatic recovery.
Correct Approach: Use ElastiCache for Redis with a replication group and Multi-AZ automatic failover when availability and durability matter.
Pitfall 2: Lazy Loading Without a TTL
Mistake: Caching on read miss but never expiring keys, while some updates write the database directly.
Why it fails: Cached values drift from the database and serve stale data indefinitely because nothing forces a refresh.
Correct Approach: Set a TTL on cached keys and invalidate or update the relevant key whenever the application writes the database.
Pitfall 3: Expecting Cluster Mode Disabled to Scale Writes
Mistake: Adding read replicas to a single-shard Redis group to handle growing write throughput.
Why it fails: Read replicas only scale reads. All writes still funnel to the one primary, and the dataset must fit on that single node.
Correct Approach: Enable cluster mode enabled to shard data across multiple primaries when writes or data size exceed one node.
Pitfall 4: Caching In Front of the Wrong Workload
Mistake: Putting ElastiCache in front of a write-heavy, low-reuse workload.
Why it fails: Caching pays off when the same data is read far more often than it changes. Constantly churning keys produces misses and overhead with little benefit.
Correct Approach: Cache read-heavy, frequently reused data such as session state, leaderboards, or hot query results.
Test Your Knowledge
An ecommerce site puts ElastiCache in front of an RDS database. The team needs the cache to survive an Availability Zone failure automatically and to back up data nightly. Which choice meets these requirements?
A read-heavy application caches data only when a requested key is missing, then reads from the database and stores the value. Occasionally the database is updated by a batch job that bypasses the cache, and users report stale values. What is the simplest fix?
A Redis workload has grown so the dataset no longer fits on a single node and write throughput is saturating the primary. Read replicas have not helped. What should the architect do?
Related Services
Quick Reference
Limits and Facts
ElastiCache Quick Reference
| Item | Value |
|---|---|
| Engines | Redis, Valkey, Memcached |
| Read replicas per shard (Redis) | Up to 5 |
| Shards per cluster (cluster mode enabled) | Up to 500 |
| Multi-AZ automatic failover | Redis and Valkey only |
| Persistence and backups | Redis and Valkey only |
| Default Redis port | 6379 |
| Default Memcached port | 11211 |
| Most common access pattern | Cache-aside (lazy loading) with a TTL |
Common CLI Commands
# Create a Redis replication group with cluster mode disabled and Multi-AZ
aws elasticache create-replication-group \
--replication-group-id sessions \
--replication-group-description "session cache" \
--engine redis --cache-node-type cache.r7g.large \
--num-cache-clusters 3 \
--automatic-failover-enabled --multi-az-enabled
# Create a Redis cluster with cluster mode enabled (sharded)
aws elasticache create-replication-group \
--replication-group-id catalog \
--replication-group-description "sharded catalog cache" \
--engine redis --cache-node-type cache.r7g.large \
--num-node-groups 4 --replicas-per-node-group 1
# Create a Memcached cluster with multiple nodes
aws elasticache create-cache-cluster \
--cache-cluster-id pagecache \
--engine memcached --cache-node-type cache.r7g.large \
--num-cache-nodes 3
# Describe a replication group to find endpoints
aws elasticache describe-replication-groups \
--replication-group-id sessions