Measure before you optimise
Cost optimisation done from intuition usually targets the wrong thing. Open the billing breakdown by service and sort by amount. The top three lines almost always account for most of the bill, and everything below them is a distraction.
If resources are tagged by environment and project, do the same breakdown by tag. That usually identifies an owner as well as a cost.
Idle and forgotten resources
The largest single category of waste on most accounts is things nobody is using.
- Instances started for a test and never stopped
- Volumes detached from deleted instances, still billing
- Snapshots of resources that no longer exist
- Reserved IP addresses not attached to anything, which several providers charge for specifically
- Load balancers left in place after the service behind them was removed
- Old environments for projects that finished
This is unglamorous work and it is usually the biggest single saving available.
Oversized instances
Instances are commonly sized by guess at the start and never revisited. Look at actual CPU and memory utilisation over a few weeks; if something is consistently using a small fraction of its allocation, resize it.
Do this before making any long-term commitment, or the oversizing gets locked in for the term.
Storage tiers and lifecycle
Data written to a hot tier and never read again is paying premium rates for nothing. Lifecycle rules that move objects to cooler tiers after a period are usually a straightforward saving.
Check minimum storage durations before applying rules to data that changes, or early deletion charges can offset the gain.
Egress and cross-zone traffic
Egress is invisible during design and prominent on the invoice. If it is a large line item, look at whether services that talk to each other frequently are sitting in different zones or regions, and whether caching would reduce repeated origin fetches.
Then consider commitments
Once workloads are rightsized and the waste is gone, committing to the steady baseline reduces the rate substantially. Commit only to the floor of usage you are confident will persist, and leave the variable portion on demand.
Doing this last rather than first is what makes it a saving rather than a lock-in of existing waste.
Make it recurring
A one-off clean-up decays. A short monthly review of the top cost lines and any newly idle resources keeps the bill honest, and takes far less time than the clean-up did.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Taking Full Ownership of a Cloud Account After Handover
- Running Client Work: One Account Per Client
- AWS vs Oracle Cloud: Which Cloud Account Should You Buy?
- Kamatera vs UpCloud: Which Cloud Account Should You Buy?
Frequently asked questions
Idle and forgotten resources, by a clear margin on most accounts. Instances, volumes and addresses nobody is using.
Only after rightsizing. Committing to an oversized instance locks the waste in for the term.
Monthly is enough for most accounts, with budget alerts covering anything unexpected in between.