The short answer
Cloud bills grow because no single decision causes it. Resources are easy to create and nobody is responsible for deleting them, over-provisioning is invisible without utilisation data, non-production environments run continuously, and data volumes only ever increase. It is an incentives problem: creating a resource is rewarded, removing one is unpaid work with a small chance of blame.
Key takeaways
- No one decision causes it, which is why no one decision fixes it
- Creating resources is rewarded; deleting them is unpaid risk
- Storage and logs grow monotonically unless a policy stops them
- Visibility per team changes behaviour more than any policy document
Part of our guide to FinOps: how to actually reduce a cloud bill.
Ask why a cloud bill went up 40% and you rarely get an answer, because there usually is not one. No decision was made. A hundred small ones were, each individually reasonable.
The mechanism
Creating is easy, deleting is risky. Spinning up an environment takes minutes and is rewarded — it unblocks work. Deleting one takes judgement, carries a small chance of breaking something, and nobody thanks you. The asymmetry is the whole problem in miniature.
Over-provisioning is invisible. Nobody sees CPU utilisation unless they go looking. An instance at 6% looks identical to one at 60% on every dashboard that matters day to day.
Non-production never sleeps. Environments created for a project stay running after the project ends, because switching them off requires someone to be confident nobody needs them.
Storage only grows. Object storage, snapshots, logs and backups accumulate monotonically unless a lifecycle policy removes them. Log retention set to "forever" during an incident three years ago is still costing money today.
Success costs money. More users means more compute, more storage, more transfer. This is the healthy kind of growth, and it is worth separating from the rest — which is precisely what most organisations cannot do, because cost is not attributed to anything.
Why it is an incentives problem
Most engineering teams are measured on delivery and reliability. Neither is served by spending an afternoon working out whether a database can be downsized. The rational individual choice is to leave it alone, and the aggregate result is the bill.
Policies do not fix this on their own. What changes behaviour is visibility with ownership attached: each team seeing its own cost trend, monthly, alongside its own delivery metrics. Once a number has a name against it, it starts moving.
The habits that reverse it
- Tag on creation, enforced. If untagged resources cannot be created, attribution works from day one. Retrospective tagging never fully succeeds.
- Expiry by default on non-production. Environments that shut down on a schedule and require a deliberate action to keep running invert the asymmetry.
- Lifecycle policies on everything that accumulates. Logs, snapshots, object storage. Set the retention deliberately rather than inheriting "forever".
- Anomaly alerting. Catching a change within a day rather than at month end is the difference between a small correction and an argument.
- A recurring review with the people who provision. Thirty minutes a month with engineers, not a quarterly report to finance.
Separating good growth from waste
The goal is not the lowest possible bill. It is knowing which part of the bill is buying something. Cost per customer, per transaction, or per environment tells you whether growth is healthy. Total spend on its own tells you almost nothing — which is why a bill that doubled alongside revenue that tripled is a success, and nobody can prove it without attribution.
