Most cloud cost advice is a list of techniques: rightsize, buy commitments, delete unused volumes, schedule non-production. All of it is correct and none of it tells you what to do first, which is the only thing that matters when the bill is large and nobody can explain it.
Across a portfolio spanning two cloud providers we took spend down by roughly eighty percent. This is the order the work happened in, and why that order is not arbitrary.
One: make the bill attributable
Before any optimisation, spend had to map to something a person owned. Not to a service or a resource type, but to a team or a business line that could be asked about it.
This is unglamorous and it takes weeks. Tagging conventions, enforcement so untagged resources cannot be created, and a period of retrospectively attributing what already exists. It produces no saving on its own, which is why it gets skipped.
Optimisation without attribution is guessing about someone else's workload.
It is also what makes every later step possible. You cannot ask whether something is worth its cost until you can find the person who knows what it is for.
Two: find what nothing depends on
The first real savings came from resources that no longer served a purpose: environments for projects that had ended, volumes detached from instances that were deleted, snapshots on an infinite retention policy, load balancers with no targets, and duplicated infrastructure created when two teams solved the same problem independently.
This is the highest-return work available and it carries almost no risk, because you are removing things nothing depends on. It is also the part that requires attribution to have been done first, otherwise you are deleting resources without knowing who will notice.
Three: consolidate the duplication
In a portfolio, the same capability tends to exist several times over: multiple monitoring stacks, several container registries, overlapping data pipelines. Each was reasonable when created, and together they cost several times what one well-run instance of each would.
This is where regulatory constraints do real work. Some duplication cannot be consolidated because separation is required, and that is a legitimate cost rather than waste. Knowing which is which is the difference between a cost programme that lands and one that gets overruled.
Four: schedule what does not need to run
Non-production environments running continuously are one of the most reliable savings available. A development environment used during working hours costs roughly three times what it needs to if it runs at nights and weekends too.
The technical work is trivial. The hard part is the first week, when someone finds their environment down at seven in the evening. Announce it, make restarting self-service and immediate, and allow exemptions for teams who genuinely need them.
Five: rightsize, now that usage is real
Only at this point does rightsizing make sense, because you are now sizing against workloads that will actually persist rather than against everything that happened to exist when you started.
Use a long observation window. Ninety days catches monthly cycles and seasonal peaks that a fortnight will miss, and sizing to a fortnight of data is how you end up with an incident during a quarter end.
Six: commit to what is now stable
Commitments are last for a reason. They are a bet on a baseline, and a baseline measured before the previous five steps is a bet on your own waste. Every earlier step lowers the floor, and committing before them locks in spend you were about to remove.
The step that makes it stick
None of this holds without a feedback loop. Budgets with alerts routed to the team that owns the spend, and a short monthly review where anomalies are explained rather than tolerated.
Cost is not a project that completes. Without ongoing attention, spend returns to roughly where it was within a year, and the second cleanup is harder because everyone remembers the first as disruption rather than progress.
