Cloud waste is spend on resources that deliver no value: capacity that is provisioned but idle, instances sized far larger than their workload, infrastructure nobody remembers creating, and data sitting on tiers far more expensive than its access pattern justifies. The widely cited figure is that around 30 percent of cloud spend is wasted, and it has stayed near that level across years of surveys. That stability is the interesting part. If waste were a one-time error, it would shrink as teams matured. The fact that it holds steady means the cloud's own mechanics keep regenerating it.
This article is part of our complete guide to cloud rightsizing and waste elimination, the cluster pillar it links up to. Understanding why the 30 percent exists is what makes the rest of that guide actionable, because each category of waste has a different cause and a different fix.
The 30 percent is not the sign of a sloppy team. It is the predictable result of self-service provisioning, padded defaults, and a cloud bill that grows by accretion. Treating it as a discipline problem misses the point and the fix.
Where the 30 percent actually comes from
The waste is not one big leak but several recurring ones that add up. The largest, on most estates, is over-provisioning: instances and volumes sized for a peak that rarely arrives, or simply chosen one size too large out of caution. The mechanics of this are covered in over-provisioning: why it happens and how to stop it. Close behind is idle capacity, resources that run around the clock but only do work for a fraction of it, the subject of how to find idle cloud resources across providers. Then comes forgotten infrastructure, the zombie resources nobody owns anymore, covered in zombie infrastructure: finding what everyone forgot. Storage waste rounds it out: orphaned disks, old snapshots, and cold data on hot tiers.
| Waste category | What it looks like | Root cause |
|---|---|---|
| Over-provisioning | Instances and volumes too large for the workload | Padded defaults, caution, no feedback loop |
| Idle capacity | Resources running 24/7 but used part-time | No scheduling on non-production |
| Zombie infrastructure | Resources nobody owns or remembers | Self-service with no decommission step |
| Storage bloat | Orphaned disks, old snapshots, cold data on hot tiers | No lifecycle policy |
Want to know your real waste percentage?
Our cloud cost audit measures exactly where your spend leaks across AWS, Azure, GCP and OCI, then hands you a ranked plan to claw it back. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Why it persists despite everyone knowing about it
The reason the 30 percent holds steady is that the cloud's defining feature, self-service elasticity, is also what generates the waste. Any engineer can provision capacity in seconds, with no procurement gate and no obligation to decommission. Resources are easy to create and easy to forget. Defaults are generous because providers would rather you over-provision than hit a limit. And the bill arrives a month later, disconnected from the moment of provisioning, so the feedback loop that would correct the behavior is broken. Each of these is individually reasonable. Together they guarantee that waste regenerates as fast as you clean it.
The cost of a third of the bill
It helps to make the number concrete. On a monthly bill of 477 thousand dollars, a 30 percent waste rate is roughly 143 thousand dollars a month, or over 1.7 million dollars a year, spent on nothing. Even a partial recovery is among the highest-return work an engineering organization can do, because it requires no new product, no new customers, and no new headcount, only the removal of spend that was never doing anything. Our own engagements average a 31 percent reduction in the monthly bill, which lines up closely with the waste figure because cutting waste is precisely where most of that reduction comes from.
How the 30 percent gets clawed back
The recovery is not a single project but a sequence. First you measure, with the inventory work in how to audit a cloud environment for waste, so the 30 percent becomes a ranked list of specific resources rather than an abstract figure. Then you cut, in the order that yields the most for the least risk: rightsize and schedule first, clear the idle and zombie spend, then deal with storage. This is the Cut step of our See, Cut, Lock, Run method. The crucial part is the last one, because waste that is merely cut comes back. Keeping it gone requires the structural fixes in how to stop cloud waste from coming back, which is the only way the 30 percent stops being a permanent tax.
The Cloud Waste Audit Framework is the structured method we use to quantify each waste category and rank it by dollars. It turns the 30 percent figure into a concrete, prioritized plan.
The short version
Roughly a third of cloud spend is wasted, and the figure is stable because self-service provisioning, padded defaults, and a delayed bill keep regenerating it. The waste splits into over-provisioning, idle capacity, zombie infrastructure, and storage bloat, each with its own fix. You claw it back by measuring it, cutting in risk order, and locking the fixes in place so it does not return. When you want the whole sequence run for you, that is what our rightsizing and waste elimination service delivers.