Why your cloud bill keeps growing
The short answer
Roughly 27% to 30% of cloud spend is wasted, and the FinOps Foundation puts avoidable waste as high as 30% to 50% once unused storage and oversized resources are counted. Idle compute is the largest single category at around 35% of waste, followed by overprovisioned instances at 25%. Smaller companies waste a higher percentage; larger ones waste more money. Flexera's 2026 report found estimated waste rose to 29%, reversing a five-year downward trend.
Where the money actually goes
Idle compute
Development and staging environments running through nights and weekends. Instances spun up for a migration two years ago that nobody switched off. This is consistently the single biggest category of waste.
Overprovisioned resources
An instance sized for a launch-day spike that never came, still running at four percent CPU. Rightsizing against multi-week data is where most of the recoverable money sits.
Storage nobody deleted
Snapshots, old backups, logs with no retention policy, and orphaned volumes left behind by instances that were terminated months ago.
Data transfer
Egress charges that nobody modelled. A chatty architecture moving data between availability zones can cost more than the compute doing the actual work.
The incentive problem nobody fixes
Here is the structural reason waste persists, and it has nothing to do with technology. Engineering performance reviews rarely include cloud cost as a metric.
The developer who ships a feature that overprovisions by ten times is not penalised for it. The developer who spends a day rightsizing infrastructure often gets no recognition for that either. Without changing what gets noticed, behaviour does not change, and the waste regenerates as fast as you clear it.
Cost visibility that stops at the finance team fixes nothing, because the people who create the spend never see the consequence. The single highest-leverage change in most organisations is not a tool. It is showing engineers what their choices cost, in a dashboard they already look at.
What to fix first, in order
This order matters. Committing to reserved capacity before rightsizing locks in the waste.
Turn off non-production environments outside working hours
Scheduled shutdown for development and staging. Usually the single largest saving available, and it takes a day to implement. A staging environment running 168 hours a week when it is used for 45 is paying nearly four times what it needs to.
Find and delete orphans
Unattached volumes, old snapshots, unused IP addresses, load balancers pointing at nothing. None of these show up as a problem, they just quietly bill every month.
Rightsize on real data
Use multi-week p95 CPU and memory rather than averages, because averages hide the peaks that actually determine required capacity. Validate changes in staging before touching production.
Set retention policies
Logs and backups without a retention rule grow forever. Decide how long each class of data needs to live and enforce it automatically rather than by memory.
Tag everything
You cannot allocate cost without tags, and you cannot fix what you cannot allocate. Enforce naming conventions before the estate gets larger, because retrofitting tags across hundreds of resources is miserable work.
Only then look at commitments
Reserved instances and savings plans are real money, but only after the estate is the right size. Committing to oversized resources means paying a discounted rate for capacity you never needed.
Making it a rhythm, not a project
- Someone owns the bill by name, not a department
- Budget alerts configured at a threshold that gives you time to react
- A monthly review of the top five line items, which is enough to catch most problems while they are small
- Cost visible to the engineers who create it, not only to finance
- New environments get a shutdown schedule at creation rather than as an afterthought
Formal cloud cost programmes nearly doubled from 39% to 72% in a single year, which suggests this is becoming standard practice rather than an advanced discipline.
A note on AI and GPU workloads
GPU spend is the fastest-growing cost category in cloud, and most of it goes to inference rather than training. That surprises teams who budgeted for a training run and then discovered the ongoing serving cost dwarfs it.
The same discipline applies, with one addition. An idle GPU instance costs considerably more per hour than an idle CPU instance, so autoscaling and shutdown scheduling matter more here than anywhere else in the estate. Check also whether a smaller model performs adequately, because the difference in serving cost between model sizes is usually larger than the difference in output quality for routine tasks.
From our own deployments
We run our own servers rather than renting managed infrastructure per client, so our version of this discipline is different from a metered cloud bill. The constraint is capacity planning rather than a monthly surprise, and clients can take hosting on our infrastructure as a subscription.
The trade-off is worth stating openly rather than presenting as an advantage. Fixed cost means no bill shock, and it also means the capacity planning and the on-call responsibility sit with us. That suits a client who wants a predictable number and does not want to staff for infrastructure. It suits a client with unpredictable, spiky traffic less well, and we say so.
Frequently asked questions
Want a predictable infrastructure bill?
We run our own servers and clients can take hosting as a subscription, with capacity planning and monitoring included rather than billed by the hour.