Idle ElastiCache clusters are different from over-provisioned ElastiCache: over-provisioned findings apply to clusters that are receiving connections but have more node capacity than their CPU and memory metrics justify. Idle clusters have near-zero client connections over the last 14 days — a signal the cache may no longer be in use.
Before you delete
- Confirm no applications, background jobs, or session stores still connect to this cluster (including from other VPCs or via VPN).
- Check for replication groups, read replicas, or ElastiCache users and security groups that reference this cluster.
- Understand cache-miss fallback: deleting a cache is safe for correctness, but if applications still run they may fall back to the backing database or API on every request — causing a latency and load spike on that store immediately after removal.
Paid plans include remediation scripts that delete the standalone cluster or replication group. AWS ElastiCache delete commands do not support --dry-run — review commands carefully before running them.
What triggers this finding
An available ElastiCache cluster older than 14 days with fewer than 0.5 average CurrConnections over the last 14 days.
Typical fix
Delete the cluster or replication group if the cache is no longer needed. Confirm no applications still depend on cache-miss fallback to a backing store.
Example savings
Often 100% of node charges — typically $15–$200+/month depending on node type and replica count.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
How ElastiCache nodes are billed
ElastiCache bills node-hours. Every node in the cluster charges its hourly rate for every hour it exists, and nothing about that rate depends on connections, cache hits, keys stored, or bytes served. An empty cache costs exactly what a saturated one of the same size costs. Replicas are full-price nodes too, so a three-node replication group bills three times the per-node rate — which is why Parsivex multiplies the node price by the node count when it estimates the finding.
The prices come from a us-east-1 on-demand table, so figures in other regions are indicative rather than exact. Clusters running a node type that is not in that table are skipped entirely rather than priced by guesswork, so a very new or unusual node type may be genuinely idle and still absent from your report.
Two costs sit outside the estimate: backup storage beyond the free allowance included with each cluster, and cross-AZ data transfer for replication. Both disappear along with the cluster, so the real saving from deleting an idle cache is usually a little higher than the figure shown.
Checking connection history yourself
The detector reads CurrConnections as a daily average over 14 days and flags clusters averaging below 0.5. Ask CloudWatch for the maximum alongside the average, because that single extra statistic is what separates "never used" from "used briefly":
aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache \
--metric-name CurrConnections \
--dimensions Name=CacheClusterId,Value=sessions-prod-001 \
--start-time 2026-07-28T00:00:00Z --end-time 2026-08-11T00:00:00Z \
--period 86400 --statistics Average Maximum
A cluster whose maximum is also near zero has genuinely had no clients for two weeks. A cluster averaging 0.2 with a daily maximum of 30 has a batch job attached to it.
Confirm what you are looking at with the inventory call Parsivex uses, which reports node type, node count, and status in one go:
aws elasticache describe-cache-clusters --show-cache-node-info \
--query 'CacheClusters[].[CacheClusterId,Engine,CacheNodeType,NumCacheNodes,CacheClusterStatus]' \
--output table
Clusters that are not in the available state are never flagged.
Caches that look idle on a 14-day average
Averaging is the honest weakness of this detector. Connections are sampled and averaged across whole days, so short bursts of heavy use vanish into the mean. A nightly job that opens twenty connections for ten minutes averages roughly 0.14 connections per day — comfortably under the threshold, and completely load-bearing once every 24 hours.
The same arithmetic misreads:
- Weekly or monthly reporting caches that carry real traffic for one window and none the rest of the time.
- Warm standby caches kept running so a failover has somewhere to land. Zero connections is the point.
- Pub/Sub brokers and distributed locks, where a handful of long-lived connections and tiny message volumes are normal operation rather than abandonment.
- Caches fronted by a connection pool that reconnects rarely, where the connection count reflects pool size rather than request volume.
In all four cases the finding is arithmetically right and the conclusion is wrong. The Maximum statistic above resolves every one of them in a single command.
Cost and risk of deleting a cache
Deleting a cache destroys its contents. For a Redis or Valkey cluster the only rollback is a final snapshot taken at deletion time, and restoring it produces a new cluster with a new endpoint, so applications need a configuration change to come back either way:
aws elasticache delete-cache-cluster --cache-cluster-id sessions-prod-001 \
--final-snapshot-identifier sessions-prod-001-final
Memcached has no snapshot mechanism at all — deletion is unconditionally final.
The operational risk is not the cache, it is what sits behind it. Anything still reading through this cluster starts missing on every request the moment it disappears, and the full load lands on the database or upstream API at once. For a cache that was genuinely idle this is a non-event; for a cache that was quiet rather than unused, it is an outage in the backing store. Check the backing store's headroom before deleting anything that fronts a production database.
A cheaper middle step exists when you are unsure: leave the cluster in place and scale it down to the smallest node type in its family for one billing cycle. You keep the endpoint, keep the ability to reverse the decision instantly, and still remove most of the cost while you wait for evidence.