Cloud cost projects have a predictable shape. A big clean up recovers a satisfying percentage, everyone agrees it should be a regular thing, and nine months later the bill is back where it started with nobody quite sure when that happened.
In short: Savings erode because cloud spend grows by default and shrinks only on purpose. The fix is a short recurring routine rather than another big project: check anomalies against budget alerts, review commitment utilisation, sweep for orphaned resources created in the last month, act on the right sizing recommendations, and confirm nothing was tagged to nobody. Half an hour a month holds most of the saving. The single most valuable habit is looking at what changed since last month rather than at the total.
Why savings erode
It is worth understanding the mechanism, because it tells you what the routine has to catch.
- New resources arrive constantly and default to generous sizing, because whoever created them was solving a problem, not optimising a bill.
- Commitments expire quietly. A reservation bought three years ago lapses and the workload silently reverts to pay as you go at full rate. Nothing breaks, so nothing alerts.
- Environments get cloned. A copy of production for a test that finished. The clone does not know it is temporary.
- Ownership dissolves. The person who created it moved teams. Nobody deletes something they cannot prove is unused.
None of these are failures of discipline. They are the normal metabolism of a cloud estate, which is why a one off clean up cannot hold.
"Cloud spend grows on its own and only shrinks when somebody makes it. That asymmetry is the whole problem."
The monthly pass
Half an hour, same slot every month, ideally the week after the invoice lands so the numbers are settled.
- Start with the change, not the total. Compare this month against last by service and by resource group. A total that looks reasonable can hide one thing tripling and another falling away. The delta is where the story is.
- Clear the anomaly alerts. If you have budgets and anomaly detection configured, work the queue. If you do not, configuring them is the highest value thirty minutes available to you, because it turns next month's surprise into this month's notification.
- Check commitment utilisation. Reservations and savings plans should be running close to fully used. Under used means you are paying for capacity you are not consuming. Also look at what expires in the next 90 days, because that is the window to decide rather than discover.
- Sweep resources created in the last month. Unattached disks, orphaned NICs, public IPs reserved and never used, snapshots from a migration that completed. Catching these monthly keeps the list at a handful rather than hundreds.
- Action the right sizing recommendations. Azure Advisor reads real utilisation. You do not have to accept every suggestion, but you should have looked at each one and made a decision.
- Confirm tagging. Anything untagged is anonymous, and anonymous resources are the ones that survive for years. Owner, project and environment is enough.
The quarterly additions
Three or four items do not need monthly attention but should not wait for the annual review either.
- Non production schedules. Dev, test and UAT rarely need to run outside working hours. Auto shutdown on those alone is one of the largest single savings available, and schedules get disabled during crunch periods and never re-enabled.
- Storage tiering. Data that has not been touched in months does not need to sit on the hottest tier it was created on.
- Licence entitlements. Azure Hybrid Benefit is routinely left switched off on machines that qualify. Worth a check whenever new VMs have appeared.
- Environments that should no longer exist. Ask the owners rather than guessing. The question "does anything still depend on this" gets a faster answer than trying to prove a negative from telemetry.
Make it someone's job, on a date
The routine fails for organisational reasons rather than technical ones. It is nobody's objective, it is the first thing dropped in a busy month, and the person who understands the estate is the person with the least free time.
Two things fix that in practice. Put it in a calendar with a named owner rather than a team, and report the delta upward every month even when it is boring. A single line saying spend moved by two percent, here is why, keeps the activity visible enough to survive.
If it repeatedly does not happen, that is a signal rather than a failing. It is precisely the kind of work that benefits from being handled outside the team that is busy running everything else, which is what our cloud and licensing cost optimisation service exists to do. For the underlying detail on where waste hides in the first place, cutting Azure waste covers the four sources we find most often.
