Right-sizing: the cheapest optimisation nobody does

Before considering commitments, spot capacity, architecture changes or a different provider, there is a simpler question that usually returns more money than any of them: are these machines the right size?

Across most estates the answer is no, and by a wide margin. Instances sized from a pre-launch guess, never revisited, running at low utilisation, are the normal condition rather than the exception.

Why it happens, reliably

The mechanics are the same everywhere.

The machine was sized before the workload existed, from an estimate of peak traffic that was deliberately generous because nobody wanted to be the person who under-provisioned the launch. Then it worked, so nobody touched it.

Meanwhile the incentives point one way. Making a machine bigger is safe and invisible. Making it smaller is a change that could cause an incident, and the person who proposes it owns that risk while the saving accrues to a budget line they do not see.

The result is a ratchet. Sizes go up and never come down.

What to measure

Utilisation alone is not enough, because a machine at twenty percent average CPU might be at ninety-five percent during a nightly batch window that matters enormously.

Look at four things over at least two weeks, and preferably a month:

• CPU utilisation, at the ninety-fifth percentile rather than the average. The average hides peaks; the maximum overreacts to a single spike.
• Memory utilisation, same statistic. Memory is the more dangerous of the two to get wrong, because exhausting it causes swapping or termination rather than slowness.
• Disk and network throughput, in case one of those is the actual constraint.
• The shape over time, so you can see whether the peak is a daily business cycle, a weekly batch, or a one-off.

Two weeks is the minimum because it captures a weekly cycle. A month is better because it captures month-end processing, which is exactly the peak that catches people out after they have downsized.

The rules of thumb

Below forty percent peak CPU and memory: downsize one step. There is comfortable room.

Forty to seventy percent: leave it alone. This is a healthy range with real headroom.

Above eighty percent sustained: size up, or investigate why it is that high, because a code inefficiency is cheaper to fix than a bigger machine.

Memory above eighty-five percent: act now. Memory pressure degrades much more sharply than CPU pressure.

Downsize one step at a time rather than jumping. A step down usually halves the resource, which is a large change, and observing one step before taking another keeps the risk small.

Where the biggest wins hide

Not all machines are equally worth examining. Concentrate on:

Non-production environments. Development, staging, test and QA machines are frequently sized identically to production for no reason other than that the template was copied. They serve a fraction of the load. They are usually the single largest pool of waste in an estate.

Anything that runs continuously but is used intermittently. A machine used during working hours costs four times what it needs to when it runs all week.

Old instance generations. Newer generations typically deliver more performance per unit of cost. Moving to a current generation is often a saving and a speed improvement simultaneously, and it is usually a resize rather than a rebuild.

Over-provisioned managed services. Managed databases in particular are often provisioned generously at creation and never reviewed.

Anything created for a project that has ended. Not right-sizing so much as deletion, but it turns up in the same review.

Scheduling, which beats sizing

For anything non-production, switching it off outside working hours saves more than any amount of sizing precision. A machine running fifty hours a week instead of a hundred and sixty-eight costs less than a third as much.

Two things make schedules stick. Make them the default for new non-production resources rather than something to opt into, and provide a documented, easy way to keep something running when it is genuinely needed. A schedule that gets in the way of real work will be disabled permanently after the first time it does.

Making it a habit rather than a project

A one-off right-sizing exercise decays. Within a year the estate drifts back, because new resources are created with the same generous defaults.

What works better is a small recurring review: once a quarter, list the ten most expensive resources and check each one’s utilisation against the rules above. Ten resources is a short enough list that it actually happens, and in a concentrated estate those ten are most of the money.

Pair it with a default that new non-production resources start small and are scheduled. Changing the default does more over time than any number of clean-up exercises.

The honest caveat

Right-sizing has a floor. Past a certain point you are trading real headroom for small sums, and the first unexpected traffic spike costs more in incident time than a year of the saving.

Aim for comfortable rather than tight. The goal is removing obvious waste, not running everything at ninety percent.

For a view of how the providers differ on the points above, the cloud account catalogue lays out their respective strengths and configurations.

For the vendor’s own reference on the services involved here, see the Azure documentation on Microsoft Learn.

Trying this on real infrastructure is the quickest way to absorb it. Our Azure accounts come in five configurations, each priced separately, and the cloud account catalogue covers the alternatives.

Questions people ask