Amazon ElastiCache
Amazon ElastiCache — managed in-memory caching with Redis and Memcached. Covers caching patterns, Redis data structures, cluster modes, and cross-cloud equivalents.
Overview
Amazon ElastiCache is AWS's fully managed in-memory caching and data store service. It supports two engines:
| Engine | Best For |
|---|---|
| Redis | Rich data structures, persistence, pub/sub, clustering, session store, leaderboards |
| Memcached | Simple, high-throughput key-value caching; multi-threaded; no persistence |
The primary use case is to reduce latency and offload read pressure from backend databases (RDS, Aurora, DynamoDB) by caching frequently accessed data in memory — serving responses in microseconds to single-digit milliseconds instead of querying the database.
SAA/SAP Tip: When a scenario describes a database under heavy read pressure, slow query response times, or repeated identical queries, the answer almost always involves adding ElastiCache as a caching layer in front of the database.
Redis vs. Memcached
| Feature | Redis | Memcached |
|---|---|---|
| Data structures | Strings, hashes, lists, sets, sorted sets, streams, bitmaps | Strings only |
| Persistence | Yes (RDB snapshots, AOF logs) | No |
| Replication / HA | Yes — Primary + Read Replicas, Multi-AZ automatic failover | No |
| Clustering (horizontal scale-out) | Yes — Redis Cluster mode (sharding) | Yes (client-side sharding) |
| Pub/Sub messaging | Yes | No |
| Lua scripting | Yes | No |
| Transactions | Yes (MULTI/EXEC) | No |
| Multi-threaded | No (single-threaded event loop) | Yes |
| Best suited for | Complex caching, session store, leaderboards, queues | Simple ephemeral cache needing maximum throughput |
Exam Trap: Only Redis supports Multi-AZ automatic failover, persistence, and replication. If a scenario requires HA or data durability for the cache, the answer is Redis, not Memcached.
Caching Strategies
Lazy Loading (Cache-Aside)
The most common pattern. Application checks the cache first; on a cache miss, fetches from the DB and writes the result to the cache.
App → Cache HIT → return cached value
App → Cache MISS → query DB → write to cache → return valuePros: Cache only contains data that is actually requested; cache failure is non-fatal (falls back to DB). Cons: Cache misses add latency (3 round trips). Stale data possible until TTL expires.
Write-Through
Write to both the cache and the database on every write operation.
App → write to DB + write to cache simultaneouslyPros: Cache is always up-to-date; no stale reads. Cons: Write latency increases; cache may fill with data that is never read.
TTL (Time to Live)
Set an expiry on every key. Prevents unbounded cache growth and limits stale data window. Critical for both patterns.
SAA/SAP Tip: Use Lazy Loading + TTL for most read-heavy scenarios. Use Write-Through when stale data is unacceptable (e.g. financial balances, inventory counts).
Redis Cluster Modes
Cluster Mode Disabled (Replication Group)
- 1 primary node + up to 5 read replicas
- All data on every node — single shard, replicated
- Supports Multi-AZ failover: if primary fails, a replica is automatically promoted
- Suitable for workloads that fit within a single node's memory
Cluster Mode Enabled (Sharding)
- Data partitioned across up to 500 shards; each shard has a primary + replicas
- Scales both memory (more shards) and throughput horizontally
- Required when the dataset exceeds a single node's memory
Common Use Cases
| Use Case | Details |
|---|---|
| Database query cache | Cache results of expensive RDS/Aurora SELECT queries; serve subsequent identical requests from memory |
| Session store | Store HTTP session tokens (stateless apps behind Auto Scaling group — sessions persist if an instance is replaced) |
| Leaderboards | Redis Sorted Sets provide O(log N) rank queries — ideal for gaming leaderboards |
| Rate limiting | Redis atomic INCR + EXPIRE to implement sliding-window rate limiters |
| Pub/Sub | Redis Channels for lightweight real-time messaging between services |
| Job queues | Redis Lists as FIFO queues; or use Redis Streams for more durable, consumer-group-based queues |
SAA/SAP Exam Tips
SAA/SAP Tip: For stateless application architectures (EC2 Auto Scaling), session data must be stored outside the instance. ElastiCache Redis is the canonical answer for external session storage.
Exam Trap: ElastiCache cannot replace a database. It is a cache layer — it holds a subset of hot data in memory. If data is not in the cache, the application still needs a persistent database backend.
SAP Tip: ElastiCache for Redis supports Global Datastore — cross-region replication of a Redis cluster for low-latency reads worldwide and cross-region DR.
Cross-Cloud Equivalents
| Provider | Service / Solution | Notes |
|---|---|---|
| AWS | Amazon ElastiCache | Baseline; supports Redis and Memcached |
| Azure | Azure Cache for Redis | Managed Redis only; similar tier structure (Basic, Standard, Premium) |
| GCP | Memorystore | Managed Redis and Memcached; similar feature parity |
| On-Premises | Redis OSS / Memcached | Self-hosted; Redis is the dominant choice; no managed HA without extra tooling |
Pricing Model
- Billed per node-hour (node type determines memory and throughput)
- Multi-AZ / replica nodes billed as separate nodes
- Data transfer charges for cross-AZ replication
Related Services / See Also
- Amazon RDS and Aurora — primary databases that ElastiCache sits in front of
- Amazon DynamoDB and DocumentDB — DynamoDB Accelerator (DAX) is the DynamoDB-native in-memory cache alternative
- Database Performance Fundamentals — IOPS, RAM, caching concepts
AWS Lambda
Serverless compute service — run code without provisioning servers, covering concurrency, cold starts, layers, destinations, and event-driven patterns.
Amazon DynamoDB and DocumentDB
AWS managed NoSQL database services — Amazon DynamoDB (key-value / document) and Amazon DocumentDB (MongoDB-compatible). Covers data models, use cases, scaling, and cross-cloud equivalents.