Cost

Commit to an Azure savings plan for compute

One capability across virtual machines, App Service, Container Instances and the rest of eligible compute: take the steady baseline you already run around the clock and pay the discounted committed rate for it instead of full pay-as-you-go, without locking yourself to a single VM size or region.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

A savings plan for compute: the basics

What does Azure Advisor mean by 'consider purchasing a savings plan to unlock lower prices'?

An Azure savings plan for compute is an hourly spend commitment. You agree to spend a fixed amount per hour on eligible compute, for one or three years, and in exchange that usage is billed at a discounted savings plan rate instead of full pay-as-you-go. Each hour, Azure applies the discounted rate to your eligible usage and draws it down against your commitment; usage above the commitment is billed at the normal rate, and any unused commitment in an hour is lost, because the benefit is use-it-or-lose-it per hour and does not roll over.

Azure Advisor raises the recommendation 'Consider purchasing a savings plan for compute to unlock lower prices' when it sees a steady baseline of pay-as-you-go compute that you are running anyway. Advisor builds the recommendation from your own metered usage: it looks back over your recent eligible usage, models what an optimal hourly commitment would be, and reports the commitment amount, the estimated saving against your current pay-as-you-go cost, and the share of your compute that the plan would cover. It surfaces both a one-year and a three-year option for the subscription.

The point that makes a savings plan different from a reservation is flexibility. A reserved instance locks you to a specific VM series, size and region. A savings plan commits only to an hourly amount of spend, and the discount then applies across eligible compute regardless of series, size, operating system or region. That covers Azure Virtual Machines, Azure App Service, Azure Functions on the Premium plan, Azure Container Instances and Azure Dedicated Hosts. So the work here is not 'buy a plan'. It is: find the steady baseline you genuinely run every hour, size the commitment to that floor rather than to your peaks, and let the flexible discount float across whatever eligible compute is running.

In this lesson you will learn what an Azure savings plan for compute actually commits you to, how Advisor sizes the recommendation from your own usage, how it differs from a reservation, and how to buy and monitor one without over-committing. You will see the az CLI to read the recommendation and to purchase a plan, and a Bicep alias you can put under source control so the commitment is a reviewed, version-controlled decision rather than a one-off click in the portal.

Fun fact

The discount that does not care what you run

Azure savings plans were introduced precisely because reservations were too rigid for how modern estates actually evolve. A reservation you bought for a specific D-series VM in West Europe stops helping the moment you resize, move region, or shift the workload onto App Service or containers, and teams were leaving real money on the table every time they modernised. A savings plan was the answer: it commits to an hourly amount of money rather than to a machine, so the discount keeps applying as the underlying compute changes shape. The plan genuinely does not care whether this hour's eligible spend came from a VM, a Premium Functions plan or a container, only that you ran it.

Reading the savings plan recommendation before committing

Priya runs the platform team at a SaaS business whose Azure compute bill has been climbing as they migrate workloads from VMs onto App Service and containers. Azure Advisor has been showing 'Consider purchasing a savings plan for compute to unlock lower prices' on the production subscription for a few weeks.

Rather than accept the headline number, Priya wants to see the recommendation Advisor generated from real usage, the commitment it proposes and the saving it estimates, so the commitment can be sized to the genuine baseline rather than to a peak.

Pull the active cost recommendations for the subscription and filter to the savings plan one, so you are reading Advisor's own numbers rather than a brochure figure.

$ az advisor recommendation list --category Cost \ --query "[?contains(shortDescription.solution, 'savings plan')].{impact:impact, solution:shortDescription.solution}" -o table

Impact Solution

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

High Consider savings plan for compute to save on your compute

# Advisor flags it High impact. Open the recommendation to read the

# proposed hourly commitment, the % saving and the coverage it buys.

Advisor builds this from your own metered usage over the look-back window. Read the proposed commitment, the estimated saving and the coverage percentage in the portal or the benefit recommendations API before you buy.

How Advisor sizes the recommendation and how the discount appliesdeep dive

Advisor and the savings plan purchase experience build the recommendation from your actual on-demand usage and costs, including any negotiated discounts. They look back over your recent eligible usage, model the optimal hourly commitment by applying the savings plan rate to your eligible usage in each hour, and report the commitment amount, the estimated saving against your current pay-as-you-go cost and the share of your compute the plan would cover. Portal recommendations use a 30-day look-back; the benefit recommendations API lets you compare different look-back windows and the one-year against the three-year term.

Once a plan is active, the discount is applied per hour. Each hour Azure prices your eligible usage at the savings plan rate and deducts it from your hourly commitment; usage beyond the commitment is billed at pay-as-you-go, and any commitment not consumed in that hour is forfeit because the benefit does not carry over. If reservations and a savings plan both apply, reservations are matched first and the savings plan picks up remaining eligible usage. This is why a commitment sized below your steady floor stays near 100 per cent utilised: there is always at least that much eligible usage each hour to absorb it.

The commitment itself is final. A savings plan cannot be cancelled, refunded or exchanged for a reservation; you can transfer it between supported agreements and you can trade certain reservations in for a plan, but you cannot undo it. The full hourly amount is owed for the whole term. That single property is what turns sizing into the central decision: commit to the floor and the plan runs fully utilised and risk-free, commit above it and you pay for hours you never filled.

What is the impact of leaving the recommendation unactioned?

The direct impact is a standing overpayment. Every hour the steady baseline runs on pay-as-you-go while a savings plan is available is an hour billed at full list price when a documented discount of up to 65 per cent was on the table. Because the baseline runs continuously, the gap compounds quietly: it is not a one-off, it is a recurring premium on the largest line of the bill that nobody is choosing on purpose.

The second-order impact is that the compute line grows without any corresponding pricing leverage. As an estate migrates from VMs to App Service and containers, a reservation strategy keeps breaking and teams give up on commitment discounts entirely, leaving the whole modernising workload at list price. A savings plan is precisely the instrument that survives that migration, so leaving it unactioned forfeits the one discount mechanism that keeps pace with how the estate actually changes.

The flip side is the risk of over-correcting. The recommendation is not a licence to commit to the Advisor headline blindly: because the plan cannot be cancelled, an oversized commitment converts overpayment into a different waste, paying for committed capacity that goes unused. The impact of doing nothing is a recurring overpayment; the impact of doing it carelessly is a stranded commitment. The capability is the discipline of capturing the first without creating the second.

How do you commit safely and capture the saving?

Work the recommendation as a sizing decision, not a purchase. The order matters: establish the genuine baseline before you commit, so the plan runs fully utilised and you never owe for an unused hour.

1. Read Advisor's own numbers, not the brochure

Open the savings plan recommendation in Advisor or the benefit recommendations API and note the proposed hourly commitment, the estimated saving percentage and the coverage it buys. These are computed from your real usage over the look-back window, so they are the right starting point, but the look-back assumes recent usage continues.

2. Separate the always-on floor from the variable top

Identify the compute that runs every hour regardless of season or roadmap. That floor is what you commit to. The elastic top, anything that scales down overnight, is seasonal, or sits on a workload that may be retired or re-architected, stays on pay-as-you-go so it can never strand a commitment.

3. Size below the floor and choose the term

Set the hourly commitment a little below the genuine floor so it stays near fully utilised even on a quiet hour. Choose the term by certainty: three years for the deepest discount on baseline you are confident about, one year where you want a shorter horizon. Prefer a shared or management group scope so the discount floats across subscriptions rather than stranding in one.

4. Buy it as reviewed code and monitor utilisation

Purchase through a version-controlled Bicep alias rather than an unreviewed portal click, so the commitment is a deliberate, recorded decision. After it is live, watch the utilisation percentage in Cost Management; if it sits at or near 100 per cent you have sized it well, and you can consider a second, incremental plan for any new steady baseline.

# Option A: purchase via the Azure CLI (billing-benefits extension auto-installs).
# Size --commitment BELOW your genuine always-on floor so it stays fully utilised.
# A savings plan cannot be cancelled, so commit only to the baseline you are sure of.
az billing-benefits savings-plan-order-aliases create \
  --order-alias-name "prod-compute-baseline" \
  --display-name "Prod compute baseline" \
  --applied-scope-type Shared \
  --billing-scope-id "/subscriptions/<billing-subscription-id>" \
  --billing-plan P1M \
  --term P3Y \
  --sku Compute_Savings_Plan \
  --commitment "{amount:5.0,currency-code:USD,grain:Hourly}"

# Option B (preferred): the same purchase as a reviewed, version-controlled Bicep alias.
# Save as savings-plan.bicep and deploy with: az deployment tenant create -l <region> -f savings-plan.bicep
#
#   targetScope = 'tenant'
#   resource plan 'Microsoft.BillingBenefits/savingsPlanOrderAliases@2024-11-01-preview' = {
#     name: 'prod-compute-baseline'
#     sku: { name: 'Compute_Savings_Plan' }
#     properties: {
#       displayName: 'Prod compute baseline'
#       billingScopeId: '/subscriptions/<billing-subscription-id>'
#       billingPlan: 'P1M'
#       term: 'P3Y'
#       appliedScopeType: 'Shared'
#       commitment: { amount: 5, currencyCode: 'USD', grain: 'Hourly' }
#     }
#   }

Quick quiz

Question 1 of 5

Azure Advisor shows 'Consider purchasing a savings plan for compute to unlock lower prices'. What exactly does a savings plan commit you to?

Keep learning

Go deeper on how Azure prices, sizes and applies a savings plan for compute across the eligible services.

You can now treat the savings plan recommendation as one capability rather than a single click: read Advisor's own numbers, separate the always-on floor from the variable top, size the commitment below the floor on the right term, and buy it as reviewed Bicep before watching utilisation confirm the fit. The discount commits to spend rather than to a machine, so it survives the migrations that strand reservations.

Back to the library

A savings plan for compute: the savings view

Turning steady compute you already pay full price for into a committed, discounted rate

This is one of the few Advisor recommendations that puts money back on the bill rather than asking for more of it. Microsoft documents savings of up to 65 per cent off pay-as-you-go for eligible compute when you commit, with the exact percentage shown per recommendation from your own usage. The saving is not hypothetical: Advisor calculates it from the compute you are already running at full price, so the question is simply how much of that steady baseline you are willing to commit to for one or three years.

Read the recommendation as a discount on spend you have already decided to incur, not as new spend. The commitment covers a floor of usage you run every hour anyway, and a three-year term discounts harder than a one-year term. The trade is duration and certainty: you exchange flexibility for a lower rate, and the lower the floor you commit to, the safer the trade.

The one caution that belongs on the finance side is that a savings plan is a firm financial commitment. It cannot be cancelled, refunded or exchanged once purchased: the full hourly amount is owed for the full term whether or not you use it. That is what makes sizing to the genuine baseline, rather than to optimistic peaks, the whole game. Commit to the floor and the plan is close to risk-free; commit above it and you can pay for hours you never used.

This lesson is for the finance partner who sees a savings recommendation on the Azure bill and wants to know what it really saves, what the commitment locks in, and how to size it so the saving is banked without ever paying for unused hours. It covers why the saving is calculated from real usage, why a savings plan beats a reservation when workloads move, and the one-way nature of the commitment that makes conservative sizing the safe play.

Fun fact

The discount that does not care what you run

How a finance partner frames the savings plan decision

Priya is the finance partner to the platform team. The Advisor recommendation lands as a high-impact item promising a double-digit percentage off the compute line. The instinct is not to wave the purchase through at the size Advisor proposes, nor to dismiss it as a lock-in to avoid; it is to separate the part of the saving that is genuinely risk-free from the part that carries judgement. Advisor sizes its recommendation to a look-back window, so the headline commitment assumes recent usage continues. Priya's job is to ask which slice of that usage is the true floor, the compute the business runs every hour regardless of season or roadmap, and which slice is variable and should stay on pay-as-you-go.

Priya asks the team to split the proposed commitment into the always-on baseline and the elastic top. The always-on baseline is committed at the three-year rate, because nobody disputes it will still be running, and that books the deepest discount on the largest, safest chunk of spend. The variable top is left uncommitted, so a workload that gets retired or re-architected never strands a commitment. The finance pack reads: 'We are banking the documented discount on the steady baseline we run anyway, sized below the Advisor number so we never owe for an unused hour, and leaving the variable top flexible. The saving is real and recurring; the only thing we have given up is flexibility on capacity we were never going to switch off.'

Why the savings plan belongs on the cost-optimisation register

The cost model here is unusually favourable, which is rare for a commitment. The saving is calculated by Microsoft from your own metered usage rather than projected, so the upside is concrete: a documented discount of up to 65 per cent off pay-as-you-go on the baseline you commit, banked every hour for one or three years. There is no Azure spend required to capture it; the plan simply reprices compute you already run.

The only real cost is the cost of getting the size wrong, and it is bounded and controllable. A savings plan cannot be cancelled, refunded or exchanged, so an over-sized commitment means owing for unused hours until the term ends. The finance discipline is therefore to size to the genuine, defensible floor of always-on usage, sit deliberately below the Advisor headline, and leave the variable top on pay-as-you-go. Done that way the recommendation is close to free money: a recurring saving on spend you had already committed to in practice, with the downside engineered out by conservative sizing.

What finance can do about the savings plan decision

Finance cannot size an hourly commitment from the technical side, but it owns the framing that turns an Advisor headline into a conservative, defensible saving with the downside engineered out. Three levers.

1. Commit to the floor, not the Advisor headline

Make explicit that the Advisor number assumes recent usage continues, so the commitment should be sized to the genuine always-on floor and set deliberately below it. The saving on that floor is concrete and recurring; the variable top stays on pay-as-you-go. The metric that belongs on the cost review is the saving banked on the committed baseline, not the largest commitment the tool will propose.

2. Treat the term as a certainty decision

A three-year term discounts harder than a one-year term, and the right term is a function of how certain the baseline is. Commit the rock-solid floor at three years for the deepest rate, and use a one-year term where the horizon is genuinely shorter. The duration is the price you pay for the discount, so match it to the confidence you have in the usage, not to optimism about growth.

3. Make the one-way nature explicit and conservative by default

Because a savings plan cannot be cancelled, refunded or exchanged, the finance position should default to under-committing and topping up. It is always possible to add a second incremental plan when a new steady baseline appears; it is never possible to claw back an over-sized one. Recording that 'we sized below the floor on purpose' is exactly what makes the commitment defensible in any later review.

Quick quiz

Question 1 of 5

Advisor estimates a double-digit percentage saving on the compute line. As the finance partner, how should you read that number?

Keep learning

Go deeper on how Azure prices, sizes and applies a savings plan for compute across the eligible services.

You have finished the finance view of the savings plan. You know the saving is concrete, calculated from your own usage, and recurring for the term, and that the only real cost is the cost of over-sizing an uncancellable commitment. Next time the recommendation lands, you will commit to the genuine floor, set the hourly amount below it, match the term to your certainty, leave the variable top flexible, and ask for utilisation as the proof the saving is real.

Back to the library

A savings plan for compute: the headline

Whether the estate is paying full list price for compute it runs every hour regardless

Compute is usually the largest single line on an Azure bill, and a meaningful share of it is steady: workloads that run around the clock at a predictable floor. Paying full pay-as-you-go for that floor is paying a premium for flexibility you are not using. A savings plan converts that floor to a committed, discounted rate, and Microsoft documents the saving at up to 65 per cent on eligible compute.

The leadership question is not 'should we chase a discount?' It is 'are we paying list price for compute we are certain to run for the next one to three years?' If Advisor is showing the recommendation, the answer is yes, and the saving is calculated from your own usage rather than estimated.

The one decision that needs a steady hand is the size of the commitment, because a savings plan cannot be cancelled. Sized to the genuine baseline it is close to risk-free recurring saving. Sized to optimistic growth it can mean paying for capacity you do not use. The right posture is to commit confidently to the floor and leave the variable top of the workload on pay-as-you-go.

A short read for the leader who needs to know why the estate is paying full price for compute it runs anyway, what a one or three year commitment buys, and where the single real risk sits: sizing the commitment to the genuine baseline rather than to hoped-for growth, since the plan cannot be cancelled.

Fun fact

The discount that does not care what you run

What it looks like when the compute baseline is bought at the committed rate, not list price

At a cost review the CFO noticed the Azure compute line had grown steadily for four quarters and asked the obvious question: are we getting any volume discount, or paying list price like a first-time customer? The honest answer at the time was that the estate was almost entirely on pay-as-you-go, because the team had shied away from reservations after an earlier one was stranded by a region migration, and nobody had revisited the question since savings plans arrived.

The team's response was to stop treating the commitment as all-or-nothing. They read the Advisor recommendation, identified the always-on baseline that runs every hour regardless of the roadmap, and committed a savings plan to a level set deliberately below that floor, on a three-year term for the deepest rate. The variable, modernising part of the workload stayed on pay-as-you-go where its flexibility was actually worth paying for. The next time the CFO asked, the answer had changed from 'we pay list price' to 'the steady baseline is on a committed discounted rate that books a recurring saving, and the part of the estate that still moves is left flexible on purpose.' That shift, from paying a flexibility premium on compute that never moves to paying the committed rate for it, is the recurring saving this capability delivers.

Why this is a margin decision worth leadership attention

Compute is typically the biggest controllable line on the cloud bill, and a savings plan is the lever that lowers its unit cost on the steady portion without changing anything the engineers build. The saving is documented at up to 65 per cent and is computed from real usage, so this is one of the clearest margin improvements available: it reduces recurring cost on capacity the business runs regardless, and it requires no migration or re-architecture to capture.

The reason it warrants a leadership eye rather than a rubber stamp is the one-way nature of the commitment. This is the rare cost lever where the upside is large and well evidenced and the only risk is self-inflicted, by committing to more than the genuine baseline. The right leadership posture is to approve the saving on the steady floor confidently and to insist the sizing is conservative, so the estate captures a recurring discount without ever stranding a commitment.

The leadership move on the savings plan

The executive handle is not to pick an hourly number; it is to authorise capturing the discount on the steady baseline while insisting the sizing is conservative because the commitment is one-way.

1. Authorise the saving on the genuine baseline

Approve a savings plan committed to the always-on floor of compute, on the longest term the team is confident in, so the documented discount is banked as a recurring reduction in unit cost. This is a margin improvement on spend the business runs regardless, and it needs a decision, not a study.

2. Insist on conservative sizing because it cannot be undone

The only real risk is over-committing, since the plan cannot be cancelled. Ask that the commitment is set below the genuine floor and that the variable, modernising part of the estate is left on pay-as-you-go on purpose. Under-commit and top up later; never reach for the headline number to look aggressive on savings.

3. Ask for utilisation as the proof it was sized right

The proof the commitment was sized well is not the purchase itself; it is a utilisation percentage sitting at or near 100 per cent in Cost Management once the plan is live. Ask for that figure after the first weeks, because near-full utilisation is the evidence that the saving is real and no committed hour is being wasted.

Quick quiz

Question 1 of 5

At a cost review you ask whether the estate gets any volume discount on compute or pays list price. What end state should you be looking for as the answer?

Keep learning

Go deeper on how Azure prices, sizes and applies a savings plan for compute across the eligible services.

Two takeaways. A savings plan is the rare margin lever where the upside is large, documented and computed from real usage, and the only risk is self-inflicted by over-committing on a one-way commitment. And the defensible end state is not 'everything is committed'; it is the steady baseline on a committed discounted rate, the modernising part left flexible on purpose, and utilisation near 100 per cent proving the size was right.

Back to the library

Part of the learning path Lock in Azure commitments

Commit to an Azure savings plan for compute

A savings plan for compute: the basics

The discount that does not care what you run

Reading the savings plan recommendation before committing

How Advisor sizes the recommendation and how the discount appliesdeep dive

What is the impact of leaving the recommendation unactioned?

How do you commit safely and capture the saving?

1. Read Advisor's own numbers, not the brochure

2. Separate the always-on floor from the variable top

3. Size below the floor and choose the term

4. Buy it as reviewed code and monitor utilisation

Quick quiz

Keep learning

A savings plan for compute: the savings view

The discount that does not care what you run

How a finance partner frames the savings plan decision

Why the savings plan belongs on the cost-optimisation register

What finance can do about the savings plan decision

1. Commit to the floor, not the Advisor headline

2. Treat the term as a certainty decision

3. Make the one-way nature explicit and conservative by default

Quick quiz

Keep learning

A savings plan for compute: the headline

The discount that does not care what you run

What it looks like when the compute baseline is bought at the committed rate, not list price

Why this is a margin decision worth leadership attention

The leadership move on the savings plan

1. Authorise the saving on the genuine baseline

2. Insist on conservative sizing because it cannot be undone

3. Ask for utilisation as the proof it was sized right

Quick quiz

Keep learning

Related cost lessons