Amazon ElastiCache
Amazon ElastiCache is a managed in-memory data store. It removes most of the operational work of running a distributed cache — provisioning, monitoring, node replacement and patching — while leaving the engines themselves unmodified, so applications talk to it with their ordinary client libraries.
It is faster than any disk-backed database, including DynamoDB, because the data is in memory. That speed is the point, and it comes with the corresponding trade-off: a cache complements a durable database, it does not replace one.
Engines
Section titled “Engines”ElastiCache runs three engines. AWS renamed the Redis offering Redis OSS when Redis Ltd changed the licence of the upstream project, and added Valkey — the Linux Foundation fork of Redis OSS 7.2 — in October 2024. Valkey is the current default choice for new caches: it is API-compatible with Redis OSS and AWS prices it below the Redis OSS options.
| Memcached | Valkey / Redis OSS | |
|---|---|---|
| Data types | Strings and simple objects only | Strings, lists, sets, sorted sets, hashes, streams, geospatial |
| Role | Cache only | Cache, and capable of standing alone as a data store |
| Threading | Multithreaded, uses large multi-core nodes well | Largely single-threaded per shard, scaled by sharding |
| High availability | No replication, no failover, no Multi-AZ | Replication, automatic failover, Multi-AZ |
| Persistence and backups | None | Snapshots, backup and restore, optional durability |
| Pub/sub | No | Yes |
Choose Memcached when the requirement really is a simple, horizontally scalable object cache and losing the cache contents is harmless. Choose Valkey (or Redis OSS where an existing dependency requires it) when you need any of complex data structures, replication, failover, persistence, pub/sub or encryption — which in practice is most of the time.
Serverless or node-based
Section titled “Serverless or node-based”ElastiCache Serverless creates a highly available cache in under a minute with no nodes, node types or cluster topology to choose. It monitors memory, compute and network use and scales itself, and is compatible with Valkey 7.2 and above, Memcached 1.6.22 and above, and Redis OSS 7.1. This is the option to reach for unless there is a specific reason not to.
Node-based clusters are the alternative when you need fine control: choosing the node type and count, placing nodes across Availability Zones, deciding single-AZ or Multi-AZ, running with or without cluster mode, and controlling when patches are applied. Node-based Valkey clusters can additionally enable durability, persisting data to a Multi-AZ transactional log so the cache survives the loss of every node.
Node-based pricing is per node per hour, so it is a function of node size and how many you run. Serverless is billed on the data stored and the requests served.
What it is used for
Section titled “What it is used for”Session storage. A fleet of web servers behind a load balancer needs somewhere shared to keep session state, so that a request can be served by any instance and a session survives an instance being replaced. This is the archetypal ElastiCache use — the application reads and writes sessions to the cache instead of holding them in local memory, and instances become genuinely disposable. Valkey and Redis OSS are the usual choice here because replication and persistence protect the sessions; Memcached is adequate only if losing every live session is acceptable.
Database offload. Putting a cache in front of an RDS or Aurora instance absorbs repeated reads of the same rows, which lowers load on the database and can allow a smaller instance class. The saving on the database often exceeds the cost of the cache.
Real-time features. Gaming leaderboards (sorted sets), rate limiting and counters, live dashboards, and streaming telemetry that needs a fast landing place before it is processed.
Things to keep in mind
Section titled “Things to keep in mind”- The primary purpose is caching. Data in a cache is expendable unless you have deliberately configured persistence or durability.
- Design for a cold cache: the application must behave correctly, if more slowly, when every read misses.
- A cache in front of a database introduces an invalidation problem. Decide the invalidation strategy — TTL, write-through, or explicit eviction — before shipping.
- ElastiCache is not the only cache in an AWS architecture. Amazon CloudFront caches HTTP responses at edge locations and solves a different problem: distance to the user rather than cost of the query.