ElastiCacheAmazon ElastiCache
A managed in-memory cache, Valkey, Redis OSS or Memcached, that answers repeated reads from memory so the database behind it does less.
Where ElastiCache takes you5 steps, all open
- I know the problem it solves
- I can picture it
- I know when to choose it
- I can use it in a design
- I can answer an exam question
What & why
Memory in front of the databaseElastiCache runs an in-memory cache for you, so data read again and again comes from memory instead of the database. Choose Valkey, Redis OSS or Memcached, and run it serverless or on nodes you size.
Valkey and Redis OSS do more. They add data structures such as sorted sets, replicas with automatic failover across zones, pub/sub, backups and geospatial data. Memcached is simpler and multithreaded, has no replication, and a node-based Memcached cluster keeps nothing on disk.
Reach for it when
- the same data is read far more often than it changes
- every web server must see the same user sessions
- a leaderboard needs players kept in order by score
- repeated reads are overloading the database
It is the wrong tool when
- the data has no other home: a cache holds copies
- the database is DynamoDB and the code should not change: DAX speaks its API
Mental model
The chef's counterA chef's counter beside the stove. The pantry holds everything, but what goes into every dish sits on the counter, within reach. The first time you need something you walk to the pantry and bring it back; after that it is at hand. Leave it out too long and it goes off.
Source of truthCacheLazy loadingWrite-throughTTLReplicaHow it works
Engine, size, strategy, expiry- Choose an engineValkey or Redis OSS for data structures and failover; Memcached for a plain, multithreaded cache.
- Serverless or nodesServerless scales by itself; a node-based cluster is sized by node type and count.
- Fill it from the applicationThe application decides what goes in: after a miss, on every write, or both.
- Give keys a TTLA time to live makes old copies expire, so the next read fetches a fresh one.
- Engines
- ThreeValkey, Redis OSS, Memcached
- Runs as
- Serverless or nodesyour choice per cache
- A miss
- Three tripscache, database, cache
- Replication
- AsynchronousValkey and Redis OSS
- Failover
- Automaticwith Multi-AZ
- Memcached
- Multithreadedno replicas
- In the cache?
The application asks the cache for the key first. A key past its TTL has been removed, and counts as missing.
- Still current?
Lazy loading writes a key only after a miss; write-through also writes it every time the database changes.
Pick a case to follow the read through each check.
Architecture
A cache beside the databaseThe application talks to both. A cache does not put itself in front of the database; the application reads the cache first and goes to the database on a miss.
Sessions outlive a server. With sessions in the cache rather than on each web server, any server can take any request, and one can be removed without logging anyone out.
A replica in a second zone. With Multi-AZ on, if the primary fails a replica is promoted and the primary endpoint's DNS moves to it, so the application keeps the same address.
Security
Encrypted, authenticated, and only a copyEncrypt in transit and at rest. Traffic to the cache and data written to disk, such as backups, can both be encrypted.
Decide who may connect. Valkey and Redis OSS can require an AUTH token, IAM authentication, or role-based access control with users and user groups.
A cache is a copy. Replication is asynchronous, so a failover can lose the last few writes. Keep anything that must not be lost in a database.
Cost
How you are charged, not what it costs todayServerless charges for data stored, per GB-hour, and for the ElastiCache Processing Units its requests use.
Nodes are charged by the node-hour, by node type; reserved nodes lower the rate for caches that run all the time.
Backup storage for Valkey and Redis OSS snapshots.
Data transfer between EC2 and ElastiCache in the same zone is free; across zones and Regions it is charged.
Prices change, so none are printed here. Check the ElastiCache pricing page on aws.amazon.com.
Comparison
Which engine, which strategy, which cache| Engine | Data | Replicas and failover | On disk | Choose it when |
|---|---|---|---|---|
| Valkey or Redis OSS | Strings, hashes, sorted sets, geospatial, pub/sub | Replicas, automatic failover with Multi-AZ | Backups and restore | Anything beyond a plain cache |
| Memcached | Plain keys and values | None | Nothing, on node-based clusters | A plain cache that scales out and in |
| Strategy | Writes to the cache | Stale data | Costs |
|---|---|---|---|
| Lazy loading | After a miss | Possible, until the key expires | A slow first read, three trips |
| Write-through | On every database write | No | Every write goes twice, and unread data fills the cache |
| Either, with a TTL | As the strategy says | Bounded by the TTL | Expired keys are read again |
| Cache | Fronts | Code changes |
|---|---|---|
| ElastiCache | Any database or API | The application reads and fills it itself |
| DAX | DynamoDB only | Few: it speaks the DynamoDB API |
SAA traps
The phrase in the question, and what it meanssorted sets for a live leaderboardValkey or Redis OSS
Memcached stores plain keys and values only.
a cache with replicas and automatic failover across zonesValkey or Redis OSS with Multi-AZ
Memcached has no replication.
a simple, multithreaded cache that scales out and inMemcached
It is the plainest engine, and it uses several cores.
cached data must never be staleWrite-through
Every database write updates the cache too.
cache only the data that is actually requestedLazy loading
A key is written only after a read misses.
limit how stale lazy-loaded data can getAdd a TTL
Keys expire and are fetched fresh on the next read.
microsecond reads for DynamoDB without changing the applicationDAX, not ElastiCache
With ElastiCache the application manages the cache; DAX speaks the DynamoDB API.
user sessions any web server can readElastiCache
Sessions in a shared cache survive the loss of any one web server.
after a failover, the last few writes were goneExpected: replication is asynchronous
Keep anything that must not be lost in a database.
Scenario
Exam style, marked when you answerA news site on RDS for PostgreSQL slows down at peak because the same articles are read thousands of times a minute. Articles rarely change, and readers may see a copy up to a minute old. The cache must keep serving if a node fails. What should a solutions architect add?
Practice
Fill the gap, the way the challenges workA mobile game's servers, in an Auto Scaling group across two zones, must keep millions of players ranked by score as scores change, and read the top 100 from memory. The ranking needs sorted sets, and a copy in another zone that takes over automatically. What do the game servers update?
Quick revision
The night before the exam- What
- A managed in-memory cache: Valkey, Redis OSS or Memcached.
- Valkey, Redis OSS
- Data structures, replicas, Multi-AZ failover, backups.
- Memcached
- Plain keys, multithreaded, no replication.
- Lazy loading
- Cache after a miss; can go stale; a miss costs
3trips. - Write-through
- Cache on every write; never stale, but every write is doubled.
- TTL
- Bounds staleness; add it to either strategy.
- Failover
- A replica is promoted; asynchronous, so the last writes can be lost.
- DAX instead
- For DynamoDB, with next to no code change.
This whole page is free right now.The AWS library is still being written, so every page of it is open to everyone while that lasts. It becomes a paid bundle later; what you read today costs you nothing.
Checked against
Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.