Azure Reserved Instances vs Savings Plans: Which Is Right for Your EA?

Why This Decision Matters More Than Most Cloud Teams Think

Enterprise Azure environments typically run 30–50% of eligible compute at pay-as-you-go rates. For a £5M annual Azure compute bill, that represents £1.5–2.5M in spend that could be discounted by 40–72% through commitment-based pricing. The difference between getting the commitment strategy right and getting it wrong routinely determines whether an organisation saves £600,000 or £1.5M annually — from the same underlying spend.

The choice between Reserved Instances and Azure Savings Plans is not a binary one, and the answer is not the same for every organisation or even every workload within an organisation. It depends on workload stability, VM family certainty, deployment flexibility requirements, budget cycle dynamics, and how the commitment interacts with the broader Azure cost optimisation strategy. This article provides the framework to make that determination systematically, not reactively.

The Mechanics: What You're Actually Buying

Both Reserved Instances and Savings Plans are commitment vehicles — you commit to consuming a defined amount of Azure compute for a 1- or 3-year term in exchange for a discounted rate. The fundamental difference is the specificity of the commitment and the corresponding discount depth.

Reserved Instances: Maximum Discount, Specific Commitment

A Reserved Instance is a commitment to a specific VM size (or VM family, with instance size flexibility enabled) in a specific region for a 1- or 3-year term. In exchange for that specificity, you receive the maximum available discount — up to 72% off pay-as-you-go on the most heavily discounted VM families over 3 years.

The commitment is applied automatically: when an Azure VM that matches the RI specification runs in a scope covered by the reservation, the RI discount applies instead of the pay-as-you-go rate. If no matching VM is running, the RI is wasted for that billing period — you pay for it regardless of utilisation.

Instance size flexibility is a critical configuration option that is enabled by default on most VM families (excluding those with specific hardware constraints). With instance size flexibility enabled, an RI for a Standard_D4s_v5 will also apply to Standard_D2s_v5, Standard_D8s_v5, and other sizes in the Dsv5 family, with the discount scaled proportionally by the normalisation factor. This significantly reduces the risk of RI waste when VM sizes change within a family.

Azure Savings Plans: Lower Discount, Maximum Flexibility

An Azure Savings Plan is a commitment to spend a defined hourly amount on Azure compute, across any VM family, size, or region globally. The commitment is expressed in dollars per hour — for example, $10/hour — and the discount applies to any eligible compute consumption up to that commitment level, with pay-as-you-go rates applied to any consumption above the committed level.

Savings Plans provide flexibility that RIs cannot match: no commitment to a specific VM family, no commitment to a specific region, and automatic application across any compute that falls within the plan scope. The trade-off is a lower maximum discount — typically 50–65% for Compute Savings Plans versus 60–72% for equivalent RIs.

There are two types of Savings Plans: Compute Savings Plans, which apply to VMs, Azure Container Instances, and Azure Dedicated Hosts across any region; and Machine Learning Compute Savings Plans, which apply specifically to Azure Machine Learning compute. Most enterprise optimisation decisions involve Compute Savings Plans.

Head-to-Head Comparison

The Decision Framework

The choice between RIs and Savings Plans comes down to four questions about the workloads and environment in scope. The answers determine which instrument delivers better value — and in most enterprise environments, the answer is a combination of both.

Question 1: How stable is the workload's compute requirement?

If a workload runs continuously at a predictable level — a production application, a database server, a core infrastructure component — it is a strong RI candidate. The reservation will be consumed predictably, waste will be minimal, and the maximum discount is justified by the certainty of consumption.

If compute requirements vary significantly — development environments, batch processing jobs, applications with variable traffic patterns — Savings Plans provide better value because the flexible commitment absorbs consumption across multiple workloads as individual workload levels fluctuate.

Question 2: How certain is the VM family?

Reserved Instances require commitment to a specific VM family (even with instance size flexibility, you are committed to that family's regional market). If the organisation is evaluating a workload migration to containers, PaaS, or a different VM architecture within the commitment period, locking to a specific VM family creates a risk that the RI becomes partially or wholly unconsumed.

Savings Plans eliminate this risk entirely. If the architecture evolves — say, a Standard_D series workload migrates to Azure Kubernetes Service running Standard_B or Standard_F instances — the Savings Plan continues to apply its discount to the new compute, with no exchange or cancellation required.

Question 3: What is the regional deployment strategy?

RIs are region-specific. A West Europe RI cannot cover East US compute. For organisations with stable, single-region deployments this is not a constraint. For organisations with multi-region deployments or workloads that may move regions (DR scenarios, data residency changes, regional expansion), Savings Plans' global coverage provides significant flexibility.

Question 4: What is the discount differential relative to the organisation's risk tolerance?

The discount gap between a 3-year RI and a 3-year Savings Plan for equivalent workloads is typically 7–12 percentage points. On a £10M compute bill, that gap represents £700,000–£1.2M annually — significant enough to warrant genuine analysis rather than a default preference for flexibility.

The question is whether the flexibility premium is justified by the actual likelihood and cost of the flexibility being needed. For stable, established workloads with known VM families and confirmed regional deployment, paying the flexibility premium of a Savings Plan is rarely justified. For workloads in active architectural evolution, it often is.

Reserved Instance Best Practices for Enterprise Deployments

Scope Selection: Always Prefer Shared Scope

The most common RI configuration error in enterprise environments is purchasing at subscription scope rather than shared scope. A subscription-scoped RI can only apply to VMs in that specific subscription. A shared-scope RI applies to any matching VM across all subscriptions in the EA enrolment — dramatically increasing the probability that the reservation is consumed and reducing waste.

There are legitimate reasons to use subscription scope — cost accountability requirements, specific chargeback models, or RBAC control scenarios — but these should be deliberate decisions, not defaults. The starting position should always be shared scope.

Instance Size Flexibility: Understand Its Limits

Instance size flexibility allows a reservation to apply to different VM sizes within the same family and generation, applying a normalisation factor to account for size differences. A reservation for a Standard_D8s_v5 (normalisation ratio 8) will cover two Standard_D4s_v5 VMs (normalisation ratio 4 each), or eight Standard_D1s_v5 VMs (normalisation ratio 1 each).

Instance size flexibility does not cross VM families. A Dsv5 reservation cannot cover a Dsv4 or Esv5 VM. It does not cross generations. It is not available for all VM families — specifically, VMs that use dedicated hardware may not have instance size flexibility enabled. Understanding these limits is critical for coverage modelling.

Exchange and Cancellation: Know the Rules Before You Commit

RIs are exchangeable — you can trade an unused or underperforming RI for a different RI of equal or greater value — subject to Microsoft's current exchange policy. The policy has tightened in recent years; what was once a straightforward self-service exchange now involves Microsoft approval for certain exchange scenarios.

Partial cancellation is available up to $50,000 per year per enrolment, with a 12% early termination fee on the cancelled amount. Full cancellation is no longer available. These limits mean that exchange and cancellation are not a substitute for rigorous upfront analysis — they are a last resort, not a risk management strategy.

Building the Portfolio-Level Commitment Strategy

An enterprise Azure environment is not a single workload — it is dozens or hundreds of workloads with different stability profiles, architectural trajectories, and regional footprints. The commitment strategy must be built at portfolio level, not workload by workload.

The recommended approach is a three-tier analysis. In the first tier, identify the stable core: workloads that have been running consistently for 12+ months, on known VM families, with no planned architectural changes in the next 36 months. These are candidates for 3-year shared-scope RIs with all-upfront payment for maximum discount.

In the second tier, identify the confident-but-shorter-horizon workloads: established workloads where the 36-month trajectory is less certain, either because architectural evolution is planned or because the business direction is not fully confirmed. These are candidates for 1-year RIs or 1-year Savings Plans, depending on VM family certainty.

In the third tier, identify the variable and evolving layer: workloads in active development, migration, or architectural change, plus the variable demand component of more stable workloads. A Compute Savings Plan commitment calibrated to provide a coverage floor across this tier — without over-committing to a specific commitment level — provides cost reduction without the rigidity of VM-specific reservations.

The quantification of each tier requires a minimum of 30 days of utilisation data from Azure Cost Management, ideally 90 days to capture weekly and monthly variation patterns. The analysis should model coverage at the subscription-portfolio level, not just at the individual subscription level, to correctly capture the value of shared-scope coverage.

How Commitment Strategy Interacts With the EA

RI and Savings Plan commitments sit within the broader Enterprise Agreement commercial framework. Their interaction with the EA has two dimensions that are frequently overlooked.

First, MACC commitments and RI/Savings Plan commitments are additive, not alternative. An organisation with a $10M annual MACC commitment and $5M in RI commitments has a total Azure commitment of $15M. Understanding the interaction between MACC drawdown and RI billing is important for financial planning — MACC credits apply to eligible Azure consumption, and RIs billed monthly draw against MACC credits.

Second, the existence of a large RI portfolio is itself a source of negotiating leverage at EA renewal. An organisation that has committed $20M in multi-year RIs is demonstrating a long-term Azure commitment that Microsoft values commercially. This commitment level, combined with a well-structured MACC, justifies a level of EA commercial negotiation that smaller or uncommitted Azure spenders cannot access. The full interaction between Azure commitment strategy and EA negotiation is covered in the MACC leverage guide and the EA negotiation service.

The third dimension — which most organisations miss entirely — is the interaction between on-premises Software Assurance and Azure Hybrid Benefit. RIs and Savings Plans reduce compute costs; AHUB eliminates the embedded licence cost in applicable VMs. The two levers are complementary, not substitutes. An organisation running AHUB on Windows Server VMs and RIs on those same VMs achieves both discounts simultaneously. The total cost reduction can reach 70–80% compared to pay-as-you-go Windows Server VMs without AHUB or reservations. See the AHUB guide for the full calculation methodology.