Almost every cloud cost review we run finds a third of the bill sitting in things nobody is actually using — before we've touched architecture at all.
Teams jump straight to talk of re-platforming or switching providers when the real problem is closer to home: idle resources, oversized instances, and storage tiers set once and never revisited.
Start with what's running idle
Dev and staging environments left running 24/7, orphaned load balancers, and forgotten snapshots are the fastest wins. None of it requires an architecture decision — just someone willing to look.
We usually find at least one "temporary" environment spun up for a demo six months ago, still billing every day since. It's rarely anyone's fault directly — it's just that nobody owns the job of periodically asking what's actually being paid for.
Right-size before you commit
Most instances are provisioned for a peak load that happens a few hours a month. Autoscaling and correctly sized reserved capacity usually beat a manually chosen instance type sized for comfort rather than data.
The cheapest infrastructure change is the one where you stop paying for capacity you already forgot existed.
Watch for egress and storage class creep
Compute gets all the attention, but data transfer and storage tier drift quietly compound. Logs and backups default into a hot storage tier and stay there for years; cross-region traffic that made sense during a migration keeps flowing long after the migration finished. Neither shows up on a dashboard unless someone's specifically looking for it.
Make cost visible to engineers, not just finance
The teams that keep their cloud bill under control long-term are the ones where engineers can see the cost impact of what they ship, not just the finance team reconciling an invoice a month later. A cost review that isn't followed by visibility just resets the clock until the next audit.
Reserved capacity is a bet, not a discount
Committing to reserved instances looks like free savings on a pricing page, but it's really a bet that next year's workload resembles this year's. Teams that grew fast and locked in three-year commitments based on a six-month usage spike often end up paying for capacity a re-architected system no longer needs.
We size reserved commitments against the load that's been stable for at least two full quarters, not the load at the moment someone happens to be reviewing the bill — a peak week is exactly the wrong week to commit against.
The audit finds different things every time
No two cost reviews turn up the same waste, because no two teams accumulated it the same way — one company's biggest line item is idle staging environments, another's is an over-provisioned database tier nobody downsized after a migration, a third's is cross-region traffic left over from an old disaster-recovery setup that quietly became permanent.
That's the actual argument for running a review at all rather than just applying a generic checklist: the checklist catches the obvious 20%, but the specific shape of a given bill only shows up once someone looks at this account, not a template.
We'll find the easy wins before you touch architecture.
Then, and only then, look at architecture
Once the obvious waste is gone, the remaining savings usually come from caching, smarter data storage tiers, and moving batch workloads to spot capacity — changes with real payoff, but only worth the engineering time after the easy money is already back in the budget.
