Cloud spend grows by default
On-premise, capacity is a purchase decision made once a year by someone accountable for it. In cloud, capacity is a decision any engineer can make in seconds, and nothing ever removes it. Resources are created for a test and left running; instances are sized generously "to be safe"; a workload doubles and nobody notices until the invoice.
Overspend is rarely one dramatic mistake. It is a hundred small defaults, none of which anyone owns. That is why the fix is part engineering and part operating rhythm.
Step 1 — Get visibility before changing anything
You cannot optimise what you cannot attribute. Most organisations start with a single account, no tagging standard, and a bill that says what was spent but not by whom or why.
- Agree a mandatory tagging standard: owner, environment, cost centre, application. Enforce it with policy so untagged resources cannot be created.
- Split environments across accounts or subscriptions — production separate from everything else makes both cost and security clearer.
- Turn on the native cost tools (Cost Explorer, Azure Cost Management, GCP Billing reports) and share them with engineering, not just finance.
- Establish a per-unit metric that matters to the business — cost per customer, per order, per tenant. Absolute spend rising is fine if the unit cost is falling.
- Set budgets and anomaly alerts. A runaway job should page someone in hours, not surface at month end.
Step 2 — The fixes with the best return
Roughly in order of value returned per hour of effort:
- Turn off non-production outside working hours. Dev and test running 24/7 for a team working 40 hours a week wastes about three quarters of that spend, and scheduling it is a small piece of automation.
- Delete orphaned resources: unattached disks, idle load balancers, unused elastic IPs, old snapshots, dormant dev environments. This is pure waste with no risk attached.
- Right-size compute against 30 days of real utilisation. Instances sized from legacy hardware specs are routinely two to four times larger than the workload needs.
- Apply storage lifecycle policies — move infrequently accessed objects to cooler tiers and expire what has no retention requirement.
- Fix the top few queries or jobs by cost. In data platforms a handful of unpartitioned queries frequently dominate the bill.
Step 3 — Commitments, but only after right-sizing
Reserved instances and savings plans discount steady-state usage substantially, and buying them is the most common way to lock in a mistake. Committing to over-provisioned capacity guarantees you pay for the wrong size for one to three years.
- Right-size first, let usage settle for a few weeks, then commit to the stable baseline only.
- Prefer shorter or more flexible commitments while the estate is still changing shape.
- Cover the predictable floor with commitments and leave the variable peak on demand.
- Review coverage and utilisation quarterly — commitments bought for a workload that has since been retired are a recurring, invisible cost.
Step 4 — Architectural costs, which are the stubborn ones
Once the obvious waste is gone, what remains is usually designed in:
- Data transfer: cross-availability-zone and cross-region traffic, and egress to the internet. This is invisible in design reviews and material on the invoice.
- Chatty service-to-service calls, which turn a design decision into a per-request cost.
- Over-replication: three copies of data nobody reads, in a region nobody serves.
- Managed service tiers chosen for a peak that never arrived.
- Logging everything at debug level, indefinitely — observability bills are frequently larger than the compute they observe.
- Idle clusters with long timeouts in data platforms, which cost the same whether anyone is querying or not.
Where the money actually goes
Before optimising, it helps to know the usual shape of a bill. For a typical business estate on any of the three major providers, compute is the largest line by some distance, followed by storage, then databases, then the long tail of managed services and data transfer.
The important detail is that the largest line is not the same as the biggest opportunity. Storage is usually a smaller share but contains a high proportion of pure waste — snapshots of servers deleted two years ago, log buckets with no lifecycle policy, backups retained far beyond any policy that was ever written down. Work through the bill by waste ratio, not by absolute size.
- Compute: the largest share, and where right-sizing and scheduling apply.
- Storage: smaller share, high waste ratio — orphaned volumes, snapshots and unbounded log retention.
- Databases: often over-provisioned because sizing was set during migration and never revisited.
- Networking and data transfer: small until an architecture change makes it large, and rarely reviewed.
- Observability: logs, metrics and traces at full verbosity, retained indefinitely.
- Non-production: frequently 30–40% of total spend for something used a third of the week.
A 30-day plan that actually gets done
Optimisation programmes stall when they start with a tooling evaluation. A tighter sequence produces a measurable result inside a month:
- Week 1 — turn on cost tooling, agree the tagging standard, and produce a baseline: spend by account, by service, and the untagged proportion.
- Week 2 — delete the obvious waste. Unattached disks, old snapshots, idle load balancers, dormant environments. No architecture decisions, no risk, immediate saving.
- Week 3 — schedule non-production off outside working hours and right-size the top 20 resources by cost using 30 days of utilisation data.
- Week 4 — set budgets and anomaly alerts, publish the baseline versus current, and agree who owns the monthly review from here.
- Only then — evaluate commitments, and only against the usage that remains after the first four weeks.
Step 5 — Make it a habit, not a project
A one-off optimisation exercise decays within about two quarters. What holds the gains is a light, regular rhythm:
- A monthly review of spend by team against the per-unit metric, with engineering present.
- Cost visible in the tools engineers already use, so the person creating a resource sees its price.
- Cost estimates included in design reviews for anything material — before it is built.
- Waste (untagged, idle, orphaned) tracked as a number that should trend down, and owned by someone.
- A quarterly commitment review tied to actual usage.
What not to do
- Do not impose a blanket percentage cut. It pushes teams to degrade production reliability instead of removing waste.
- Do not optimise before you have attribution — you will move spend around rather than remove it.
- Do not buy three-year commitments during a migration, when the estate is still changing weekly.
- Do not treat cost as a finance-only concern. The people who can remove waste are the people who created it.
- Do not chase the last few percent at the expense of engineering time worth more than the saving.
Frequently asked questions
For an estate that has never been actively managed, 20–35% within a few months is a common range, mostly from right-sizing, scheduling non-production and deleting orphaned resources. Beyond that, savings come from architectural change and are slower to realise.
Idle and over-provisioned compute — non-production environments running around the clock, and instances sized against legacy hardware specs rather than measured utilisation.
Yes, but only after right-sizing and only for the stable baseline of your usage. Committing to capacity you have not yet optimised locks in the over-provisioning for the length of the term.
Not usually. Most organisations need a tagging standard, cost visibility in engineering tools, and a monthly review with the right people in the room. A dedicated function makes sense once spend is large enough that a full-time role pays for itself several times over.
Almost never. It removes some commitment discounts, duplicates tooling and skills, and adds cross-cloud data transfer. Multi-cloud can be justified by resilience or regulatory requirements, but it is not a cost strategy.
Usually because workloads were sized from the old hardware, non-production kept running 24/7, and the legacy environment stayed switched on in parallel. All three are fixable, and all three are best addressed in the first 90 days before the numbers become normal.
How we can help
Migrations sized against real utilisation, with a cost baseline and budget alerts from day one.
Solution Design & ArchitectureRun-cost modelling per option, so the budget conversation happens before the build.