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.