Amazon ElastiCache
Fully managed in-memory cache (Valkey, Redis OSS, Memcached) that serves hot data in microseconds so your database doesn't have to.
Verified against AWS documentation · 2026-09-09
Key facts
- 01In-memory key-value store — a copy of hot data lives in RAM, so repeat reads never touch the database
- 02Memcached: simplest model, multi-threaded, no replication and no backups — lose a node and you lose that slice of cache
- 03Valkey / Redis OSS: replication, Multi-AZ auto-failover, backups, pub/sub, sorted sets — the default pick unless you genuinely want 'just a cache'
- 04Two ways to run it: Serverless (name it, it scales itself) or node-based clusters (you pick node type, count, and AZ placement)
- 05Nothing is cached automatically — your app decides what to store and for how long (TTL); the cache sits inside your VPC, never on the public internet
- 06Exam convention: questions still say "Redis vs Memcached". AWS now leads with Valkey, a Redis fork with the same API — for exam purposes, Valkey and Redis OSS are the same answer
Exam triggers
Phrases and scenarios that point here.
- "Microsecond latency", "in-memory", "read-heavy", "the same query over and over" → ElastiCache
- Database CPU pegged by repeated identical reads → put a cache in front, don't buy a bigger instance
- Session state must survive an instance being terminated → Valkey / Redis OSS, not Memcached
- "Simplest possible cache", "cache objects", "add and remove nodes as demand changes" → Memcached
- Leaderboards, live rankings, real-time counters → Valkey / Redis OSS sorted sets
Not this service
- Caching DynamoDB reads with no application changes → DAX
- Redis-compatible primary database that must not lose data → MemoryDB
- Caching static assets or API responses close to end users → CloudFront
- Scaling relational reads while keeping SQL → RDS read replicas
Use cases
- 01Sitting in front of RDS so the homepage's top-sellers query runs once a minute instead of ten thousand times
- 02Session store for a stateless web tier — any instance behind the load balancer can serve any user, and scaling in doesn't log anyone out
- 03Game leaderboards and live rankings, where a sorted set updates in microseconds and a SQL ORDER BY can't keep up
- 04API rate limiting — increment a counter key per user per minute and let the TTL clean it up for you
- 05Lift-and-shift for an app that already speaks Redis or Memcached: point it at the ElastiCache endpoint and ship, no rewrite
How it's charged
- 01Node-based: billed per node-hour for as long as the node exists — an idle cache costs the same as a busy one, and every replica is a full-price node (3 shards with 1 replica each = 6 nodes on the bill)
- 02Serverless: two meters at once — data stored in GB-hours plus requests in ElastiCache Processing Units (ECPUs, roughly 1 per KB moved)
- 03No scale-to-zero on Serverless — a minimum amount of stored data is always metered, so forgotten dev caches keep billing
- 04Valkey is priced below Redis OSS and Memcached on both models (~20% cheaper node-based, ~33% cheaper Serverless) — same API, lower bill
- 05Reserved Nodes (1 or 3 year) discount node-based clusters; Serverless can't use them and relies on Database Savings Plans instead
- 06Billing surprise: running an engine version past its end of standard support auto-enrols the cache in Extended Support, adding a premium on top of the node rate
