Cloud cost optimisation is not a one-time cleanup exercise led by finance. It is an operating discipline that balances spend, reliability, and delivery speed over time.
Finance visibility alone does not reduce waste. Engineering ownership of cost drivers does.
When this applies
Use this model when your AWS, Azure, or GCP spend is growing faster than workload growth, when budgets need clearer predictability, or when migrated environments are accumulating idle capacity without owners.
It is most effective when:
- service teams can explain what they run, not only what they deploy
- environments are tagged by owner, application, and lifecycle
- production and non-production capacity are funded and governed differently
- platform and application teams share responsibility for cost outcomes
Where waste usually hides
Start with the areas that most often grow unnoticed. Waste is rarely in the core compute tier; it accumulates at the edges, and the specifics shift by provider:
- compute and databases sized for peak tests or old traffic assumptions, including idle AWS NAT Gateways, over-provisioned Azure Premium SSD v2 disks, or idle GCP Cloud SQL instances
- development and staging environments left running continuously
- unattached storage, old snapshots, and orphaned load balancers or public IPs
- always-on services that only need business-hours capacity
- cross-region, cross-cloud, or internet egress paths that were convenient during migration
- unoptimised query patterns, such as BigQuery jobs scanning far more data than needed
The first goal is visibility with ownership. Optimisation without a named service owner usually reverses itself within a quarter.
Practical levers
Use levers in order of operational risk, not just potential savings.
1. Right-sizing
Match instance or service size to observed utilisation across normal and peak periods. Use several weeks of data, not one quiet afternoon.
2. Scheduling
Stop or scale down non-production environments outside working hours where no batch or integration dependency blocks it.
3. Reserved or committed capacity
Buy discounts only for stable baseline workloads with predictable usage. Avoid committing spend for bursty or experimental services. Commit at the organisational level to keep flexibility, but hold service owners accountable for how well that commitment is used. AWS Savings Plans, Azure Reserved VM Instances, and GCP Committed Use Discounts all follow this same logic with different mechanics.
4. Spot or preemptible capacity
Use interruptible capacity for fault-tolerant batch jobs, CI workers, stateless processors, or workloads with explicit retry design. Do not use it as a default for stateful production paths without recovery testing. Termination notice windows differ by provider, so build retry and checkpoint logic against the shortest one you rely on.
5. Storage lifecycle management
Tier or expire logs, backups, analytics data, and old snapshots deliberately. Storage waste is often the easiest savings to miss because it does not trigger immediate operational pain.
6. Architecture change
Serverless, managed services, consolidation, or workload redesign can reduce operating cost, but only when the reliability and migration tradeoffs are understood.
The multi-cloud reality
Running workloads across more than one provider adds a distinct failure mode: designing for the least common denominator to stay "portable," and quietly giving up every native cost-control mechanism in the process.
The better default is to use each provider's native tools fully, and hold uniformity only where it actually matters: tagging. A consistent schema (owner, environment, cost centre) applied the same way across AWS, Azure, and GCP is what makes unified reporting possible at all. Cross-cloud egress deserves its own line item too; moving data between providers is often more expensive than the compute needed to process it.
Operating rhythm
Cost control sticks when it becomes part of platform operations.
- monthly review of top spend drivers with service owners
- tag enforcement for environment, team, and application
- alerts on unexpected daily or weekly spend movement
- documented exceptions for workloads that must remain oversized for reliability
- post-migration review once real traffic patterns exist
A useful rule: every top-ten cost item should have a named owner and a reviewed justification.
Verification
A cost programme is working when:
- teams can explain why their largest services cost what they do
- non-production waste is visible and shrinking
- savings do not correlate with increased incident volume
- reserved or spot decisions are tied to workload behaviour
- finance reporting and engineering reality match closely enough to trust both
What to avoid
- optimising invoices without involving service owners
- downsizing production before understanding peak, cache, and failure behaviour
- using spot capacity for stateful systems without a tested recovery path
- treating dashboards as a substitute for engineering review
- cutting observability or backup spend first because it is easy to hide temporarily
Related work
This note supports Cloud cost optimisation programme.