ElastiCache
ElastiCache is AWS's managed in-memory caching service for Redis and Memcached, returning frequently accessed data in under 1 millisecond and dramatically reducing read load on RDS or DynamoDB. Unlike DAX, it requires explicit application code to check the cache before falling back to the database, giving more flexibility to cache computed or aggregated results rather than only raw items.
A food-delivery app caches restaurant menu data in ElastiCache Redis using the cache-aside pattern: check Redis first, and on a miss, query RDS, store the result in Redis, then return it — so a menu viewed by 1,000 users in a minute triggers only one RDS query instead of 1,000.
Redis vs Memcached
Redis supports rich data structures (lists, sets, sorted sets), persistence, replication with automatic Multi-AZ failover, and pub/sub — Memcached supports none of these. There's almost no production case where Memcached is the better choice today.
RememberElastiCache is not a transparent proxy — your application must explicitly check the cache and handle the miss path. Plan cache logic into the architecture up front rather than bolting it on after a performance problem appears.
Frequently Asked Questions
How does ElastiCache reduce load on a primary database like RDS?
It sits in front of RDS or DynamoDB as an in-memory layer, serving reads for frequently accessed keys in sub-millisecond time instead of hitting disk-backed storage. Typical patterns are cache-aside (app checks cache, falls back to DB on a miss, then populates the cache) or write-through. Because it's unmanaged in terms of cache logic, engineers can cache expensive aggregate queries or computed results, not just raw row lookups.
What's a common pitfall when using ElastiCache for Redis in production?
Not setting a TTL or eviction policy (like allkeys-lru) leads to memory exhaustion and OOM errors once the cache fills, since Redis without eviction will simply reject writes. Another frequent issue is cache stampede: many requests miss the cache simultaneously after a key expires (e.g. after a deploy flushes it) and all hit the database at once — mitigated with request coalescing or staggered TTLs.