Nobody owns the cloud bill, and it shows

Ask most companies who owns their cloud bill and you get a pause. Finance receives the invoice but cannot read it. Engineering understands it but is not measured on it. The person who set up the account left eighteen months ago. So the bill grows at a steady, unremarkable rate that nobody has to justify, and one day it is a board-level line item.

The reassuring part is that this waste is rarely architectural. In the estates we audit, the majority of recoverable spend comes from a short list of ordinary omissions, and none of them requires rewriting anything.

Where the money actually goes

1. Instances sized for a load test nobody remembers

Somebody sized the production database for a peak that was measured once, during a launch, with a safety multiplier on top. Three years later the traffic pattern is different but the instance is not. Check average CPU and memory utilisation over 30 days: anything sitting consistently under 15% is oversized. Right-sizing is the single largest line item in most first audits.

2. Storage that was never given a lifecycle

Snapshots taken daily and kept forever. Log buckets with no expiry. Volumes detached from instances that were terminated years ago, still billing every month. None of it is visible on a dashboard anybody looks at, because storage growth is gradual by nature.

3. Non-production running at 3am

Staging, QA and development environments typically run 168 hours a week to serve a team that works about 45. Scheduled shutdown outside working hours removes roughly 70% of their cost, and takes an afternoon to implement.

4. On-demand pricing for baseline load

Every cloud provider discounts capacity you commit to in advance, and the discount is substantial. If a workload has run continuously for a year, paying the on-demand rate for it is a choice. The reason it persists is that commitment feels risky to whoever would have to sign it. That is a governance problem, not a technical one.

5. Data transfer nobody modelled

Egress between availability zones, between regions, and out to the internet is charged, and it is the line item most likely to surprise. Chatty services placed in different zones for resilience can quietly generate more transfer cost than compute cost.

6. Managed services bought for convenience, kept out of habit

A managed search cluster, a message queue, a monitoring tier: each was the right call when the team was small and the workload uncertain. Some of them still are. The point is to re-ask the question annually rather than never.

7. Orphans

Unattached IP addresses, idle load balancers, old environments from a proof of concept, duplicate backups from a migration that finished. Individually trivial, collectively meaningful, and they only accumulate.

The order to work in

1. 01Turn on cost allocation tags and get one month of clean data. You cannot fix what you cannot attribute, and doing this first stops the whole exercise being an argument about whose spend it is.
2. 02Delete the orphans. Zero risk, immediate saving, and it builds confidence for the harder steps.
3. 03Schedule non-production shutdown. High saving, low effort, no production risk.
4. 04Apply storage lifecycle rules. Decide retention deliberately, then enforce it automatically.
5. 05Right-size based on 30 days of real utilisation, not on the original estimate.
6. 06Only then buy commitments. Committing to the wrong size for three years locks in the waste rather than removing it.
7. 07Review data transfer patterns, which is the one genuinely architectural item on this list.

The order matters. Teams that start at step six, usually because a vendor offered a discount, commit to their current, unoptimised footprint and lose most of the available saving for the length of the term.

Making it stick

A one-off cleanup regresses within a year unless something changes structurally. Three things keep it from coming back: a named owner for the bill, a monthly report that a non-engineer can read, and cost attribution accurate enough that a team can see the consequence of its own choices. None of that requires a tool purchase.

Cloud spend is not an engineering problem that finance struggles to read. It is an accountability problem that happens to be denominated in instance hours.

When we take on a new cloud environment, this is the first piece of work we do, and the results arrive as a written report with the saving attached to each change.