Cost

Move spiky VMs to burstable B-series SKUs

One capability across your VM and scale-set estate: find the machines that sit nearly idle most of the time but occasionally spike, and move them onto burstable B-series SKUs so you pay for the baseline you actually use instead of a full-time core you do not.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Burstable B-series SKUs: the basics

What does an over-provisioned, spiky VM actually look like?

A surprising share of any Azure estate is made up of virtual machines that are almost always idle and occasionally busy: a build agent that sits at a few percent CPU until a pipeline runs, a small line-of-business app that wakes up at month-end, a dev box that is busy for an hour and quiet for the rest of the day. On a general-purpose Dsv5 or Dv5 SKU you pay for that machine as if it ran flat-out around the clock, because those SKUs provision full, dedicated vCPUs whether you use them or not. The shape of the waste is the same every time: a low average CPU with intermittent spikes, sitting on a SKU priced for sustained load.

Azure Advisor surfaces exactly this pattern. Inside its VM and virtual machine scale set right-size engine, the 'Optimise spend by resizing or shutting down underutilised instances' recommendation can suggest moving a machine to a burstable B-series SKU with the same number of cores, so you keep the vCPU count but pay a lower rate. Advisor only makes the burstable call when it has looked at roughly the last seven days of CPU and determined that the B-series credit model can cover your average utilisation. That last point is the whole game: B-series is not a smaller machine, it is a different billing model that rewards low average use.

The mechanism behind a B-series SKU is a CPU credit. Each size has a baseline CPU performance, expressed as a percentage of a full vCPU. Run below that baseline and you bank credits; run above it, during a spike, and you spend the credits you banked. As long as your quiet periods refill the bucket faster than your busy periods drain it, you get full-core bursts when you need them and a much lower bill the rest of the time. The work in this lesson is to find every VM whose real-world behaviour fits that model, move it across safely, and avoid the handful that genuinely run hot and would be starved of credits.

In this lesson you will learn how Azure prices burstable B-series SKUs, how the CPU credit model decides whether a workload fits, how Azure Advisor identifies the candidates in your estate, and how to move VMs across safely without starving the few that genuinely run hot. You will leave able to turn the Advisor burstable recommendation into a prioritised, reversible savings plan.

Fun fact

The bucket that fills while you sleep

A B-series VM quite literally banks CPU while it is idle. Each size has a baseline performance, a percentage of a full vCPU, and Azure tracks a credit balance per minute: run below the baseline and the balance climbs, run above it and the balance falls. A single vCPU B-series machine starts life with thirty credits and tops up continuously whenever it is quiet, up to a per-size cap. The practical upshot is that a build agent idling overnight wakes up with a full bucket, ready to spend a burst of real cores on the morning's first pipeline, then refills through the quiet afternoon. The whole model is a bet, made by Azure and confirmed by Advisor against your last seven days of CPU, that your idle time more than pays for your busy time.

Finding burstable candidates across a subscription

Priya runs the platform team at a growing SaaS company. The monthly Azure invoice has crept up faster than usage, and Azure Advisor's Cost tab is showing a stack of resize recommendations, several of them suggesting a move to burstable B-series SKUs.

Rather than click through each recommendation in the portal, Priya pulls the cost recommendations from the CLI so the burstable candidates can be listed, sized and ordered by saving before anything is touched.

List the Advisor cost recommendations and pick out the ones that point at a burstable resize. The shortDescription and impactedValue tell you what to move and what it is costing.

$ az advisor recommendation list --category Cost \ --query "[?contains(shortDescription.solution, 'burstable')].{vm:impactedValue, saving:extendedProperties.savingsAmount, impact:impact}" -o table

Vm Saving Impact

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

build-agent-01 41 Medium

lob-reporting-vm 38 Medium

api-prod-03 12 Low

# build-agent-01 idles overnight, then spikes on each pipeline: a textbook burstable fit.

Advisor only suggests burstable when it has judged the B-series credits sufficient for your average CPU over the last seven days. Order the list by saving, not by the order it returns.

How the B-series credit model decides whether a VM fitsdeep dive

Every B-series size has a published baseline CPU performance, given as a percentage of a full vCPU, and a matching rate of credits banked per hour. A Standard_B2ts_v2, for example, has a 20 percent baseline and banks 24 credits per hour; a Standard_B2ls_v2 has a 30 percent baseline and banks 36 credits per hour. The machine accrues credits whenever its actual CPU sits below the baseline and consumes them whenever it runs above. Microsoft gives the per-minute figure as ((baseline CPU percent times vCPU count) minus (actual CPU percent times vCPU count)) divided by 100, so a quiet machine fills its bucket steadily and a busy one drains it.

The credit balance is capped per size and a freshly started VM begins with an initial allocation of thirty credits per vCPU. While credits remain, the VM can burst up to a full vCPU per core. The moment the balance hits zero, performance is throttled back to the baseline until enough quiet time refills the bucket. That throttle is the one failure mode that matters: a machine whose busy periods consistently outweigh its quiet ones will run out of credits and then crawl, which is precisely the workload Azure Advisor is built to exclude.

Advisor's burstable recommendation leans on this. It evaluates roughly the last seven days of CPU telemetry and only proposes the move when the candidate B-series size's credit accrual can sustain the workload's observed average. That is why the recommendation is conservative and why acting on it is low-risk: Azure has already checked the fit against real data. The remaining judgement is yours for workloads with rare but heavy spikes that a seven-day average can mask, and for anything where consistent full-core performance is a hard requirement rather than a nice-to-have.

What is the impact of leaving spiky VMs on dedicated-core SKUs?

The direct impact is a recurring overspend. A machine that is idle most of the day on a Dsv5 or Dv5 SKU is billed at the sustained-use rate every hour, including the long stretches where it does almost nothing. Multiply that gap by a fleet of build agents, dev boxes, small internal apps and seldom-used utility VMs and the unnecessary spend becomes a standing line on the invoice that grows every time someone provisions another part-time machine on a full-time SKU.

The second-order impact is drift. Without a routine that reviews the Advisor cost recommendations, over-provisioned machines accumulate silently. Each one looks individually trivial, which is exactly why nobody acts, and the aggregate only becomes visible when the bill forces a review. By then the saving has been leaking for months, and the catch-up is a project rather than a habit.

There is an opportunity-cost angle too. Money spent on idle cores is money not spent on the workloads that actually need capacity, on reservations for the genuinely steady machines, or on the product itself. Burstable SKUs are a low-effort way to stop funding capacity nobody is using, and because Advisor has already pre-qualified the candidates against real telemetry, the saving is available with very little analysis on your side.

How do you move VMs to burstable SKUs safely?

Work the recommendation as one loop rather than clicking through Advisor one VM at a time. The order matters: confirm the fit and check for spike-heavy outliers before you resize, so you do not throttle a machine that genuinely needs sustained cores.

1. Pull the burstable candidates and price them

Export the Advisor cost recommendations and filter to the burstable resizes. For each candidate, note the current SKU and the proposed B-series SKU, and price both from the rate card for the region so you have a real per-VM saving rather than a single Advisor estimate. Order the list by recurring saving.

2. Sanity-check the spike profile

Advisor already judged the fit against seven days of average CPU, but check candidates that run rare, heavy spikes a seven-day average can hide. Look at peak CPU and how long peaks last. A machine that bursts hard for hours, not minutes, may exhaust its credits and throttle, so leave those on dedicated cores and note them as deliberate exceptions.

3. Resize, in a maintenance window if needed

Resizing a VM requires a reboot, and a deallocate-and-start if the target size is not available on the VM's current hardware cluster. For most machines this is a brief interruption to schedule; for anything user-facing, do it in a window. Move the highest-saving, clearly idle machines first.

4. Make burstable the default and review on a cadence

Bake the burstable SKU into the infrastructure-as-code template for new idle-but-spiky workloads so the saving is the default, not a later clean-up. Put the Advisor cost review on a monthly cadence so newly over-provisioned machines are caught as they appear, and keep the deliberate dedicated-core exceptions documented so nobody resizes them by mistake.

# 1. Resize a confirmed burstable candidate. A reboot is required.
#    Replace the size with the exact SKU Advisor proposed for this VM.
az vm resize \
  --resource-group rg-platform \
  --name build-agent-01 \
  --size Standard_B2ts_v2

# 2. If the target size is not available on the current hardware cluster,
#    the resize fails. Deallocate, resize, then start.
az vm deallocate --resource-group rg-platform --name build-agent-01
az vm resize    --resource-group rg-platform --name build-agent-01 --size Standard_B2ts_v2
az vm start     --resource-group rg-platform --name build-agent-01

# 3. Make burstable the default for new idle-but-spiky workloads in Bicep:
#
#    resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
#      name: 'build-agent-02'
#      location: location
#      properties: {
#        hardwareProfile: {
#          vmSize: 'Standard_B2ts_v2'
#        }
#        // ...osProfile, storageProfile, networkProfile
#      }
#    }

Quick quiz

Question 1 of 5

Azure Advisor recommends moving a VM to a burstable B-series SKU. What does that change about the machine?

Keep learning

Go deeper on how the B-series credit model works, how Advisor sizes the recommendation, and how to resize a VM cleanly.

You can now treat burstable SKUs as one capability rather than a stack of individual Advisor clicks: pull the candidates, price the saving from the real rate card, sanity-check the spike-heavy outliers, resize the confirmed fits with a reboot, and make burstable the default for new idle-but-spiky workloads. You know the change is reversible, so the risk of acting is small and the saving recurs every hour.

Back to the library

Burstable B-series SKUs: the savings view

A right-size move that lowers the per-hour rate on idle-but-spiky VMs with no loss of capacity

This is one of the cleaner savings levers in Azure compute because it does not ask anyone to give up cores or accept a slower machine. A B-series SKU keeps the same vCPU count Advisor matched it to; it simply charges a lower published hourly rate in exchange for a credit-based performance model. For a workload that is genuinely idle most of the time, the burstable rate is materially cheaper than the equivalent Dsv5 or Dv5, and the saving recurs every hour the machine exists. Quote the saving from each VM's own before-and-after rate in the Azure pricing data rather than a blanket percentage, because the gap varies by size and region.

Treat the Advisor list as a backlog ordered by recurring saving, not as a queue to clear top to bottom. A handful of busy VMs that Advisor would never recommend for B-series should not be on the list at all; the value sits in the long tail of small, idle machines whose individual saving looks trivial but whose sum is not. The finance question is simple: what is the monthly run-rate today across the candidate VMs, and what does it become once they are on burstable SKUs.

The cost of acting is close to zero. The resize itself is free, the only operational cost is a short reboot per machine, and the change is fully reversible: if a VM turns out to run hotter than its credits allow, you resize it straight back. That makes this a low-regret saving you can approve broadly rather than one machine at a time.

This lesson is for the finance partner who sees a burstable resize recommendation in Azure Advisor and wants to know what it really saves, how to size the opportunity across the estate, and how to be sure the saving is durable rather than a number that evaporates the first time a VM gets busy. It covers how to read the saving per VM, how to order the backlog by run-rate, and why this is a low-regret approval.

Fun fact

The bucket that fills while you sleep

How a finance partner sizes the burstable opportunity

Priya is the finance partner working with the platform team on a cost-reduction target. The Advisor export lands with fourteen burstable resize candidates, and the instinct is not to celebrate fourteen wins; it is to ask what the total recurring saving actually is and how durable it is. She pulls each candidate's current SKU and the burstable SKU Advisor proposed, then prices both from the Azure rate card for the subscription's region, so the saving is the real before-and-after per-hour gap multiplied out to a month, not Advisor's single estimate taken on faith.

The picture sharpens once the numbers are lined up. Two larger idle machines, a reporting VM and a build agent, account for most of the saving; the rest is a long tail of small dev and utility boxes each saving a modest amount but adding up to a worthwhile second tranche. Priya reframes the list as a run-rate: 'These fourteen VMs cost X a month today and Y on burstable SKUs, a recurring saving of X minus Y, applied with one reboot each and reversible in minutes if any of them runs hotter than expected.' The finance pack reads as a durable run-rate reduction with a near-zero cost of action and a clearly bounded downside, which is exactly the kind of saving that gets approved in a single pass.

Why burstable belongs near the top of the savings backlog

The trade-off here is unusually favourable. The saving is recurring and predictable, the cost of action is a single reboot per VM, and the change is fully reversible, so the downside is bounded to 'we resize it back.' That combination, a durable saving against a near-zero cost and a capped risk, is rare enough that burstable resizes deserve a high place on the savings backlog rather than being left as housekeeping.

Quantify it from the real rate card. For each candidate, take the current SKU's hourly rate and the proposed B-series rate in the subscription's region, take the difference, and multiply by the hours the machine runs in a month. Summed across the candidate fleet, that is the monthly run-rate reduction, and it is the number to track. The finance role is to keep the list ordered by saving and to make sure the long tail of small machines is swept up too, because individually they are ignorable and collectively they are not.

What finance can do about the burstable opportunity

Finance cannot resize a VM, but it owns the framing that turns a stack of Advisor recommendations into a prioritised, durable saving with a near-zero cost of action. Three levers.

1. Price the saving from the real rate card, not the single estimate

Take each candidate's current SKU rate and proposed B-series rate in the subscription's region, difference them, and multiply by monthly run hours. That gives a defensible per-VM saving and a fleet-wide run-rate reduction you can put your name to, rather than relying on Advisor's headline number. Track the monthly run-rate before and after as the metric that proves the saving stuck.

2. Order by saving and sweep the long tail

A couple of larger idle machines usually carry most of the saving, but the long tail of small dev and utility VMs is where this quietly adds up. Each one looks ignorable on its own, which is exactly why it gets ignored. Insist the whole candidate list is worked, not just the top few, and report the aggregate so the small machines are not left on the table.

3. Frame it as low-regret and approve it broadly

The cost of acting is a reboot, and the change is reversible in minutes if a VM throttles. That bounded downside is the case for approving the whole burstable backlog in one pass rather than negotiating machine by machine. Reserve the only real caveat, the genuinely busy VMs Advisor never recommended, as documented exceptions and move everything else.

Quick quiz

Question 1 of 5

Azure Advisor lists fourteen burstable resize candidates. As the finance partner, how should you size the opportunity?

Keep learning

Go deeper on how the B-series credit model works, how Advisor sizes the recommendation, and how to resize a VM cleanly.

You have finished the finance view of moving VMs to burstable SKUs. You know the saving is recurring and priced from the before-and-after rate per VM, that the long tail of small machines is worth sweeping up alongside the big ones, and that the cost of acting is a reboot against a bounded, reversible downside. Next time an Advisor burstable recommendation lands, you will size it as a run-rate reduction, order it by saving, and approve the whole low-regret backlog in one pass rather than negotiating machine by machine.

Back to the library

Burstable B-series SKUs: the headline

Whether the estate is paying full-time rates for machines that are busy part-time

A large part of most cloud bills is paid for capacity that sits idle. Burstable SKUs are Azure's built-in answer to one slice of that: machines that are quiet most of the time and busy occasionally. Moving them onto a billing model priced for their real behaviour lowers the run-rate without removing any capability, and Azure Advisor already identifies the candidates.

The leadership question is not 'can we cut compute?' It is 'are we paying sustained-use rates for part-time workloads, and is there a routine that catches that drift as it accumulates?' The defensible end state is that idle-but-spiky machines default to burstable SKUs, the genuinely busy ones are deliberately left on dedicated cores, and the Advisor recommendation is reviewed on a cadence rather than discovered during a cost panic.

This is a low-risk saving. The change is reversible in minutes, costs nothing to apply beyond a reboot, and does not touch the application. It is the kind of routine optimisation that should be a standing process, not a one-off project.

A short read for the leader who needs to know why part-time workloads on full-time SKUs are a recurring cost leak, what burstable SKUs do about it, and why moving the right machines across is a low-risk, reversible saving worth making a standing routine rather than a special project.

Fun fact

The bucket that fills while you sleep

What it looks like when part-time workloads stop paying full-time rates

During a cost review, the CFO pointed at the compute line and asked the obvious question: usage is flat, so why is the bill climbing? The honest answer was that the estate had quietly filled up with machines provisioned for peaks they rarely hit, each one billed at a sustained-use rate around the clock regardless of how idle it sat.

The team's response was to make burstable a default rather than an afterthought. They worked the Advisor cost recommendations, moved every machine that fitted the credit model onto a B-series SKU, deliberately left the genuinely busy ones on dedicated cores, and then put the Advisor cost review on a monthly cadence so new idle machines get caught as they appear rather than a year later. At the next review the compute line had a visible step down and, more importantly, a story behind it: the estate now pays part-time rates for part-time workloads by routine, not by luck. That shift, from discovering waste in a panic to catching it on a cadence, is the durable win this capability delivers, and it costs nothing but a reboot to reach.

Why this is a standing cost-discipline issue

Idle capacity billed at full rates is the most common form of cloud waste, and burstable SKUs address one clean, well-bounded slice of it. The risk of leaving it unaddressed is not a single large event; it is a slow, compounding leak that grows every time a part-time workload lands on a full-time SKU and nobody resizes it.

The cost of fixing it is trivial and the saving is durable, which makes this the kind of optimisation that should run as a routine rather than a rescue. The leadership signal worth asking for is not 'how much did we save once' but 'is the Advisor cost review on a cadence, so part-time workloads default to part-time pricing without anyone having to remember.'

The leadership move on burstable SKUs

The executive handle is not to approve each resize; it is to require that idle-but-spiky workloads default to burstable pricing and that the Advisor cost review runs on a cadence, so the saving is structural rather than a one-off.

1. Make burstable the default, not a clean-up

Ask that new idle-but-spiky workloads start on a burstable SKU in the infrastructure-as-code template, so the estate stops accumulating over-provisioned machines in the first place. Catching waste at provisioning time is far cheaper than catching it in a year-end review.

2. Put the Advisor cost review on a cadence

Require a monthly look at the Advisor cost recommendations so newly over-provisioned machines are resized as they appear. The signal of success is not a one-time saving figure; it is that part-time workloads land on part-time pricing by routine, without anyone needing to remember.

3. Document the deliberate dedicated-core exceptions

A handful of machines genuinely run hot and belong on dedicated cores; that is correct, not a miss. The leadership requirement is that each is a recorded, owned decision rather than an oversight, so the goal is zero accidentally over-provisioned machines, not zero dedicated-core machines.

Quick quiz

Question 1 of 5

Compute spend is climbing while usage is flat. What does the burstable opportunity tell you about why?

Keep learning

Go deeper on how the B-series credit model works, how Advisor sizes the recommendation, and how to resize a VM cleanly.

Two takeaways. Part-time workloads on full-time SKUs are a quiet, compounding cost leak, and burstable SKUs are a low-risk, reversible way to stop funding idle cores. And the durable win is not a one-time saving figure; it is making burstable the default for new idle workloads and putting the Advisor cost review on a cadence, so part-time pricing happens by routine rather than by a year-end scramble.

Back to the library

Part of the learning path Right-size your Azure compute

Move spiky VMs to burstable B-series SKUs

Burstable B-series SKUs: the basics

The bucket that fills while you sleep

Finding burstable candidates across a subscription

How the B-series credit model decides whether a VM fitsdeep dive

What is the impact of leaving spiky VMs on dedicated-core SKUs?

How do you move VMs to burstable SKUs safely?

1. Pull the burstable candidates and price them

2. Sanity-check the spike profile

3. Resize, in a maintenance window if needed

4. Make burstable the default and review on a cadence

Quick quiz

Keep learning

Burstable B-series SKUs: the savings view

The bucket that fills while you sleep

How a finance partner sizes the burstable opportunity

Why burstable belongs near the top of the savings backlog

What finance can do about the burstable opportunity

1. Price the saving from the real rate card, not the single estimate

2. Order by saving and sweep the long tail

3. Frame it as low-regret and approve it broadly

Quick quiz

Keep learning

Burstable B-series SKUs: the headline

The bucket that fills while you sleep

What it looks like when part-time workloads stop paying full-time rates

Why this is a standing cost-discipline issue

The leadership move on burstable SKUs

1. Make burstable the default, not a clean-up

2. Put the Advisor cost review on a cadence

3. Document the deliberate dedicated-core exceptions

Quick quiz

Keep learning

Related cost lessons