Most AWS overspend comes from five places: instances sized for a peak that never arrives, storage nobody deleted, non-production environments running overnight and at weekends, data transfer nobody designed, and managed services chosen for convenience at a scale where they stopped being economical. All five are recoverable without reducing what the system can do.
Here is the order we check them.
1. Compute sized for an imagined peak
Instances are usually sized during a nervous first launch and never revisited. The result is a fleet running at 8% CPU with headroom for traffic that never came.
Check average and p99 utilisation over ninety days rather than a week. Right-size against p99 plus a margin, then move steady-state workloads onto committed pricing. Reserved capacity and savings plans reduce cost substantially for workloads that genuinely run continuously — and only for those, which is why right-sizing comes first.
2. Storage nobody deleted
Storage grows and nothing removes it. Old snapshots, unattached volumes, log data retained forever because no lifecycle policy was ever written, and build artefacts from pipelines that ran years ago.
Lifecycle policies that move infrequent data to cheaper tiers and delete what has no retention requirement usually recover a meaningful amount, and it is the least risky change on this list.
3. Non-production running around the clock
Development and staging environments frequently run 24/7 while being used during office hours in one timezone. Roughly two-thirds of their running hours are unused.
Scheduled shutdown is straightforward. The objection is usually that someone might need it — which is worth testing rather than assuming, because the cost of being wrong is a few minutes of startup time.
4. Data transfer nobody designed
Cross-availability-zone traffic, NAT gateway charges and egress to the internet accumulate quietly and are difficult to attribute after the fact.
Common causes: services chatting across zones when they could be co-located, everything routed through a NAT gateway that does not need to be, and traffic leaving the network that could use a VPC endpoint.
5. Managed services past their crossover point
Managed services are excellent value at small scale and can stop being so as usage grows. The crossover is real but specific to workload shape, so it needs modelling rather than assuming in either direction.
The mistake in both directions is the same: choosing once and never re-checking.
What we do not recommend
Some reductions trade away resilience, and we say so plainly rather than reporting a lower number:
- Removing multi-AZ redundancy on production databases
- Reducing backup retention below what recovery actually requires
- Dropping monitoring and logging to save ingestion cost
- Undersizing so that a traffic spike causes an outage
A cloud bill that is 30% lower and an outage that costs a day of trading is not a saving.
Start with an audit
Before changing anything, produce a breakdown by service and environment, and tag resources well enough that the breakdown is meaningful. Most environments we audit have spend attached to something nobody can identify, and finding out what it is comes before deciding whether to remove it.
- aws
- cloud-cost
- infrastructure
- devops