Cut your cloud bill without cutting corners

Cloud bills rarely balloon because someone made a dramatic architectural mistake. They creep, because provisioning is a two-minute job and decommissioning is nobody's job. When we audit an account, the same four things come up almost every time.

1. Machines sized for a launch that already happened

Teams provision generously before launch because nobody wants to be the reason the site fell over. Then traffic settles and nobody revisits it. We regularly find production instances sitting at four percent CPU.

What to do: pull thirty days of CPU and memory metrics, and right-size anything that never crossed forty percent. Do it one service at a time with a rollback plan. This is usually the single biggest win available.

2. Storage nobody deleted

Detached volumes from terminated instances. Snapshots from a migration two years ago. Log buckets with no lifecycle policy, quietly accumulating since the first deploy.

What to do: list unattached volumes and snapshots older than your actual retention policy, and delete them. Then set lifecycle rules so it does not happen again — move logs to cold storage after thirty days, expire them after a year, or whatever your compliance obligations actually require rather than what feels safe.

3. Non-production running at 3am on a Sunday

Staging, QA and demo environments usually only need to exist during working hours. Running them nights and weekends means paying for roughly three times the hours you use.

What to do: schedule non-production environments to stop outside working hours. It is a small automation and it typically removes a meaningful chunk of the bill on its own.

4. Paying on-demand rates for baseline load

If a workload has been running continuously for a year, paying the on-demand rate for it is a choice. Committed-use discounts and savings plans exist precisely for this, and the discount is substantial.

What to do: identify your genuine floor — the capacity you have never gone below — and commit to that portion only. Keep the variable part on-demand. Committing to your peak is how people end up locked into paying for capacity they stopped needing.

The habit that keeps it from coming back

Tag everything by environment and owner, then put the bill in front of the team monthly. Not to blame anyone — to make cost visible at the point where decisions get made. Engineers make thriftier choices when they can see the number, and they cannot see it if it arrives on someone else's invoice.

A useful sanity check: could you explain your three largest line items to someone outside the team? If not, that is where to start looking.

What not to do

Do not cut backups, do not cut monitoring, and do not collapse redundancy to save money. Those savings are real right up until the day they are catastrophically not. If the only remaining savings are in those categories, you are already efficient and the answer is to grow into the spend rather than shrink it further.