Seventy percent. When I mention how much we once cut from a cloud infrastructure bill, engineers want the technical story – which services, which tricks, which tool found the waste. The honest answer disappoints them, and then it changes how they look at their own bill: the waste had always been visible. What changed was who felt safe enough to point at it.
The Bill Nobody Owned
Cloud waste is not exotic. Walk through almost any mature cloud estate and the suspects are boringly universal: non-production environments running around the clock for tests that execute twice a day. Compute sized for a peak that was estimated once, years ago, and never revisited. Storage that outlived the project it served. Premium tiers nobody remembers choosing. Redundancy stacked on redundancy because two different teams each added their own “just in case.” None of this hides. It sits in the billing console, itemised, every month.
This is why I treat cost as the fifth question of my four-pillar lens. A system that cannot answer for its throughput, load, scale, and capacity cannot answer for its bill either – because every unanswered question gets settled the same way: with padding. Over-provisioning is what uncertainty looks like when it is converted into infrastructure. The bill is not a finance document. It is an architectural confession.
Why Engineers Stay Silent About Waste They Can See
Here is the uncomfortable part. The engineers closest to a system almost always know where its waste lives. They sized the clusters. They watch the utilisation graphs. So why does the waste survive, year after year? Because every line on that bill has an author – and the author is usually in the room. Pointing at an oversized cluster is never just a technical observation; it can be heard as a criticism of the colleague who sized it, the architect who approved it, the team that depends on its comfort margin. Proposing a simplification means proposing that something someone built should not exist.
In a team without psychological safety, that calculation ends in silence every time. The personal risk of the observation is concrete and immediate; the saving belongs to a budget nobody in the room owns. So the waste compounds – politely, invisibly, expensively. I have written before that cost problems are almost never purely technical. This is the mechanism: they are culture problems that appear on the infrastructure bill.
The waste was always visible. What was missing was the culture that made pointing it out safe.
What Actually Changed
The 70% did not come from a clever tool. It came from deliberately changing three conditions – the same three verbs I keep returning to when I describe that period: engineers became safe to question assumptions, to surface inefficiencies, and to propose unpopular simplifications. Each verb needs its own condition to exist.
Every sizing decision got a birthday, not a tombstone
The most expensive sentence in cloud infrastructure is “that’s how it was sized.” When leadership treats old decisions as revisitable rather than sacred – and asks “what would you delete?” without flinching at the answers – engineers stop defending estimates that nobody believes anymore, including the people who made them.
Waste was separated from authorship
Inefficiency needs a place where it can be said out loud without a name attached to the mistake. The same blameless discipline that makes post-incident reviews work applies to the bill: the question is never “who over-provisioned this?” It is “what does the system need today, and what is it carrying out of habit?”
Someone senior absorbed the politics
A simplification proposal threatens comfort margins, pet architectures, and the quiet pride of whoever built the thing. It only survives if a leader visibly carries that political weight – saying, in effect: the engineer pointed, but I am the one deleting. Without sponsorship, the bravest observation dies in the meeting where it was made.
Notice what is missing from those three cards: any particular technology. That is the point. The technical work – rightsizing, consolidating, deleting – is well documented and largely mechanical once it is allowed to happen. The culture work is what allows it to happen.
What I Will Not Itemise
You will notice I have not named the workloads, the vendor, or the line items. That is deliberate: the bill belonged to an employer, and the discretion belongs to them permanently. The number travels; the itemisation does not. But here is the useful part – you do not need my itemisation. Your own billing console already contains your version of it, and your engineers can already see it. The question this essay leaves you with is not where is the waste. It is: who on your team has seen it, and what happens to them if they say so?