The bill went up again. Nobody can point at a change that explains it, the graph has been going in one direction for four quarters, and someone in a meeting has now said the words "why don't we just move off AWS."
Before that conversation goes anywhere: most AWS bills contain a fifth of pure waste that costs nothing in risk to remove. Not architecture. Not resilience. Waste — things running that nothing uses. The reason it's still there is that nobody owns the bill, and the reason it feels dangerous to touch is that nobody's sure what's load-bearing.
That uncertainty is the actual problem. The spend is a symptom.
The order matters more than the techniques
Every AWS cost list on the internet is roughly the same list. What separates a safe 20% from an outage is the sequence — because the cheap wins carry no risk and the deep wins carry a lot, and doing them in the wrong order is how cost programmes end in an incident and a rollback.
- See it Tag, attribute, and find out what's actually driving spend
- Delete waste Things nothing uses. Zero risk, immediate saving
- Right-size Match provisioned to observed. Low risk, needs data
- Commit Savings Plans and reservations on the steady-state floor
- Re-architect Real savings, real risk. Last, and only with evidence
Each stage costs more risk than the one before it. Stop when the savings stop being worth the risk — most teams should stop earlier than they think.
Teams reliably start at the last stage, because it's the interesting one.
Stage 1: you can't cut what you can't see
If you can't attribute spend to a team, an environment, or a customer, every subsequent decision is a guess wearing a spreadsheet.
- Tag everything by environment, service and owner — then find what's untagged, because that's where the surprises live
- Split production from non-production in the reporting. Most teams are shocked by the ratio
- Find the top ten line items. It's almost always more concentrated than anyone expects
- Check data transfer specifically. It hides in the bill and it's frequently an architecture bug rather than a cost problem
The single most useful number: what percentage of your bill is non-production? If dev and staging are more than about a quarter of production, you've found your first win and it carries no customer risk at all.
Stage 2: delete what nothing uses
This is the free money, and it's genuinely free — the only reason it's still on the bill is that deleting things feels scarier than paying for them.
- Unattached EBS volumes and old snapshots. Storage from instances terminated years ago, still billing monthly.
- Idle load balancers and NAT gateways. They cost money to exist, not to be used.
- Non-production running at 3am on a Sunday. Dev and staging don't need a night shift. Scheduling them off outside business hours is a large saving for a small amount of work.
- Orphaned Elastic IPs. Charged specifically for being reserved and unused.
- Old log data on hot storage. Nobody queries last year's logs at hot-storage prices. Lifecycle it.
- Whole environments nobody remembers. The proof-of-concept from 2023. The account someone opened for a customer trial.
None of this touches production. If it feels risky, that's not because it is risky — it's because your environment isn't documented well enough for you to be sure. That's the finding, and it's more valuable than the saving.
Stage 3: right-size against observed reality
Provisioning is set once, at the moment of most uncertainty, and then never revisited. It's almost always wrong in the same direction.
The discipline: make changes against observed data, not against the shape of the graph you're worried about. Look at real utilisation over a real period including a real peak. Then move one thing, watch it, and move the next.
Right-sizing databases is where cost programmes hurt people. RDS is often the biggest line item and the most tempting target — and it's also the one where getting it wrong shows up as customer-visible latency under a load pattern you didn't test for. Right-size compute first. Come back to the database with a proper picture of your peak.
Stage 4: commit to what you know you'll use
Once the waste is gone and the sizes are right, you're paying on-demand prices for a workload floor that never goes away. Savings Plans and Reserved Instances discount that floor substantially for a commitment.
The rule: commit to the floor, never the peak. Work out the capacity you genuinely never drop below, commit to that, and let the variable part stay on-demand. Committing before stages 2 and 3 means locking in a discount on waste — which is how teams end up with a three-year commitment to servers they should have deleted.
Stage 5: re-architect, last
This is where the big numbers are and where the risk lives. Moving to containers, changing storage classes, re-working data transfer paths, reconsidering multi-AZ.
By all means. But do it with evidence, and notice that stages 1–4 have already told you where — because you now know what's actually expensive rather than what feels expensive.
Where cost cutting starts buying risk
The line is clearer than people think. You've crossed it when the saving comes from removing a thing whose entire job is to be there when something goes wrong:
- Backups, and — more often — backup testing
- Multi-AZ on the database that would take a week to rebuild
- Monitoring and log retention (the first thing cut, and the thing you need at 3am)
- The capacity headroom that absorbs your actual peak rather than your average
These aren't costs. They're the price of the reliability you've already promised someone in a contract. Cutting them isn't a saving, it's an undisclosed loan against an incident.
A test that settles most arguments: for each proposed cut, name the failure it makes more likely and who notices. If nobody notices, cut it. If a customer notices, you're not saving money — you're changing your risk position, and that's a different decision with different people in the room.
What 20% looked like in practice
We audited AWS spend for a global cybersecurity enterprise running a fleet of more than 70 servers across the UK, US and Australia — an environment already under SOC 2 obligations, which is to say one where "just turn it off and see" was not available.
Resource requirements came down 20%, with no impact to uptime or SLAs.
The part worth copying isn't the number, it's where it came from: not a re-architecture, not a migration off AWS. Baseline automation with Chef and Ubuntu Pro made the fleet consistent and reproducible first — and once every server was built the same way, the ones that shouldn't exist became obvious. The saving was a side effect of knowing what you have.
That's the pattern almost every time. The bill is high because the environment is unclear. Fix the clarity and the number moves on its own.
Frequently asked questions
Work in order: attribute the spend, delete what nothing uses, right-size against observed utilisation, commit to your steady-state floor, and only then consider re-architecting. The first two stages carry no customer risk and typically recover most of the available saving.
Around 20% is a common result from waste removal and right-sizing alone, without architectural change — that's what we achieved for a 70+ server fleet with no impact to uptime or SLAs. Bills that have never been reviewed often have more. Anyone quoting a number before looking at your bill is guessing.
Shutting non-production environments outside business hours, and deleting unattached EBS volumes and old snapshots. Both are same-week changes that don't touch production.
Yes, but not first. Clean up waste and right-size before committing, or you'll lock in a multi-year discount on resources you should have deleted. Commit to the floor you never drop below, not to your peak.
Rarely, and it's usually the wrong response to a bill nobody has reviewed. A migration is a large, risky project justified against a number you haven't yet audited. Find out what the 20% of waste is first — the answer sometimes removes the reason for the migration entirely.
Find the 20% before you re-architect anything
An AWS cost review that separates the free wins from the changes that buy risk.
Related reading
- AWS Cost Optimisation Review — the costed version of this sequence
- DevOps Consulting — who owns the bill afterwards
- Signs your infrastructure isn't ready for growth — the cost curve as a symptom
- The real cost of downtime — the other end of the cost-versus-reliability trade