Key takeaways
- Most savings come from deleting unused resources and right-sizing, not from renegotiating anything.
- Cut in order of reversibility: idle first, schedules second, sizing third, commitments last.
- Never buy long commitments before right-sizing — it locks in your waste for years.
- Without tagging and per-team budgets, the bill returns to where it was within two quarters.
Why bills drift upward
Nothing in a cloud account gets cheaper on its own. Environments are created for a test and never destroyed, instances are sized for a launch-day spike that never came, and storage accumulates because deleting it feels riskier than paying for it. Each decision was reasonable in isolation; the total is not.
The structural problem is that the person who provisions a resource is rarely the person who sees the invoice, and the invoice arrives a month later as one number with no names attached. Until that feedback loop is closed, optimisation is a project you repeat annually rather than a property of how you work.
Where the money usually is
In almost every audit, the same categories account for the majority of recoverable spend. They are worth checking in this order because that is roughly the order of size.
- Idle and orphaned resources — unattached volumes, stopped instances still holding storage, years of snapshots, unused load balancers and reserved IPs doing nothing.
- Oversized compute — instances running at single-digit CPU utilisation around the clock because they were sized from a guess.
- Non-production running 24/7 — staging, test and demo environments that are only used during office hours, which is roughly a quarter of the week.
- Storage in the wrong tier — logs, backups and media sitting on hot storage for years when nothing has read them since the month they were written.
- Data transfer — cross-zone and egress charges caused by architecture rather than by demand, and often invisible until you look at the line item specifically.
- Forgotten managed services — a database, search cluster or queue spun up for a project that ended, still running because nothing obviously breaks when it does.
The hardest one to find
Over-provisioned databases are the single most commonly missed item, because they are the resource teams are most nervous about touching. They are also frequently the largest line on the bill. Reading actual connection counts, IOPS and memory use over a month usually shows a much smaller instance would do, and the change is reversible.
The safe order to cut in
Order matters, because the risk attached to each of these actions differs by an order of magnitude.
- Delete what nothing is using. Snapshot first, then remove orphaned disks, stale images and idle endpoints. Near-zero risk, immediate saving.
- Schedule non-production to shut down outside working hours. Often a double-digit percentage of the total bill, and reversible with a switch.
- Move cold data to cheaper storage tiers using lifecycle policies rather than manual clean-ups, so it keeps working without anyone remembering to do it.
- Right-size compute using two to four weeks of utilisation data, one workload at a time, with a documented rollback.
- Fix the architecture causing transfer charges — co-locate chatty services, add caching, review egress paths and CDN configuration.
- Only now buy commitments or reserved capacity, against the baseline you have just established.
Committing before right-sizing locks in your waste for one to three years. It is the most common and most expensive sequencing mistake in cloud cost work.
Commitments versus flexibility
Discounted commitments are genuinely worth having — for the portion of your load that is genuinely stable. The judgement is about how much of your usage is a floor rather than a peak.
A workable rule of thumb: commit to the floor of your last three months of steady-state usage, and serve everything above that on demand. That captures most of the discount while leaving room for the architecture to change.
- If your product is still changing shape monthly, prefer shorter terms and accept the smaller discount.
- Favour flexible commitment types that apply across instance families over ones tied to a specific machine type you may outgrow.
- Diary the expiry dates. Auto-renewing a commitment built around last year’s architecture is a slow, quiet waste.
Making it stick
A one-off clean-up buys you two good quarters. Keeping the saving requires changing who sees the number.
- Tag every resource with an owner, environment and project, and reject untagged resources automatically at creation.
- Publish a monthly cost report broken down per team or product, so the number has an audience who can act on it.
- Set budget alerts on anomalies, not just on totals — a 40% week-on-week jump matters long before month end.
- Review the top ten line items once a quarter. It takes an hour and catches most of the drift.
- Put a cost estimate in the template for any proposal to add infrastructure, so the trade-off is visible at the decision, not on the invoice.
None of that requires a dedicated platform team. It requires the bill to be somebody’s named responsibility, reviewed on a schedule.
Frequently asked questions
How much can we realistically save?
On an account that has never been reviewed, 20–40% is a common range without changing what the business can do. On a well-managed account, single digits — and there the work is about keeping it that way.
Will cutting costs make things less reliable?
Only if you cut in the wrong order. Deleting unused resources and scheduling test environments carries no production risk. Right-sizing needs utilisation data and a rollback plan, which is why it comes fourth rather than first.
Do we need a dedicated cloud cost tool?
Not to begin with. Native billing tools plus tagging discipline will find most of the first-round savings. Tooling earns its place once spend, account count and team count grow enough that manual review stops being practical.
Is reserved capacity always cheaper?
Only for load you will genuinely still be running at the end of the term. An unused commitment is more expensive than on-demand, which is why the baseline calculation matters more than the headline discount.