ElastiCache clusters serving no traffic for 30 days
What does ZopNight detect here?
ZopNight flags an ElastiCache cluster only when 4 separate signals agree over 30 days: near-zero CurrConnections, near-zero CacheHits, near-zero CacheMisses and CPU under 5%. If any one of those series is missing it abstains rather than guessing, because connection count alone over-fires in both directions.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-108 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | elasticache_idle.go |
Where it applies
Why four signals instead of one
Connection count on its own is a bad idle test, in both directions. An application can hold pooled keep-alive connections open to a cache it never actually reads from, so the cluster looks busy and is doing nothing. A short-lived client can drive heavy traffic and hold almost no connections at any instant, so the cluster looks idle and is doing real work.
So the rule requires request volume too. Every GET and SET resolves to either a cache hit or a
cache miss, which makes CacheHits + CacheMisses, a pair ElastiCache reports per cluster, the honest “is anything using this” signal.
CPU is the fourth axis, and it catches the case the other three miss: a cluster burning cycles on replication, snapshotting or key-expiry sweeps is not safely idle even with no clients and no requests.
The exact gates
| Signal | Floor |
|---|---|
CurrConnections | below 1.0 |
CacheHits + CacheMisses | below 1.0 per sample |
CPUUtilization | below 5% average |
| Coverage on every axis | 30 days |
The floors are deliberately “below 1.0” rather than exactly zero. CloudWatch series carry trace non-zero noise, and a hard equality test would let a genuinely idle cluster slip through.
The 30-day coverage requirement is stricter than the platform default of 7. A shorter window cannot prove a month of inactivity, and this rule recommends deleting a datastore.
When it stays silent
If any one of the four series is missing from CloudWatch, the rule has single-axis evidence and abstains. That is a deliberate fail-closed choice: partial evidence for deleting a cache is worse than no finding at all.
Reading CurrConnections and CacheHits
aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache --metric-name CurrConnections --dimensions Name=CacheClusterId,Value=my-cluster --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --period 86400 --statistics Average MaximumRepeat for CacheHits, CacheMisses and CPUUtilization. All four need to be flat.
Before you delete it
Search your application config and Secrets Manager for the cluster endpoint first. A cache with no traffic is sometimes a cache nothing has been pointed at yet. Take a final snapshot, then either delete the cluster or downsize the node type and count if the workload is simply smaller than the cluster it was given.