ElastiCache clusters with no connections, no cache lookups and under 5% CPU for 30 days

Cache nodes bill by the hour whether or not anything reads them

ElastiCache pricing bills On-Demand nodes hourly from launch until termination, with each partial node-hour counted as a full hour. A cache left behind by a retired service, or created for a load test, costs the same as one handling production traffic. Caches also tend to be sized generously, so a forgotten one is rarely cheap.

Proving a cache is unused

aws elasticache describe-cache-clusters --show-cache-node-info \
  --query 'CacheClusters[].[CacheClusterId,CacheNodeType,NumCacheNodes,ReplicationGroupId]'

aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache --metric-name CacheHits \
  --dimensions Name=CacheClusterId,Value=my-cache-001 \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \
  --period 86400 --statistics Sum Maximum

Run the same for CacheMisses, CurrConnections and CPUUtilization. AWS notes that on Valkey and Redis OSS, ElastiCache itself uses 4 to 6 connections to monitor the cluster, so hits and misses are the clearer signal of real use when you check by hand.

Four quiet signals, all required

The rule looks at four CloudWatch metrics for the cluster over 30 days:

• CurrConnections below 1;
• CacheHits below 1;
• CacheMisses below 1;
• CPUUtilization below 5%.

Each must hold on both the average and the maximum, and each series must cover the full 30 days. The cluster also needs a resolved monthly cost, from node type rate times node count.

Any doubt means no finding

If one of the four metrics is missing, covers less than 30 days, or rises above its floor even once at peak, the cluster is left alone. That makes the rule strict: a single client holding a connection is enough to keep a cluster off the list, and on Valkey and Redis OSS the monitoring connections AWS describes can do the same. A cache that is used but oversized is a rightsizing question rather than an idle one.

The saving is the whole cluster

saving = node type hourly rate x node count x 730
cost after deletion = 0

Removing an idle cache

1. Search application configuration and secrets for the cluster endpoint.
2. Take a final backup where the engine supports it.
3. Delete a replication group with a final snapshot: aws elasticache delete-replication-group --replication-group-id my-cache --final-snapshot-identifier my-cache-final
4. For a standalone node cluster, use aws elasticache delete-cache-cluster --cache-cluster-id my-cache-001.