Amazon ElastiCache
ElastiCache
You need an in-memory database to cache slow queries, store user sessions, and reduce backend database load.
Reach for it when
- Caching frequently accessed SQL database queries to reduce application response times to sub-milliseconds.
- Storing transient user session state and shopping carts for high-traffic web applications.
- Implementing pub/sub message brokers or rate limit counters across distributed services.
Do not reach for it when
- Storing primary application data that requires permanent persistence and complex relationships — use RDS instead.
- Building serverless apps where database connections scale instantly without connection pool management — use DynamoDB instead.
- Caching static assets, images, or files delivered to public web clients — use CloudFront instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| DynamoDB (with DAX) | Choose it when you need an in-memory cache directly integrated with your DynamoDB tables. |
| MemoryDB | Choose it when you require Redis compatibility with durable, multi-AZ data persistence. |
How you pay
- The model
- Pay hourly per node based on instance type and size, plus data transfer fees.
- The line item that surprises people
- Leaving idle cache nodes running with high memory limits will bill continuously regardless of usage.
What trips people up
- ElastiCache does not offer native database connection pooling; client connections must be managed by the application.
- Redis cluster resizing can experience latency spikes or replication failures if the node CPU utilization is too high.
- Standard ElastiCache nodes do not write to persistent storage; a node reboot will wipe all cached data.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.