Keeping cloud cost under control
Cloud spend almost never explodes. It creeps, five per cent a month, until somebody notices the bill is forty per cent higher than last year and nobody can say which decision caused it.
Most cloud overspend comes from five things: environments nobody switched off, storage on a tier that was chosen once, backups retained far longer than the policy requires, resources sized for a launch peak that never returned, and data leaving the platform.
Tag everything so spend can be attributed to a team or a project. Untagged resources are the ones nobody turns off, because nobody knows whose they are.
A twenty-minute monthly review of the ten largest line items catches almost all of it. An annual review catches none of it, because by then the drift is normal.
The five line items that cause most of it
| Cause | How it happens | Typical share |
|---|---|---|
| Idle environments | A test or acceptance environment built for a project that ended | Often the largest single item |
| Storage tiering | Everything on the fastest tier because that was the default | Substantial and easy to fix |
| Backup retention | Seven years retained when policy says one | Grows quietly and never shrinks |
| Over-sized resources | Sized for a launch peak that never came back | Very common after a migration |
| Egress | Data leaving the platform, often to a reporting tool | Small until it is not |
Tagging is the whole discipline
The reason nobody switches off an unused environment is that nobody is certain whose it is or what breaks if it goes. Tagging solves that: every resource carries an owner, a project and an environment label, applied at creation rather than retrospectively.
Enforce it. A policy that blocks the creation of an untagged resource is unpopular for a week and saves money for years. Retrospective tagging never finishes, because the resources you most want to identify are the ones whose owner has left.
The twenty-minute monthly routine
- Open the ten largest line items. Not the whole bill. The top ten is where the money is.
- Compare against last month. Anything that grew by more than ten per cent gets a sentence of explanation.
- List untagged resources. Assign an owner or switch it off after a warning period.
- Check non-production environments. Are test and acceptance running outside working hours, and do they need to be?
- Look at the trend, not the number. One expensive month is noise; three rising months is a decision somebody made.
We include this in monthly reporting rather than treating it as a separate optimisation project, which is described under service governance.
Commitments and reservations
Reserved capacity and savings plans reduce the rate substantially in exchange for committing to a term. They are worth it for anything genuinely steady, and a trap for anything you are still deciding about.
The rule we use: commit only to what has run unchanged for three months and is expected to run for another year. Everything else stays on demand. Committing early to a workload that gets redesigned six months later costs more than the discount saved.
Not everything belongs in the cloud
Predictable, steady workloads with large data volumes are frequently cheaper on your own hardware, and that has become more visible as egress and storage costs have grown. This is not an argument against cloud; it is an argument against assuming one answer for the whole estate.
We look at each workload separately: bursty and variable to the cloud, steady and data-heavy often better where it is. Where virtualisation stays on site we work with VMware, Nutanix and Proxmox, and the trade-offs are set out in Azure, AWS or stay where you are.
Somebody has to own the bill
The single strongest predictor of whether cloud cost stays under control is whether one named person looks at it every month. Not a department, not a shared mailbox, a person.
That does not have to be someone technical. A finance colleague who asks why line four grew by eighteen per cent gets a better result than an engineer who understands the bill but has no reason to question it.
Questions we get about this
What comes up when a bill has been rising.
Why does our cloud bill keep going up?
Almost always through drift rather than a single decision: environments left running, storage on a fast tier that was never revisited, backups retained beyond policy, and resources sized for a peak that never returned. Reviewing the ten largest line items monthly catches nearly all of it.
How much can we realistically save?
On an estate that has never been reviewed, ten to thirty per cent is common without changing anything users notice. Most of it comes from switching off what nobody uses and moving cold data to a cheaper tier.
Are reserved instances worth it?
For workloads that have run unchanged for three months and are expected to run another year, yes. For anything still being designed, no. An early commitment to a workload that gets redesigned costs more than the discount saved.
Should everything move to the cloud?
No. Steady, predictable workloads with large data volumes are frequently cheaper on your own hardware, particularly once egress is counted. The useful question is which workload belongs where, not whether to be in the cloud.
Where this lands in our work
Where cloud work sits.
Want this looked at for your own sites?
Half an hour on a call is usually enough to tell you whether we are the right party for it, and we will say so if we are not.