Explanation
Why the waste happens and who it affects.
A node-based cluster bills for every node, including read replicas, from the time the node is launched until it is terminated, so a cluster that receives no connections and serves no commands costs the same as one under full load.
Unlike an underutilized cluster that can be downsized, an inactive cluster provides no value and can usually be deleted. Inactive caches are easy to miss because a cache is rarely anyone's primary system of record, and multi-node replication groups can make each forgotten cluster expensive. AWS Compute Optimizer produces idle recommendations for ElastiCache (Valkey and Redis OSS), and recommends deleting clusters that are no longer required.
Billing model
The pricing dimensions that drive this cost.
- Node-hours
- On-demand nodes are billed hourly from launch until termination, with each partial node-hour billed as a full hour; every primary and replica node counts
- Serverless caches
- Billed for data stored in GB-hours, with a minimum of 1 GB per cache for Redis OSS and Memcached and 100 MB for Valkey, plus ElastiCache Processing Units (ECPUs) consumed by requests
- Backup storage
- Snapshots are billed per GiB-month ($0.085 per GiB-month in all Regions) and keep billing after a cluster is deleted if they are retained
- Reserved nodes
- A reservation keeps billing for its full term even if the matching cluster is deleted, unless another node in the same family uses it
How to detect
5 checks to find it in your estate.
- Review Compute Optimizer idle recommendations for ElastiCache: a node-based Valkey or Redis OSS cluster is flagged when all nodes show no new connections, engine CPU utilization below 1 percent, and no cache hits, misses, get or set commands over a 14-day lookback
- For ElastiCache Serverless, look for caches with no ElastiCache Processing Units consumed, no current or new connections, and no hits, misses, get or set commands over the same period
- For Memcached clusters, which Compute Optimizer idle recommendations do not cover, check CloudWatch CurrConnections, NewConnections, CmdGet, CmdSet, GetHits and GetMisses per node for sustained inactivity
- Search application configuration, parameter stores and secrets for the cluster endpoint, and check whether any security group still allows clients to reach it
- Check tags, creation date and the last engine or configuration change to identify owners of clusters that appear abandoned
How to fix
5 ways to remove the waste.
- Confirm with the owner that no application uses the cache, then delete the cluster or replication group
- If the data might be needed later, create a final backup when deleting and set a retention decision for it, since backup storage keeps billing
- If the cache is needed only occasionally, consider ElastiCache Serverless, which bills for data stored and requests processed instead of fixed nodes
- If the cluster was covered by reserved nodes, reuse the reservation for another cluster in the same node family and Region rather than leaving it unused
- Add ownership tags and include caches in application decommissioning checklists to prevent recurrence
Documentation
Vendor references for pricing and configuration.