Why cloud waste hides in plain sight

Ask an engineering team where their cloud money goes and you will usually get a confident answer. It is usually wrong, but not in the way you would expect. The answer is rarely wrong about the big things. It is wrong about the small ones, because nobody has ever added them up.

The shape of the problem

Cloud waste is not typically one runaway cluster. It is a long tail:

• a few dozen unattached volumes, left behind by instances terminated months ago
• load balancers still provisioned for services that were merged away
• a NAT gateway carrying traffic between two subnets that could have talked directly
• development databases running at production sizes because they were cloned from one
• storage in the wrong class, quietly, for years

Individually, none of these is worth an afternoon. That is precisely the mechanism. A $40/month orphaned resource will never be anybody's priority, and two hundred of them is $96,000 a year.

Why the usual tooling misses it

The standard cost tool answers "what did we spend?" — broken down by service, by account, by tag. That view has a structural blind spot: it aggregates.

Aggregation is exactly the wrong operation for a long tail. Two hundred resources, each below the threshold of interest, roll up into one line item that looks entirely reasonable. "EC2: $210,000" tells you nothing about whether it should have been $150,000.

To find the tail you have to go the other way — down to the individual resource, with enough context to say not just what it costs but whether it should exist. That means putting three things side by side that usually live in three different places: billing data, resource configuration, and utilisation metrics.

The tagging trap

The instinctive fix is a tagging policy. Tag everything, then the aggregation becomes meaningful.

It is a reasonable instinct and it works, eventually, for new resources. It does nothing about the existing tail, because the resources that are wasting money are disproportionately the ones nobody has thought about — and nobody has thought about their tags either.

Tag coverage is a genuinely useful metric. It is a leading indicator for future accountability. It is not a way to find current waste, and treating it as one delays the actual work by about a quarter.

What actually moves the number

Three observations from looking at a lot of accounts:

Start with what has no owner to consult. Orphaned and idle resources are the largest single bucket in most accounts and the only one where the change requires no conversation about performance. There is nothing to preserve, so there is nothing to argue about.

Fix it where it is defined, not where it runs. A change made in the console against infrastructure that is managed as code will be reverted by the next apply. The saving lasts until the next deployment, which makes it feel like the work did not stick — because it did not.

Group the work the way a person would do it. Twelve tickets for twelve volumes in one account is twelve context switches for one afternoon's work. One ticket, twelve resources, gets done. Ticket granularity is a real variable in whether a backlog gets read at all.

The number to hold yourself to

Industry estimates put waste at 30–40% of a typical cloud bill, and a focused effort commonly recovers 20–40% of spend. Those are wide ranges, and they should be treated with suspicion until they are grounded in your own account.

The useful version of the question is not "how much do we waste?" It is: how much did we actually stop paying last quarter, and which specific completed piece of work does each dollar of that trace back to?

If that question is answerable, the programme is working. If the only evidence is that the bill went down, the honest answer is that you do not know yet — seasonality explains a great deal, and it explains it flatteringly.