The idle Redis problem: finding zero-traffic caches across AWS, GCP and Azure

A cache rarely throws an alert when it goes idle — it simply stops being asked anything. Connection counts drop to near zero, but the instance keeps running, and nobody notices because nothing breaks.

They also span teams: one squad provisions a Redis for a feature that later ships differently, and the cluster outlives the decision that created it.

The cleanest idle signal is client connections over time. A cache averaging near-zero connections for a sustained window is almost certainly orphaned. CPU and cache-hit metrics corroborate, but connections are the strongest first cut.

On AWS, watch ElastiCache CurrConnections; on GCP, Memorystore connected_clients; on Azure, Cache for Redis connectedclients. The pattern is identical across clouds — only the metric name changes.

Confirm no application depends on it (check VPC/security-group references and recent deploys), then delete it. If it must stay for failover or a rare path, downscale to the smallest node type or fewest nodes that satisfies the requirement.

AWS ElastiCache is priced per node-hour by node type; Memorystore and Azure Cache bill by provisioned memory. Either way, an idle cluster is full price for zero value.