Cloud bills grow quietly. Nothing fails, so nothing prompts a review, and by the time anyone looks the spend has doubled. The savings are usually concentrated in a handful of places.
Find the shape of the bill first
Group spend by service and by environment before changing anything. Teams routinely discover that non-production environments cost more than production because nothing ever shuts them down.
The usual savings
- Idle and orphaned resources: unattached volumes, old snapshots, unused load balancers
- Oversized instances chosen from a default rather than a measurement
- Non-production environments running around the clock
- Data transfer between zones that architecture could avoid
- Logs retained for years without a reason
Commit only to what you understand
Reserved capacity and savings plans reduce rates substantially, but they lock in a baseline. Commit to steady-state usage you have measured over months, and leave variable workloads on demand.
Make cost visible
Tag resources by team and environment, and put the monthly figure somewhere the engineers who create resources will see it. Visibility changes behaviour more reliably than policy.
Do not optimise into fragility
Right-sizing to the point where a traffic spike causes an outage is not a saving. Leave genuine headroom and test that autoscaling works before relying on it.
The cheapest resource is the one nobody needed. Deleting beats resizing, and resizing beats committing.
Where to start
Sort last month's bill by cost, take the top five lines, and ask what each one is for. Anything nobody can explain is your first saving.
