Delete idle ElastiCache clusters

A managed cache like ElastiCache is charged for the capacity you reserve, not the work it does. AWS bills it by the node-hour — a fixed amount per node per hour — and that charge is identical whether the cache is handling heavy traffic or sitting completely idle. So a team can switch off the application that used a cache, leave the cache running, and keep paying full price for it every hour with nothing flowing through it. A single mid-sized node is roughly $50 a month; a multi-node cluster is a multiple of that.

This finding flags caches that are demonstrably idle — almost no memory in use, almost no connections, almost no read or write commands over a two-week window. In practice these are caches that were sized generously "to be safe" at launch and never grew into it, or caches stranded after the service that needed them was decommissioned. Each one is a fixed monthly charge that recurs on zero business activity, and because caches live behind the application they're easy to miss in a manual review.

From a budgeting standpoint this category behaves like other orphaned infrastructure: predictable in cost but sticky on the way down, because nobody wants to be the person who deleted the cache that turned out to be load-bearing. The right framing is that an idle cache is an ownership signal as much as a cost signal — it means a provisioned, billing resource has no clear owner who can confirm it's safe to remove. The dollar amount is small per cluster; the discipline gap it exposes is the thing worth tracking.

Sam is the finance partner embedded with the platform team. At the monthly cost review the engineering lead is walking through a flat data-services line, and Sam asks the question that's now standard on the agenda: "How many caches are sitting idle, and what's that costing us a month?" The dashboard says $290 across four ElastiCache clusters — small in absolute terms, but it's been roughly that every month for most of the year, so the cumulative is into the low thousands.

The conversation isn't technical. Sam doesn't ask about node types, Redis versus Valkey, or memory utilisation curves. She asks three things: who owns each cluster, how long it's been idle, and whether anything has connected to it in the last two weeks. The lead pulls the report — every cluster has an owner tag, the oldest has been idle eleven months, and connection counts are flat. That's enough to act. Engineering commits to a cleanup sprint with a one-week deadline; Sam adds a recurring line to the finance pack so the number can't drift back up unnoticed.

Two months later the same line reads $50 — one legitimate staging cache that's idle between releases, with sign-off. Sam knows that's the right floor, and she knows that if it creeps back above $200, ownership tagging is slipping somewhere and that's the conversation, not the dollar amount. The dollars are a leading indicator of a governance gap; the cleanup itself is almost incidental.

The per-resource impact is small and the aggregate is material. Idle caches typically sit in the hundreds-to-low-thousands of dollars a month for a mid-sized estate — call it well under 1% of total cloud spend. Not enough to move quarterly numbers alone, but enough that it keeps landing in the "unexplained variance" bucket every month and finance ends up chasing it across teams instead of focusing on the larger commitments.

The more important point is that this category has no natural floor unless someone enforces one. Unlike compute, there's no stopped state for a cache — the meter only stops on deletion — so an idle cache doesn't decay, it persists at full cost until a human acts. That makes it a pure function of operating discipline: the number is exactly as large as the gap between "service retired" and "someone remembered to delete its cache." When you see this line growing, you're not looking at a usage problem, you're looking at a cleanup-cadence problem.

The third impact is on chargeback credibility. An untagged idle cache is a real cost that can't be assigned to a business unit because the resource has no clear owner — so it gets absorbed centrally or argued about in meetings. Every untagged dollar here weakens the chargeback model. Cleaning these up is less about the dollar saving and more about keeping the cost-allocation report defensible.

Finally, treat it as a leading indicator. Sustained month-over-month growth in idle caches almost always means tagging or lifecycle conventions are slipping — the same drift that predicts bigger waste categories (oversized databases, idle compute, unused load balancers) trending the same way a few months later. Watch it as a signal, not a target to zero out.

Managed caches bill for the capacity you reserve, not the traffic they serve. An idle cache costs exactly the same as a busy one — so a cluster left running after its application retired keeps charging in full, month after month, for doing nothing. At scale across an organisation, that's a recurring drag on the cloud bill from infrastructure the business has already stopped using.

This is a hygiene and accountability issue, not a pricing one. Each flagged cluster is money spent on something with no clear owner and no active value. Cleaning them up is low-risk, immediate-saving work; the more durable outcome is the discipline it sets — every provisioned resource has an owner, a purpose, and a review date, not just a launch date.

At one company the quarterly cloud-cost review used to carry a recurring slide: "$290/month of idle cache infrastructure across 4 clusters." Small number, but it sat there every quarter — sometimes growing, never shrinking. The exec sponsor stopped asking about the dollar figure and started asking about the shape: "Why do we have any of these? Who owns this cache? Why is there no review date?"

Within two quarters the slide changed. The number was no longer the headline; the headline was "every data service has a named owner and a documented review date." The $290 dropped to a residual $50 of intentionally-idle staging caches with sign-off, and the cleanup stopped being an agenda item. The exec hadn't asked engineering to chase dollars — she'd asked them to fix the absence of ownership the dollars exposed. "Zero idle caches" was never the goal; "every resource has an owner and a date" was.

The dollar amount in this category is usually small. It's tracked because its size and trend say something about the discipline underneath. A small, flat, fully-tagged number means working ownership conventions and a normal cleanup cadence. A growing or large number means the inverse — resources provisioned without clear owners or review dates, nobody closing the loop, and almost certainly the same pattern in bigger spend categories that don't show up on the dashboard as cleanly.

There's a second-order risk too. A forgotten data store with stale ownership is as much an audit and security finding as a cost one — an idle Redis still has a network footprint and may still hold data. So this category sits at the intersection of cost, security posture, and operational hygiene. Most CFOs care about the first and most CIOs about the second; both should care about the underlying pattern the trend reveals.