Cost optimisation has a reputation for requiring architecture changes. In practice the first two-thirds of the saving on most accounts comes from deleting things nobody is using, and carries no risk at all.
Step one: find what is running and unused
Zero-risk, usually the largest single win, and almost always available on an account older than a few months:
- Unattached block volumes. Deleting a server rarely deletes its disks, and the disk keeps billing at full provisioned size.
- Reserved public IP addresses not attached to anything. Most platforms charge specifically for this.
- Old snapshots. Automatic schedules with no retention limit accumulate indefinitely.
- Load balancers with no healthy targets.
- Stopped instances that still hold storage. Stopped is not free on every platform.
- Development and staging environments left running overnight and at weekends.
That last one is the biggest recurring item on many accounts. A non-production environment running 168 hours a week when it is used for 45 is paying nearly four times what it needs to.
Step two: right-size from measurements
Low risk, done one resource at a time, reversible with a reboot.
- Collect a week of real utilisation — CPU, memory, disk I/O and network.
- Identify instances whose peak sits far below their allocation.
- Resize one, during a quiet window, and watch it for a few days.
- Repeat.
Resize down in single steps rather than halving. The goal is a machine with comfortable headroom, not a machine at 95% — see how much RAM a cloud server needs.
Step three: storage classes and lifecycle rules
Object storage almost always contains data that is never read again — old backups, logs, uploaded originals of files that have since been processed. A lifecycle rule that moves objects to a colder class after a set period, and deletes them after a longer one, is a one-time configuration that keeps saving. Set retention when you set the schedule, not when the bill arrives.
Step four: attack egress
For traffic-heavy workloads this is frequently the largest line item and the least examined. A CDN in front of static assets, compression on text responses, and keeping chatty components inside one zone will together move the number substantially. Egress and bandwidth charges covers where it hides.
Step five: commitments, last
Commitment discounts are the step everyone reaches for first and belong last, because committing to a workload you have not yet optimised locks in the unoptimised shape for a year or more. Right-size first, then commit to what remains. On-demand, reserved and spot covers the trade-offs.
Keeping it from coming back
- Tag everything at creation with project and owner. Untagged resources are what become orphans.
- Set retention on every automatic snapshot or backup schedule.
- Schedule non-production environments off outside working hours.
- Review the bill monthly by service, not just in total. The total hides which thing changed.
- Keep a budget alert on forecast spend.
Where to go next
Questions
Frequently asked
What is the fastest way to reduce a cloud bill?
Delete unused resources: unattached volumes, unassigned IP addresses, accumulated snapshots and idle non-production environments. It carries no risk and is usually the largest single saving.
Should I buy reserved capacity to save money?
Only after right-sizing. Committing to an unoptimised workload locks in the waste for the length of the term.
Is it safe to resize a running instance downward?
Generally yes, with a reboot and a quiet window. Move one step at a time and observe for a few days before continuing.