Where cloud spend actually goes, and the four lines worth reading
Cloud bills are itemised in units nobody thinks in. A team asks why the bill doubled and receives four hundred line items denominated in GB-months and request-units, which is why the usual response is either to accept it or to cut something visible and hope. Both are avoidable with an afternoon of attribution work.
Most cloud overspend is not a pricing problem or a negotiation problem. It is an attribution problem: nobody can say which feature, team or customer causes which part of the bill, so every cost-reduction discussion is conducted on guesses.
The categories that dominate, in the usual order
The observability row deserves a mention because it is self-inflicted and easy to fix. Volume-priced log ingestion means every debug statement left enabled in production has a monthly cost, and a single noisy loop can produce a bill larger than the service it is instrumenting.
Tagging is the prerequisite for every other decision
Without tags, a bill is a total. With tags, it is a set of answers. This is the highest-leverage work available and it is boring, which is why it does not get done.
- Environment — production, staging, development. The first question anyone asks, and frequently unanswerable
- Service or component — so cost can be compared against the value that component delivers
- Owner — a team, not a person who may have left
- Cost centre — where the money is accounted for, if that differs from the owning team
- Lifecycle — temporary resources tagged with an expiry, so they can be found and removed
Distinguish waste from capacity
Not all unused capacity is waste. Conflating the two produces either a bill that never falls or a system with no headroom, and both outcomes come from the same failure to categorise.
The insurance row is the one worth naming explicitly. Redundancy costs money and buys availability; that is a decision, not an inefficiency. What makes it a problem is when nobody knows the figure, because then it cannot be weighed against the availability it delivers.
The reductions available in a single afternoon
- Turn off non-production outside working hours. Development and staging idle for roughly two thirds of every week, and scheduling them is a few lines of automation.
- Delete orphans. Unattached volumes, old snapshots, unused addresses, load balancers with no targets. Every estate has them and they are pure loss.
- Add storage lifecycle rules. Move old objects to colder tiers and expire what has a retention limit, rather than keeping everything at hot-tier pricing forever.
- Cap log ingestion. Sample high-volume debug output and set a retention period, rather than paying to store logs nobody will read.
- Right-size the obvious outliers. Not everything — the three resources whose utilisation is visibly far below their provisioning.
The number that actually matters
Total spend is the wrong headline metric, because it should rise as the business grows. The useful figure is cost per unit of whatever the business counts — per tenant, per thousand requests, per active user, per transaction processed.
- A rising bill with a falling unit cost is a growing business getting more efficient — the good case, and invisible if only the total is tracked
- A flat bill with a rising unit cost means growth is slowing while infrastructure is not — a genuine warning
- A unit cost per tenant makes pricing decisions possible, because you know the floor beneath a plan
- A unit cost per feature makes it possible to notice that one feature consumes a quarter of the bill for a small share of use
That last case is the one worth hunting. A feature whose infrastructure cost is wildly disproportionate to its usage is either mispriced, misbuilt, or should not exist — and it is impossible to identify without both tagging and a usage denominator.
None of this requires a cost-management platform. It requires tags applied at creation, one report of untagged spend, a unit-cost denominator, and someone reading the bill once a month with the authority to act on it.
Questions
What is the first thing to do about a rising cloud bill?
Make it attributable. Tag every resource with environment, service, owner and cost centre at creation time, enforce it with a policy that rejects untagged resources, and drive untagged spend towards zero. Until spend can be traced to a service and an owner, every reduction is a guess and every increase is a mystery — which is why most cost discussions end in cutting something visible and hoping.
Why is data transfer so often a surprise on the bill?
Because inbound is usually free while outbound is not, and traffic between availability zones is frequently charged in both directions. A chatty service split across zones for redundancy can spend more moving bytes between its own halves than on the compute doing the work, and it appears as an opaque transfer line rather than being attributed to the service causing it.
Should we buy reserved capacity to reduce costs?
Only after removing waste. Commitments reduce the rate on usage you promise to keep for one to three years, so buying them first locks in the waste at a discount — which feels like a saving and is actually a commitment to keep spending. Turn off idle non-production, delete orphaned resources, add storage lifecycle rules, then commit to the steady state that remains.
Is total spend the right metric to track?
No — it should rise as the business grows. Track cost per unit of whatever the business counts: per tenant, per thousand requests, per active user. A rising bill with a falling unit cost is a growing business getting more efficient, which is invisible if you only watch the total. A flat bill with a rising unit cost is the genuine warning sign.