When a cloud bill has grown 40% in a year, the instinct is to look for the thing that caused it. Someone opens the cost explorer, finds the largest line item, and the conversation narrows to that service.
It is almost never one thing. In our experience rising cloud spend is six or seven separate causes compounding, each individually too small to have triggered an investigation, and each requiring a different kind of fix. Which is precisely why the bill kept growing: nothing on the list was ever the biggest problem.
Separating the causes is the actual work. Here are the ones that recur.
1. Provisioning that was sized once
Almost every environment contains resources sized for a launch that has since happened, a load test that has since finished, or a worst case that never arrived. Instance families change, storage tiers improve, and the sizing decision made two years ago is now simply the wrong shape.
This is the cheapest category to fix and the one most often skipped, because it is unglamorous. It is also where the fastest wins are.
2. Environments nobody turned off
Non-production environments accumulate. A staging copy for a migration that finished, a demo environment for a customer who signed, a performance environment used for one week last quarter. Each was created deliberately and none had an owner assigned for decommissioning.
Worth checking specifically: whether non-production runs on the same instance sizes as production, and whether anything non-production runs overnight and at weekends. Both are common and both are pure waste.
3. Storage that only ever grows
Storage is individually cheap, which is exactly why it goes unmanaged. Logs with no retention policy, backups of systems that were retired, snapshots of volumes that no longer exist, and data sitting in a hot tier years after anyone last read it.
The fix is a lifecycle policy, and the reason it does not get applied is that nobody is confident about what is safe to delete. That confidence question is the real blocker, not the configuration.
4. Data movement
Egress and cross-zone transfer are the costs that surprise people, because they do not appear in the architecture diagram. A service in one availability zone chatting continuously with a database in another, a backup crossing a region boundary nightly, an API returning far more data than its callers use.
This category is worth attention out of proportion to its size, because it usually indicates an architectural mismatch rather than a configuration error. The cost is the symptom; the topology is the cause.
5. Managed services bought for convenience
Managed services are often the right call — they remove operational burden that would otherwise cost engineering time. But each one carries a premium, and the premium was justified against the alternative at the time it was chosen.
Some of those decisions no longer hold. A managed service provisioned for a workload that has since shrunk, or one whose operational advantage has been eroded because the team now runs similar infrastructure anyway, is worth re-examining. Not reflexively reversing — re-examining.
6. Architectures that scale cost faster than load
The most expensive category, and the one that cannot be configured away.
Some designs have a cost curve steeper than their load curve. Per-request patterns that fan out to several services. Polling where events would do. Caching that was never added because the load did not require it, so every request reaches the database. A queue consumer that scales out on depth and so runs continuously.
These are the cases where the bill is telling you something true about the design. They need engineering work, they take longer, and they are frequently where most of the growth actually came from.
7. No cost attribution
The meta-cause. If spend cannot be attributed to a team, a product, or a customer, then nobody owns any part of it and every optimization is somebody else's job.
Tagging discipline is boring infrastructure work with no visible output, which is why it is usually absent. It is also the difference between a one-off cleanup and a run rate that stays down, because it is what makes the next increase visible while it is still small.
Sequencing matters more than completeness
The reason this list is worth separating out is that the seven causes have wildly different effort profiles. Right-sizing and switching off idle environments are days of work. Re-architecting a fan-out request pattern is months.
Doing them in the wrong order is how cost programmes lose momentum: the team starts with the largest line item, discovers it needs an architectural change, and the effort stalls before anything has been saved.
Start with the configuration wins, because they fund attention for the rest. Then use the cost attribution work to see clearly. Then take on the architectural causes with a measured baseline behind you.
The number that matters
One closing observation. Most cost exercises report a saving against the previous bill, which flatters the result — some of that reduction would have happened anyway, and some of it will quietly return.
The more useful measure is cost per unit of business activity: per order, per user, per transaction, whatever the business actually counts. That number tells you whether the architecture got more efficient or the traffic just dipped. It is also the only version of the figure that survives the next growth quarter.