Open any cost management tool and it will greet you with a list of underutilised instances and an estimated monthly saving. It is a satisfying place to start: concrete, quantified, and apparently low risk.
It is also close to the worst first move available, and the argument against it is arithmetic rather than taste.
You will size things you are about to delete
In any estate that has been running a few years, a meaningful share of what is deployed serves no current purpose. Environments outliving their projects, duplicated infrastructure, workloads whose consumers were decommissioned.
Rightsizing first means carefully choosing the correct instance type for things that should not exist. The effort is wasted twice: once doing it, and once again when someone eventually deletes the resource and your saving evaporates from the running total.
You will size against unrepresentative demand
Utilisation data reflects current architecture. If you are about to consolidate three monitoring stacks into one, or move a workload behind a cache, today's numbers describe a system you are about to change.
Sizing to a shape you are about to alter is measuring carefully and then moving the target.
You will encode your own waste as a baseline
This is the expensive version. Rightsizing produces a new baseline, and baselines get used for commitment purchases and for next year's budget.
Do it before cleanup and you have committed to a level of spend that still contains all the duplication you had not removed yet. That is a multi-year mistake made in an afternoon, and it is difficult to unwind because the commitment is now a sunk obligation.
What to do first instead
Attribution, then deletion, then consolidation, then scheduling. Every one of those lowers the floor that rightsizing will eventually be measured against, and all of them are cheaper to reason about because they involve removing things rather than tuning them.
By the time you rightsize, you are working on infrastructure that has survived four rounds of questioning about whether it should exist at all. That is a much better use of the effort.
When you do get there
A few things worth holding to:
- Use at least ninety days of observation. A fortnight misses month-end and quarter-end peaks, and sizing to it produces an incident on a predictable date.
- Size to the peak you must serve, not the mean. Averages hide exactly the load that causes an outage.
- Change one dimension at a time. Simultaneously reducing CPU and memory makes the resulting behaviour hard to attribute.
- Reserve headroom deliberately and write down why. A future reviewer will otherwise read it as waste and remove it.
The uncomfortable part
This sequencing is harder to sell, because deletion and consolidation require conversations with teams while rightsizing can be done from a dashboard. That is precisely why programmes start in the wrong place: the first step is chosen for how easy it is to begin rather than for how much it returns.
