Every cloud provider's own cost-optimisation guide reads the same: "right-size your instances, delete unused resources, use reserved capacity." All true. All incomplete. The advice that actually moves a bill by a meaningful percentage rarely fits in a bullet list, because it requires understanding how a specific system is actually being used — not generic best practices.
What genuinely moves the needle
1. Committed-use discounts, sized correctly
Reserved Instances (AWS), Committed Use Discounts (GCP), and Reserved VM Instances (Azure) routinely deliver 30–60% savings over on-demand pricing — but only if sized against genuinely stable baseline load, not peak. The mistake we see constantly: teams commit based on current total usage, including autoscaling peaks, and end up paying for reserved capacity they don't consistently use. Commit against your true floor, let autoscaling handle everything above it on-demand or spot.
2. Spot/preemptible instances for the right workloads
For fault-tolerant, stateless, or batch workloads — CI/CD runners, data processing jobs, non-critical background workers — spot instances (AWS/Azure) or preemptible VMs (GCP) cut compute costs by 60–90%. This is one of the highest-leverage changes available, and one of the most underused, because it requires architecting for interruption up front. Retrofitting it into a system not designed for it is real work, but the payoff is large and recurring.
3. Storage tiering, actually enforced
Every provider has cheap cold-storage tiers (S3 Glacier, Azure Archive, GCP Coldline) that cost a fraction of standard storage. The gap isn't awareness — it's that lifecycle policies rarely get set up and maintained. A one-time audit plus automated lifecycle rules (move to cold storage after 90 days of no access, delete after retention period) is a few hours of work that keeps paying off indefinitely.
4. Killing orphaned resources
Unattached EBS volumes, idle load balancers, forgotten dev/staging environments left running, old snapshots nobody deletes — in nearly every cost audit we've run, this category alone accounts for a real, recoverable chunk of monthly spend. It's boring work, but it's close to free money: nothing architectural has to change, you're just turning off what nobody's using.
What doesn't move the needle much (despite the blog posts)
Switching cloud providers entirely
Multi-cloud "cost arbitrage" articles imply meaningful savings from picking the cheapest provider per workload. In practice, the migration cost, added operational complexity, and lost volume discounts from splitting spend across providers usually outweigh the marginal pricing differences — unless you're operating at a scale where dedicated FinOps engineering makes the complexity worth it.
Micro-optimising individual instance types
Endlessly tuning between similar instance families for a few percent difference burns engineering time that's worth more than the savings. This matters at hyperscale; for most mid-size companies it's a distraction from the four levers above.
Aggressive autoscaling tuning without addressing root cause
If an application is inefficient — unoptimised queries, no caching layer, chatty microservices — no amount of autoscaling tuning fixes the underlying waste; it just autoscales the waste more precisely. Fix the application first.
The pattern across every real cost audit we've done: the biggest wins come from matching commitment/pricing model to actual usage pattern, not from squeezing marginal efficiency out of infrastructure that's fundamentally well-architected already.
Where to actually start
Run a proper cost audit before optimising anything — most cloud providers' native cost tools (AWS Cost Explorer, Azure Cost Management, GCP's Cost Table) will surface orphaned resources and usage patterns within an hour of setup. Fix the "free money" items first (orphaned resources, storage tiering), then move to the bigger architectural levers (committed-use discounts, spot instances for the right workloads) once you understand your actual usage baseline.