Azure reservations or Savings Plan?

Content reviewed: 29 October 2026

A team regularly shuts down its development virtual machines overnight and expects a Savings Plan to reduce costs further. The offer looks attractive because it shows a lower hourly rate. But the commitment applies every hour, while the development environment runs for only part of the day. An oversized commitment can leave the company paying more than it would on demand.

Choose a reservation or Savings Plan using hourly consumption after removing waste, rather than the total monthly bill. The largest advertised discount does not automatically produce the lowest final cost. This article distinguishes utilisation from coverage, calculates a break-even point and shows which costs must not be counted twice.

This article covers Azure Savings Plan for compute and compute reservations. Microsoft also distinguishes a database Savings Plan; its eligible services and price components differ. Do not transfer compute-plan rules to database products merely because their names are similar. The current Savings Plans overview distinguishes the scope of both offers.

What each option buys

Reservations and Savings Plan provide pricing benefits in return for a commitment. They do not replace correct resource sizing or reduce the number of VMs you need. A compute Savings Plan does not guarantee datacentre capacity either; the Azure product FAQ states this limitation explicitly.

Microsoft's decision guidance recommends resizing resources and eliminating unused ones first, reviewing existing commitments next, and purchasing new ones only afterwards. Otherwise, you may commit for years to consumption that you intend to eliminate.

For the finance team, split the proposal into two questions: how much infrastructure do we actually need, and how should we pay for its verified baseline? Architecture and operations answer the first; the pricing model answers the second. Buying a discount does not demonstrate that an oversized server has been addressed.

An hourly commitment is not a monthly wallet

Savings Plan applies its benefit hour by hour. Any unused part of a particular hour does not carry over to the evening, the next day or month end. Eligible consumption draws down the commitment at the applicable plan rate; do not compare it mechanically with nominal on-demand spending.

Where a reservation and a plan overlap, the reservation applies to matching consumption first. Only the remaining consumption can use Savings Plan. These rules and periodically updated prices are described in Savings Plan discount application.

The practical consequence: if you buy a plan in January based on today's uncovered consumption, then reserve the same stable baseline in February, the original plan may have less consumption left to cover. Simulate both purchases together. Reservation and Savings Plan discounts do not simply add up on the same unit of compute.

Worked example: when a discount makes a scheduled VM cost more

The following model uses invented rates in monetary units, not current Microsoft prices. It assumes one constant VM size, an identical benefit scope, no other eligible resources, no reservation and unchanged rates. It includes compute only, excluding software, disks, networking, tax and currency effects.

On-demand operation costs 1 unit per hour. The plan rate is 0.60 units per hour for the same compute, a hypothetical 40% discount. We purchase a commitment of 0.60 for each of the day's 24 hours. The daily commitment costs 14.40 units regardless of how long this single VM runs.

In the third row, the lower offered rate has not produced a lower daily bill. The commitment is too large for this isolated workload. If other eligible consumption exists within the same plan scope during those idle hours, however, the outcome can change. This model does not prove that Savings Plan is unsuitable for all development environments. It shows why the hourly pattern of the entire eligible environment matters.

The break-even point in this model

The commitment cost of 14.40 equals the on-demand cost at 14.4 runtime hours per day. At precisely that duration, there is no saving. The 40% above is the maximum modelled saving at full utilisation, not an automatic saving on signing.

For this simplified case: utilisation required to break even = plan rate / comparable on-demand rate. Here, 0.60 / 1.00 = 60%. This is our own derivation from the stated assumptions. With multiple meters, changing prices or existing commitments, use an hourly simulation of actual data. This example does not establish a universal percentage for an entire Azure account.

Utilisation and coverage answer different questions

Commitment utilisation shows whether you consumed what you committed to buy. Here, coverage means the share of the eligible consumption being analysed that received a commitment benefit. State whether your report calculates the ratio using compute units, reference on-demand value or another basis. Do not combine different bases into a single percentage.

According to the utilisation report documentation, initial data can take up to 48 hours to appear. Subsequent processing introduces further delay. Do not judge a new plan from its first few hours or mix incomplete data with closed reporting periods.

A reservation need not be tied to one exact size

Comparisons of flexibility often overlook instance size flexibility. A supported reservation can apply to different compatible sizes within the relevant group and region. The number of covered instances depends on size ratios. One larger VM and two smaller VMs therefore cannot be compared by machine count alone.

Verify the exact groups and ratios in the instance size flexibility documentation. Two sizes with the letter D in their names need not belong to the same flexibility group. Before a migration, record the original and target SKUs, the region and the specific compatibility rule.

Three operating scenarios

• Stable database server on an Azure VM: compare a reservation for its compute baseline with a plan, and assess software licensing separately. Resizing within a verified compatible group need not invalidate the reservation.
• Gradual application migration from VMs to another eligible compute service: Savings Plan may offer broader applicability. Verify the destination service and actual meter; being in the cloud does not itself establish eligibility.
• Development running only on weekdays: model its hourly profile alongside other resources. A monthly average hides unused nights and weekends.

Separate compute from Windows, SQL and other charges

A compute Savings Plan does not automatically cover the full price of a Windows VM. Microsoft provides a separate list of software meters outside the plan. Disk, networking and other service charges should not be treated as remaining compute that the discount must cover either.

Azure Hybrid Benefit is a separate layer. With qualifying rights, it may address the Windows or SQL licensing component in a supported scenario. But you must not deduct the licensing component from the reference price once and then report it again as an additional saving against the same baseline. We cover the Windows rules in Azure Hybrid Benefit: how many cores do you need?.

A working proposal should therefore show separate lines for compute, software, storage, networking, other services and unused commitment. This explains how compute can become cheaper while the overall bill fails to fall because disk usage or data transfers increased.

Check the outcome using amortised costs

Actual payments answer a different question from the economic cost of the consumed service. If you pay upfront for a commitment, internal cost allocation also needs its amortisation. Looking only at a VM's zero or reduced ongoing charge can hide the cost of a benefit already purchased.

Microsoft's chargeback guidance uses Amortized Cost to allocate costs to resources. It also identifies unused commitment in the data as ChargeType=UnusedSavingsPlan and PricingModel=SavingsPlan. Include that amount in the economic outcome rather than filtering it out as an unrelated line.

Use the same scope, period and cost basis throughout your comparison. Do not add the purchase payment in Actual Cost to all amortised amounts for the same period. Instead of saying Azure saved us X percent, identify the comparison baseline: which meter, which rate, which consumption and how much unused commitment.

Check change options before purchasing

A compute Savings Plan is not a monthly order that can be adjusted continuously. The current overview states that a purchased plan cannot be cancelled or refunded. Paying in monthly instalments does not turn a long commitment into a monthly cancellation option.

For reservations, distinguish exchanges, returns, instance size flexibility and trade-in for Savings Plan. They are not synonyms. The current trade-in rules also describe exchange changes from 1 February 2027 and the requirement that the new total commitment must be at least the remaining commitment of the reservation being traded in. Assess the specific rights by product and purchase date.

What an approval proposal should contain

1. A list of eligible resources and meters after unused resources have been removed and planned rightsizing applied.
2. Hourly data covering nights, weekends, seasonality and planned migrations; a monthly total is insufficient.
3. A model of existing reservations and plans, their scopes and end dates. Calculate a new purchase against residual consumption only.
4. A comparison using the same contractual rates, with software and other costs separated.
5. Conservative, expected and reduced-demand scenarios, each showing the actual cost including unused commitment.
6. An accountable owner, a review date and rules for infrastructure changes that could undermine the commitment.

This proposal supports choosing a reservation for the stable baseline, a smaller Savings Plan for a sufficiently predictable remainder, or retaining on-demand pricing for now. The decision follows verified operations rather than the discount displayed next to the Buy button.