When a cloud bill becomes a visible problem, the instinct is to act immediately: buy reserved instances, downsize a few obviously oversized machines, delete the resources someone remembers being unused. All of these can help. None of them are actually the first step, and doing them first usually means redoing the work later.
You can't optimize what you can't attribute
The first, unglamorous step is answering a simple question well: which team, service or environment is actually driving this cost? Most organizations can't answer this with any precision, because tagging is inconsistent or absent — a resource created eighteen months ago by someone who's since left the company has no tag telling you who owns it or why it exists.
Without that attribution, every optimization decision is a guess dressed up as analysis. You might rightsize a database that turns out to be critical, or leave an idle one running because nobody flagged it as unowned.
Fix tagging at the infrastructure-as-code level, not by policy memo
Asking engineers to "please tag your resources" produces inconsistent results within a month. The durable fix is enforcing tags at the point resources are created — a required variable in your Terraform modules, validated in CI, so an untagged resource simply doesn't get created. This is a small amount of upfront engineering work that eliminates an entire category of future cleanup.
Then: find what's driving cost, not what looks big
Once you have attribution, the next step isn't rightsizing everything — it's finding the handful of things actually driving spend. In practice, cost is rarely spread evenly. A small number of oversized instances, forgotten environments, or an inefficient data transfer pattern typically account for a disproportionate share of the bill. Fix those first; the effort-to-savings ratio is far better than an across-the-board rightsizing pass.
Idle and orphaned resources are usually the fastest win: unattached storage volumes, idle load balancers, forgotten staging environments left running over a weekend or a holiday. These cost real money and provide zero value, and they're straightforward to detect once you have consistent tagging in place.
Rightsizing comes after visibility, based on real data
Only after you know what's running and who owns it does rightsizing make sense — and it should be based on actual utilization data (two to four weeks of CPU, memory and network metrics), not on guessing a smaller instance size will probably be fine. Guessing in either direction is expensive: too aggressive, and you introduce a reliability risk; too conservative, and you've barely moved the number.
Commitment-based discounts are a planning exercise, not a purchase
Reserved instances and savings plans are worth real money, but only once you have a stable, well-understood baseline of usage to commit against. Buying commitments before you have visibility just locks in whatever inefficiency already exists, for one to three years.
The sequence that actually works
Visibility and attribution, enforced tagging, targeting the actual biggest cost drivers, evidence-based rightsizing, and only then commitment planning. Skipping to the end of that list is what makes cost optimization feel like a one-time cleanup that has to be redone every year, instead of a discipline the engineering team owns continuously.
Related service