Home/Blog/Rightsize Before You Commit
Explainer · Commitment Management

Why You Should Rightsize Before You Commit

It is the most expensive ordering mistake in cloud cost management. A reservation discounts the price of a resource; it does nothing about whether you needed that resource at all. Commit to an oversized fleet and you have just signed a one to three year contract on your own waste.

Updated May 20269 min readAWS · Azure · GCP · OCI

You should rightsize before you commit because a commitment discounts the rate, not the usage. Rightsizing reduces how much you consume; reservations reduce what each unit costs. If you buy reservations before rightsizing, you lock the discount onto resources you are about to shrink or delete, which means you pay, at a discount, for capacity you do not need, for the full length of the term. The correct order is the opposite: cut the usage down to what you actually need, let the baseline settle, then commit to that clean number. This is exactly why our method runs See and Cut before Lock.

This article is part of the complete guide to cloud commitment management, and it is the reasoning behind step one of the commitment purchase strategy. It is a lesson we have watched cost real money across the 500-plus environments we have optimized since 2019.

A reservation discounts the rate, not the usage

This is the whole argument in one sentence, and it is worth sitting with. When you reserve a large compute instance, the provider gives you a lower hourly price in exchange for committing to run it. The commitment is to the resource and its rate, not to a workload outcome. So if that instance was twice the size your application needs, the reservation makes the oversized instance cheaper, but it does nothing to make it the right size. You have optimized the rate of a mistake instead of removing the mistake.

What committing too early actually costs

Consider a fleet running at 30 percent average CPU, a textbook over-provisioned setup. The right move is to rightsize it down, cutting roughly half the spend. But if you reserve the fleet first at, say, a 40 percent discount, you are now locked into the oversized fleet for the term. Rightsizing it afterward would strand the reservation, dropping your utilization and wasting the commitment, so most teams leave the oversized fleet running just to keep the reservation busy. You have traded a one-time 50 percent rightsizing saving for a 40 percent discount on twice the capacity you needed. The math almost never favors committing first.

The trap in numbers

Reserve an oversized fleet at a 40% discount and you pay 60% of full price on 100% of the waste. Rightsize first, then reserve, and you pay 60% of full price on only the 50% you actually need. The second path costs less than half as much, every month, for years.

Why this creates a vicious cycle

Committing before rightsizing does not just waste money once; it actively blocks future optimization. A reservation creates an incentive to keep the underlying resource running so the commitment stays utilized. Teams that reserve early often refuse to rightsize afterward because doing so would tank their utilization metric, the very number explained in coverage and utilization. The result is a fleet that is frozen at the wrong size for years, defended by the reservation that should never have been bought. This is one face of the risk of over-committing to cloud discounts.

The correct order: See, Cut, then Lock

The fix is a sequence, not a single action:

  • See first. Get clean, tagged, normalized usage data so you know what every resource is actually doing.
  • Cut next. Rightsize compute, clear idle and zombie resources, and put non-production on a schedule. This is the work that shrinks the baseline.
  • Let it settle. Give the new baseline a few weeks so you are forecasting the real, post-rightsizing floor, not a number mid-change. The forecasting method is in how to forecast commitment needs.
  • Lock last. Now commit, to the clean, stable base, choosing instruments per reserved instances vs savings plans vs CUDs and laddering the purchase per how to ladder cloud commitments.

What if usage is genuinely stable and already right-sized?

Then commit. The rule is not delay forever; it is do not commit to waste. If a fleet is already running efficiently and you are confident it will persist past break-even, there is no reason to wait, and you should check the math with the model in how to model break-even on a reserved instance. The discipline is simply to verify the resource is right-sized before you sign a multi-year commitment to it, not to leave savings unclaimed.

Not sure if your fleet is ready to commit?

An audit rightsizes first, settles the baseline, then builds the commitment plan on a clean number, so the discount lands on real usage. On the performance model, if we do not save you money, there is no fee.

Get a commitment audit →
Field note

On the SaaS-on-AWS engagement we resisted the client's instinct to reserve the existing fleet. We rightsized EC2 first, cleared idle capacity, then committed to the settled base with laddered Savings Plans. Reserving first would have locked in roughly 40% more capacity than they needed. The disciplined order was part of taking the annual bill from $4.2M to $2.8M, a 33% reduction.

Where this fits

Rightsizing before committing is the foundation of the whole commitment cluster. Read the complete guide to cloud commitment management for the full sequence, and download The Commitment Strategy Playbook: RIs, Savings Plans, CUDs for the rightsize-then-commit worksheets. When you want the whole sequence run for you, see our commitment management service.

The Cloud Cost Brief

Cloud pricing moves. We tell you when it matters.

New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.

Subscribe · Work email only