Basic Information
| Field | Details |
|---|---|
| English name | Amazon ElastiCache |
| Full name | Amazon ElastiCache |
| Chinese description | 托管内存缓存 |
| Japanese description | マネージドインメモリキャッシュ |
| Exam frequency | ⭐⭐⭐⭐ |
| Often confused with | DAX / RDS Read Replica / CloudFront / MemoryDB |
In one sentence
ElastiCache moves repeatedly read hot data into memory to reduce database load and response latency.
Core purpose
- A cache hit returns directly; a miss reads from the database and repopulates according to policy.
- Cache-aside is flexible and common; write-through updates cache on writes but adds work to the write path.
- Valkey/Redis OSS offer rich structures and high availability; Memcached is lighter.
Exam focus
- In-memory cache, Redis/Valkey/Memcached, and reduced database load point to ElastiCache.
- DAX is DynamoDB-only; read replicas hold complete databases; CloudFront caches edge HTTP content.
- Design TTL, eviction, invalidation, failure behavior, and stampede protection.
Common misconceptions
- A cache is normally not the durable source of truth.
- Strongly consistent, frequently changing data may not be suitable for caching.
Key takeaway
Repeated reads + hot data + in-memory access → ElastiCache.
Related services
RDS, Aurora, DAX, CloudFront, EC2, Lambda.
Update: caching patterns and security
- With cache-aside, the application reads the database on a miss and fills the cache. Write-through updates the cache when primary data changes.
- TTLs, invalidation, jitter, and request coalescing reduce stale data and cache stampedes.
- Redis OSS/Valkey supports replicas, failover, sorted sets, and richer structures; Memcached is simpler for horizontally sharded ephemeral caches.
- RBAC provides finer authorization than one AUTH token; production designs also need encryption and subnet/security-group isolation.