What this protects
The bill that grows while nobody is looking
Cloud waste does not arrive with a purchase order. It builds up a line at a time, until the monthly bill is a cost nobody can justify.
Margin
Every idle instance and orphaned volume is money leaving the business for nothing in return.
Predictable budgeting
A bill that creeps upward without explanation makes planning harder and the finance director nervous.
The owner's time
Waste hides because the people who understand the systems rarely see the invoice. Someone has to own the number.
Waste does not arrive in one big invoice
Nobody signs off a purchase order for an idle server. Cloud waste accumulates quietly: a test environment left running over Christmas, a storage volume attached to a project that finished in March, a database sized for a peak that lasted one week.
Because there is no box to look at, nobody feels the weight. The invoice arrives by email, the growth is gradual, and by the time anyone asks, the cloud bill has become a standing line item that nobody can fully explain.
The usual suspects
Idle compute
Instances sized for a launch that finished months ago, still running because stopping them feels like a risk.
Orphaned storage
Volumes and snapshots attached to nothing, kept forever because deleting data is scarier than paying for it.
Oversized databases
Sized for a peak that happened once. A sensible tier often halves the bill with no change in performance.
Zombie environments
Dev, test and demo setups nobody has logged into since the person who built them left.
Snapshot sprawl
Daily backups kept for three years because the retention policy was never actually agreed.
Data that keeps moving
Workloads chatting across regions every minute, paying egress for a conversation nobody needed.
Why it is hard to see from inside
The people who understand the applications are rarely the people who see the bill, and the person holding the invoice cannot tell which instances are load-bearing. So it goes uncontested.
There is also a version of the problem where the waste is invisible because it is technically in use. An environment that runs overnight for a backup nobody reads is not idle, it is just pointless, and it costs the same either way.
How to find it
- Tag everything by owner, project and environment, or you cannot ask anyone a question
- Look at the bill by service rather than by total, and sort by growth rather than size
- Check utilisation before you check cost, because a busy instance and an idle one look identical on an invoice
- Review commitments once a quarter, not once a panic
- Give someone the job, and let the savings fund their budget
A quarterly routine that takes an afternoon
- Stop anything not used in the last thirty days, and note who complained
- Check resource utilisation across compute, storage and databases
- Delete snapshots and volumes with no attached resource, after a restore test
- Right-size the ten most expensive resources by actual load, not by the original guess
- Confirm reserved capacity still matches what you actually run
- Re-check the data paths between services and regions, because egress adds up
The savings are real, but so is the discipline
You can usually find a meaningful slice of the bill in the first afternoon, and then the easy work is done. Keeping it gone needs a habit: tags that stay accurate, a regular review, and someone who owns the number.
Be honest about the trade-off too. Shutting off a test environment saves money and slows the next project down. The point is not to cut everything, it is to know what you are paying for and choose it deliberately. And if you only run a handful of servers, the bill is probably too small to be worth chasing. Spend the afternoon on something else.
What to do about it
- Tag by owner and environment first, or every cost conversation stalls on \"who owns this?\"
- Sort the bill by growth, not size. The fastest-rising line is usually the accident.
- Do not tidy up once and move on, or the waste creeps straight back.
- Right-size by measured load, not by the number someone guessed when it was built.
Questions we get asked about this
How much can we realistically save?
It varies enormously, which is why we size it rather than promise a percentage. In most environments the first review finds something worth stopping, usually within one afternoon of looking.
Will right-sizing slow our systems down during busy periods?
No, if the sizing is based on actual load rather than guesswork. We look at real utilisation over time and keep headroom for the peaks that genuinely happen.
We are only about twenty people. Is cloud waste really our problem?
Sometimes, sometimes not. If the monthly bill is small, chasing it can cost more in time than it saves. It becomes worth doing properly once you run several environments or the bill climbs faster than your headcount.