Cost

Right-size or shut down underutilised VM scale sets

One capability for VM scale sets: find the ones whose instances run far below the SKU and instance count they are paying for, then resize the SKU, reduce the instance count, or shut the idle ones down, so the bill matches the load you actually carry.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Right-sizing VM scale sets: the basics

What does an underutilised VM scale set actually look like?

A virtual machine scale set is a pool of identical VMs sized by two numbers: the SKU each instance runs on, and how many instances are in the pool. You pay for both, continuously, whether or not the workload uses them. Underutilisation shows up when those two numbers were chosen for a peak that rarely arrives, or for headroom that was never trimmed: instances sitting at a few per cent CPU, a pool of ten running work that two could carry, or a whole scale set spun up for a project that ended and never torn down. The compute meter keeps running at the size you provisioned, not the size you use.

Azure Advisor turns this into a single cost recommendation, 'Right-size or shutdown underutilized virtual machine scale sets', against the microsoft.compute/virtualMachineScaleSets resource type. It uses machine-learning on the last seven days of CPU, memory and outbound-network metrics (the lookback is configurable up to ninety days) to spot pools that would fit on a cheaper SKU or fewer instances. For a scale set it has three moves: reduce the instance count, resize to a smaller or cheaper SKU, or, if the pool was not used at all over the lookback window, shut it down. Each carries an estimated saving against retail rates.

Most of this is drift, not a sizing mistake. A scale set provisioned for a launch that never reached its forecast, a pool whose instance count was bumped up during an incident and left there, a SKU chosen before a newer, cheaper generation existed. The work is to find every scale set running well below what it pays for, decide which can shrink without touching the load they carry, and prove the change is safe before you make it.

In this lesson you will learn how a VM scale set expresses its cost through SKU and instance count, how Azure Advisor decides a scale set is underutilised, and how to act on the recommendation safely: reduce the instance count, resize the SKU, or shut an idle pool down without taking a live service offline. The keep-learning section links the exact Microsoft references for each action.

Fun fact

The pool nobody scaled back down

The most common reason a scale set is oversized is not a bad initial estimate, it is an incident. A pool gets scaled out by hand or by a one-off rule to ride out a traffic spike or a noisy-neighbour problem, the fire is put out, and the instance count is never brought back down because nothing forces it to. The extra instances run on quietly, billed by the hour, until a right-sizing review or an Advisor recommendation notices that the pool has been sitting at single-digit CPU for weeks. This is exactly why Advisor prioritises the instance-count recommendation for scale sets: reducing the count is the quickest, most reversible way to undo that kind of drift.

Finding underutilised scale sets across a subscription

Priya runs the platform team at a SaaS company that has grown by acquisition, so its Azure estate is a patchwork of scale sets created by teams that no longer own them. The monthly bill has crept up and compute is the largest line.

Rather than guess at which pools are oversized, Priya pulls the cost recommendations Azure Advisor has already generated, then cross-checks each flagged scale set against its current SKU and instance count before deciding what to do with it.

Start by listing the right-sizing and shutdown recommendations Advisor has already raised in the Cost category. Each one names a scale set and an action.

$ az advisor recommendation list --category Cost --query "[?contains(impactedField, 'virtualMachineScaleSets')].{resource:impactedValue, action:shortDescription.solution}" -o table

Resource Action

----------------- -----------------------------------------

checkout-vmss Right-size or shutdown underutilized VMSS

batch-pool-old Right-size or shutdown underutilized VMSS

# batch-pool-old has been idle for the whole lookback. Check it for shutdown first.

Advisor has already done the detection. The CLI lists every scale set it flagged so you can triage shutdown candidates from resize candidates before changing anything.

How Azure Advisor decides a scale set is underutiliseddeep dive

Advisor evaluates the resource against CPU, memory and outbound-network utilisation. By default it analyses the last seven days of metrics, and you can widen the lookback to 14, 21, 30, 60 or 90 days in the Advisor configuration. Metrics are sampled every 30 seconds and aggregated up to 30-minute windows, and for a scale set the per-instance figures are combined across the pool: averaged across instances for instance-count recommendations, and taken at the maximum across instances for SKU-change recommendations, so a busy instance is not hidden by quiet ones when it decides the SKU can shrink.

From that, Advisor produces one of three actions. If the scale set was not used at all over the window (broadly, P95 CPU below about 3 per cent and outbound network below about 2 per cent), it recommends shutting it down. Otherwise it looks for a cheaper fit that keeps performance headroom, a smaller or newer-generation SKU, or simply fewer instances of the same SKU. For scale sets specifically, Advisor prioritises the instance-count recommendation over the SKU change, because changing the count is easily actionable and banks the saving faster. It also checks whether a burstable B-series SKU would suit a pool with low average CPU but occasional spikes.

Two limits matter when you read the estimate. The saving is calculated against retail rates, so it does not reflect any discount, reservation or savings plan you already hold, and Advisor explicitly cautions that a cross-series resize can increase cost if a reservation was bought for the original family. The recommendation also will not know about capacity you provisioned deliberately for an upcoming launch, a disaster-recovery standby, or a homogeneity requirement. Those are valid reasons to dismiss or postpone the recommendation rather than act on it.

What is the impact of leaving scale sets oversized?

The direct impact is recurring spend with nothing behind it. Every instance in an over-provisioned pool, and every step of SKU larger than the workload needs, is a compute charge that bills every hour regardless of load. Because it is steady and unremarkable, it rarely triggers a review: an oversized scale set does not page anyone, it just quietly inflates the monthly invoice until someone goes looking. The idle batch pool that ran for a month after its project ended is the same money as a small headcount, spent on nothing.

The second-order impact is that this waste compounds. An oversized scale set sets a baseline that the next reservation or savings-plan purchase is sized against, so the over-provisioning gets locked in as a committed spend that is harder to unwind. Right-sizing before you commit means the commitment is bought against real usage, which is where the durable saving comes from.

There is an upside framing too: this is one of the few cost levers where Azure quantifies the prize for you. A clean set of acted-on right-sizing recommendations is both an immediate, repeating saving and a signal that the estate is actively managed rather than left to drift, which is exactly what a cost-conscious board or an incoming finance owner wants to see.

How do you right-size a scale set safely?

Work the recommendation in order of how risk-free each action is, and verify against the workload's real peak before you shrink anything. The sequence matters: confirm a pool is genuinely idle or over-provisioned before you touch a live service, and check for reservations before a cross-family SKU change.

1. Triage shutdown candidates from resize candidates

Pull the Advisor cost recommendations and separate the scale sets it says were not used at all over the lookback window (shutdown candidates) from those it says are over-provisioned (resize candidates). A scale set that has been idle for the whole window is the cleanest saving; confirm with the owning team that it is genuinely retired, not a standby, before deallocating or deleting it.

2. Prefer reducing the instance count first

For over-provisioned pools, Advisor prioritises cutting the instance count over changing the SKU, because it is reversible and lands the saving fast. Check that the workload's peak is comfortably carried by the smaller count, then scale the pool down. If the scale set autoscales, lower the minimum and maximum capacity rather than fighting the autoscale rule.

3. Resize the SKU only after checking the peak and any reservation

A SKU change alters the performance ceiling of every instance, so size it against the maximum across instances, not the average, and keep the headroom Advisor targets. Critically, check whether the pool sits under a reservation or savings plan: a cross-family resize can strand it and increase net cost. If the new SKU is not supported on the current hardware, the instances must be deallocated before the SKU name can change.

4. Apply the model, then make right-sizing a routine

After changing the scale set model, bring the existing instances up to it (manual upgrade mode requires an explicit update-instances call). Then schedule a recurring review of the Advisor cost recommendations so new drift, especially instance counts bumped up during an incident and never lowered, is caught within weeks. Dismiss or postpone, with a reason, any recommendation against capacity held deliberately for a launch, disaster recovery or a homogeneity requirement.

# Take the lowest-risk saving first: reduce the instance count on an over-provisioned pool.
# Advisor prioritises this for scale sets because it is reversible and lands fast.
az vmss scale \
  --resource-group myResourceGroup \
  --name checkout-vmss \
  --new-capacity 3

# Higher-judgement saving: resize the SKU to a cheaper fit.
# Size against the peak, and confirm no reservation covers this pool before a cross-family change.
az vmss update \
  --resource-group myResourceGroup \
  --name checkout-vmss \
  --set sku.name=Standard_D2s_v5

# In manual upgrade mode the model change does not touch running instances until you apply it.
az vmss update-instances \
  --resource-group myResourceGroup \
  --name checkout-vmss \
  --instance-ids "*"

# Clean shutdown saving: deallocate an idle pool so it stops billing compute (storage still charges).
az vmss deallocate \
  --resource-group myResourceGroup \
  --name batch-pool-old

Quick quiz

Question 1 of 5

Azure Advisor raises 'Right-size or shutdown underutilized virtual machine scale sets' against several pools. For a scale set, which action does Advisor prioritise, and why?

Keep learning

Go deeper on how Azure Advisor generates the right-sizing recommendation and how to act on it across SKU, instance count and shutdown.

You can now treat scale-set right-sizing as one capability: pull the Azure Advisor cost recommendations, triage the idle pools to shut down from the over-provisioned ones to trim, reduce the instance count before reaching for a SKU change, verify each change against the workload's peak and any reservation, apply the model to running instances, and put the review on a recurring cadence so the saving stays banked.

Back to the library

Right-sizing VM scale sets: the savings view

Compute you are paying for at the provisioned size, not the used size, and the saving from closing that gap

A scale set running at a fraction of its capacity is the clearest form of waste in an Azure bill: a recurring compute charge with no matching demand behind it. Unlike a security finding, this one has a number attached. Advisor estimates the monthly saving for each recommended action, so 'right-size this scale set' reads directly as a line item you can recover, and the saving repeats every month until something pushes the size back up.

The actions sit on a spectrum of how risk-free they are. Shutting down a scale set that was not used at all over the lookback window is close to free money: you are paying for compute that did nothing. Reducing the instance count on a pool that is comfortably over-provisioned is low risk and, because Advisor prioritises it for scale sets, usually the fastest saving to bank. Resizing to a smaller or cheaper SKU is the higher-judgement call, because it changes the performance ceiling of every instance, so it wants a look at the peak, not just the average.

The one caveat finance should hold onto: Advisor's estimated savings are based on retail rates and do not account for any reservation or savings plan already covering that compute. If a scale set is sitting under a reserved instance, resizing it across SKU families can strand the reservation and cost more, not less. Net the saving against existing commitments before you treat it as banked.

This lesson is for the finance partner who sees a right-sizing recommendation with an estimated monthly saving and wants to know which actions are risk-free, which need a closer look at the workload's peak, and how to net the saving against any reservation or savings plan already in place so the figure on the board pack is the real recoverable amount.

Fun fact

The pool nobody scaled back down

How a finance partner frames the right-sizing decision

Priya is the finance partner sitting with the platform team's cost review. Azure Advisor shows seven right-sizing recommendations against scale sets, each with an estimated monthly saving, and the instinct is not to wave them all through at once. It is to sort them by how risk-free each one is and by how much the estimate is really worth. The numbers are attractive: Advisor estimates a meaningful monthly recovery across the seven. But the estimate is a retail-rate figure that ignores commitments, so the first question is which of these scale sets already sit under a reservation or savings plan.

Priya splits the list into three buckets. One scale set has been idle for the entire lookback window, a leftover batch pool, so shutting it down is close to pure saving with no performance trade-off. Three are comfortably over-provisioned and Advisor recommends simply reducing the instance count, which is low risk and lands quickly. The remaining three are SKU-change recommendations, and two of those sit under a three-year reservation for the current family, so a cross-family resize would strand the reservation. The finance pack reads: 'Four actions bank a clean, repeating monthly saving now; one idle pool is a straight shutdown; two SKU changes are parked until the reservation is netted out, because the headline saving overstates what we would actually recover.'

Why right-sizing belongs on the savings tracker

The cost model here is unusually concrete for a recommendation: each one carries an estimated monthly saving, so the prize is a number rather than an avoided risk. That makes right-sizing a savings-tracker item, not a risk-register one. The discipline finance brings is to convert Advisor's retail-rate estimate into the real recoverable figure by netting out any reservation or savings plan already covering the compute, and to weight each action by how reversible it is.

Order the list accordingly. Shutting down a scale set that was idle for the whole lookback is the cleanest saving and carries no performance trade-off. Reducing the instance count on an over-provisioned pool is low risk and, because Advisor prioritises it for scale sets, the fastest to bank. SKU changes are the higher-judgement bucket: they alter the performance ceiling of every instance and can strand a reservation if they cross SKU families, so they deserve a check against the workload's real peak before the saving is treated as banked. The metric for the cost review is recovered monthly spend net of commitments, not the raw count of recommendations closed.

What finance can do about the right-sizing gap

Finance cannot resize a scale set, but it owns the framing that turns a list of recommendations with retail-rate estimates into a real, banked saving net of commitments. Three levers.

1. Net the estimate against existing commitments

Make it standard that Advisor's headline saving is a retail-rate figure that ignores reservations and savings plans. For every recommendation, ask whether the scale set already sits under a commitment, and net the saving down accordingly. The figure that goes on the savings tracker is recoverable spend after commitments, not the raw estimate, so nobody books a saving the reservation has already paid for, or a cross-family resize that strands one.

2. Order the work by how reversible it is

Group the recommendations: idle-pool shutdowns and instance-count reductions are low-risk, fast-to-bank savings; SKU changes are higher-judgement because they move the performance ceiling and can collide with reservations. Push the team to act on the reversible bucket promptly and to verify the SKU bucket against the workload's peak before booking it. The savings that show up this month should be the reversible ones.

3. Make it a routine and require documented exceptions

A single right-sizing pass is a one-off win; a recurring review is a durable saving, because the most common cause of oversizing, an instance count bumped up in an incident and never lowered, recurs. Put the Advisor cost review on a monthly cadence. Any scale set that looks idle but is kept on purpose, a disaster-recovery standby or a provisioned-for-launch pool, should carry a recorded, finance-visible reason so it is a named exception rather than missed waste.

Quick quiz

Question 1 of 5

Advisor shows a right-sizing recommendation with an estimated monthly saving. As the finance partner, how should you treat that figure?

Keep learning

Go deeper on how Azure Advisor generates the right-sizing recommendation and how to act on it across SKU, instance count and shutdown.

You have finished the finance view of right-sizing scale sets. You know the saving is quantified up front but the figure is retail-rate, so the real number is recoverable spend net of commitments. Next time a right-sizing recommendation lands, you will net it against any reservation, bank the reversible actions first, the idle-pool shutdowns and instance-count cuts, and treat the deliberate idle capacity as a named exception rather than waste.

Back to the library

Right-sizing VM scale sets: the headline

Whether the estate pays for the compute it uses or the compute it once provisioned

Underutilised scale sets are the quiet kind of cost: nothing is broken, nothing alerts, the bill simply carries pools that were sized for a load that never arrived or a project that has ended. Azure Advisor surfaces them with a pound figure attached, which makes this one of the few cost levers where the saving is quantified before you act.

The leadership question is not 'can we cut compute?' It is 'does our spend track our usage, or our history?' The defensible end state is that right-sizing is a routine the platform runs, idle scale sets are shut down, over-provisioned pools are trimmed, and the few that look idle but must stay (disaster recovery, a known seasonal peak) are documented exceptions rather than forgotten ones.

This is a savings decision, not a security one, and it has a payback rather than a cost. The trade is a small amount of engineering time to verify each change against the workload's real peak, set against a recurring monthly saving that lands the moment the change is made and continues until something resizes the pool back up.

A short read for the leader who needs to know what an underutilised scale set costs, why right-sizing is a routine rather than a one-off cleanup, and what a defensible end state looks like: spend that tracks usage, with the deliberate exceptions named and owned.

Fun fact

The pool nobody scaled back down

What it looks like when spend tracks usage, not history

After a board review where compute was flagged as the fastest-growing line in the Azure bill, the CFO asked the platform lead a plain question: are we paying for what we use, or for what we once set up? The honest answer was that nobody knew per scale set, because pools had been sized by different teams at different times and never revisited.

The team's response was to stop treating right-sizing as a one-off cleanup and start treating it as a routine. They pulled every Advisor cost recommendation against scale sets, shut down the pools that had been idle for the whole lookback window, reduced the instance count on the over-provisioned ones, and parked the SKU changes that collided with existing reservations until those could be netted out. Then they put a monthly review on the calendar so new drift gets caught within weeks rather than quarters. The next time the CFO asked the question, the answer had changed from 'we think so' to 'spend tracks usage, here is the recurring saving we banked, and here are the three pools that look idle but stay because they are our disaster-recovery capacity.' That shift, from a bill shaped by history to one shaped by current load, is the confidence signal this capability delivers, and it pays for itself.

Why this is a board-level saving

Underutilised compute is the most common avoidable line in a cloud bill, and scale sets concentrate it because they multiply a sizing decision across a whole pool. The advantage here is that Azure quantifies the saving before you act, so this is a lever where the return is known in advance and the risk of acting is small and verifiable.

The cost of leaving it is steady, repeating and compounding: it inflates the baseline that future reservations are sized against, locking the waste in. The cost of acting is a small amount of engineering time to verify each change against the workload's peak. This is the rare class of decision where the saving is measured, the payback is immediate, and the only real discipline required is to net the estimate against existing commitments, which is exactly the trade leadership should be quickest to approve.

The leadership move on right-sizing

The executive handle is not to approve each resize individually; it is to require that spend tracks usage as a routine, that the quantified savings are banked net of commitments, and that the deliberate exceptions are named and owned.

1. Ask for the banked saving, net of commitments

Advisor estimates the prize, so ask for it as a number: how much recurring monthly spend was recovered, net of any reservation or savings plan. A retail-rate estimate is the headline; the recoverable figure after commitments is the one that belongs on the board pack. Asking for the net figure also surfaces where reservations are propping up oversized pools, which is its own conversation.

2. Make right-sizing a routine, not a project

Set the expectation that Advisor cost recommendations are reviewed on a regular cadence, not swept up once a year. Oversizing recurs, an incident scales a pool out and nobody scales it back, so a one-off cleanup decays. A standing monthly review catches new drift within weeks and keeps the saving durable rather than a single quarter's win.

3. Treat the deliberate idle capacity as named, owned exceptions

Some pools look idle on purpose: disaster-recovery standbys, capacity provisioned ahead of a launch, scale sets kept homogeneous by design. That is fine. The leadership requirement is that each is a deliberate, documented decision with an owner, dismissed or postponed in Advisor with a reason, not an oversized pool nobody has looked at. The goal is not zero idle capacity; it is zero unintended idle capacity.

Quick quiz

Question 1 of 5

At a board review, compute is the fastest-growing line in the Azure bill. What end state should you be looking for on scale-set spend?

Keep learning

Go deeper on how Azure Advisor generates the right-sizing recommendation and how to act on it across SKU, instance count and shutdown.

Two takeaways. Scale-set right-sizing is the rare cost lever where Azure quantifies the saving before you act and the change pays back immediately, so it is a trade you should be quick to approve, asking for the saving net of commitments. And the defensible end state is not 'we did a cleanup once'; it is a routine where spend tracks usage, idle pools are shut down, and the few deliberately idle ones are documented and owned.

Back to the library

Part of the learning path Right-size your Azure compute

Right-size or shut down underutilised VM scale sets

Right-sizing VM scale sets: the basics

The pool nobody scaled back down

Finding underutilised scale sets across a subscription

How Azure Advisor decides a scale set is underutiliseddeep dive

What is the impact of leaving scale sets oversized?

How do you right-size a scale set safely?

1. Triage shutdown candidates from resize candidates

2. Prefer reducing the instance count first

3. Resize the SKU only after checking the peak and any reservation

4. Apply the model, then make right-sizing a routine

Quick quiz

Keep learning

Right-sizing VM scale sets: the savings view

The pool nobody scaled back down

How a finance partner frames the right-sizing decision

Why right-sizing belongs on the savings tracker

What finance can do about the right-sizing gap

1. Net the estimate against existing commitments

2. Order the work by how reversible it is

3. Make it a routine and require documented exceptions

Quick quiz

Keep learning

Right-sizing VM scale sets: the headline

The pool nobody scaled back down

What it looks like when spend tracks usage, not history

Why this is a board-level saving

The leadership move on right-sizing

1. Ask for the banked saving, net of commitments

2. Make right-sizing a routine, not a project

3. Treat the deliberate idle capacity as named, owned exceptions

Quick quiz

Keep learning

Related cost lessons