- RI Fundamentals: How Azure Reserved Instances Work
- Reserved Instances vs Azure Savings Plans: Decision Framework
- Discount Benchmarks by Service and Term
- Right-Sizing: The Most Expensive Mistake
- RI Utilisation Management
- MACC Integration: Using RIs to Optimise EA Terms
- Exchange and Cancellation Policies
RI Fundamentals: How Azure Reserved Instances Work
Azure Reserved Instances are 1-year or 3-year capacity commitments for specific Azure compute resources — virtual machines, SQL databases, Cosmos DB, App Service plans, and a growing range of PaaS services. The commitment structure is straightforward: you pay upfront (or monthly) for the reserved capacity, and Azure applies the reserved price automatically to eligible running resources, regardless of whether you explicitly manage the association.
The discount mechanism operates as a billing credit, not a provisioning reservation. You do not reserve specific VM instances; rather, Azure applies the RI discount to any running VM that matches the reserved VM series, size, and region (or flexible scope, if configured). This means an RI for a D4s_v5 in East US will automatically discount any D4s_v5 running in that scope — including VMs you create after the RI purchase.
This architecture has important commercial implications. First, RIs are separate from and additive to EA discounts — your standard EA discount applies to the on-demand VM rate, and the RI discount is calculated against the discounted EA price, not list price. An enterprise with a 15% EA compute discount purchasing 3-year RIs saves 15% through the EA and then a further 60% through the RI — compounding to an effective 66% total discount versus list price. Second, RIs are owned at the subscription or management group level, not the resource level — meaning RI management is an IT finance or FinOps function, not a workload team function. Enterprises that leave RI purchasing to individual workload teams consistently produce portfolios of conflicting, overlapping, or underutilised reservations.
Reserved Instances vs Azure Savings Plans: Decision Framework
Microsoft introduced Azure Savings Plans in 2022 as a more flexible alternative to Reserved Instances, and the choice between the two instruments is one of the most consequential cloud cost decisions an enterprise finance team makes annually.
| Dimension | Reserved Instances | Azure Savings Plans |
|---|---|---|
| Max discount (VM, 3-year) | Up to 72% vs PAYG | Up to 65% vs PAYG (compute Savings Plan) |
| Flexibility | VM series + region specific | Applies across compute services automatically |
| Commitment unit | Instance quantity | Hourly spend ($x/hour) |
| Scope | Single subscription or shared | Single subscription or shared |
| Services covered | VMs, SQL, Cosmos DB, App Service, etc. | VMs, AKS, Azure Functions, App Service |
| Exchange rights | Yes (within product family) | No |
| Best for | Stable workloads, specific VM series | Dynamic workloads, evolving architecture |
The optimal enterprise strategy is not either/or: use 3-year RIs for stable, predictable workloads where VM series and region are locked; use 1-year Savings Plans for dynamic workloads and emerging workloads where architecture may evolve. The layered approach consistently outperforms pure RI or pure Savings Plan strategies by 8–15% in realised savings.
Discount Benchmarks by Service and Term
The following discounts represent Microsoft's standard reservation discounts against pay-as-you-go pricing. EA discounts apply on top of these figures for most services.
| Service | 1-Year RI Discount | 3-Year RI Discount | Notes |
|---|---|---|---|
| Virtual Machines (General Purpose) | 40–45% | 60–72% | Varies by VM series |
| SQL Database (General Purpose) | 40% | 60–65% | vCore model only |
| SQL Managed Instance | 40–43% | 60–65% | vCore model only |
| Azure Cosmos DB | 40% | 60–65% | Provisioned throughput RUs |
| Azure App Service | 35–40% | 55–60% | Isolated v2 tier eligible |
| Azure Databricks | 40% | 60% | DBU commitments |
| Azure Synapse Analytics | 35% | 55–58% | DWU commitments |
| Azure Blob Storage | 18–22% | 30–38% | Capacity-based only |
Right-Sizing: The Most Expensive Mistake
The single most common and costly Azure RI error is committing to the wrong VM size. Enterprises that purchase RIs based on currently-running VM sizes without first conducting a right-sizing analysis routinely lock in 12–24 months of over-provisioned capacity that cannot be fully utilised or cost-effectively exchanged.
Azure Advisor provides right-sizing recommendations based on 7-day and 30-day CPU, memory, and network utilisation data. However, Azure Advisor's recommendations are optimised for cost reduction of on-demand resources and do not account for RI exchange complexity or the cost of workload migration required to implement sizing changes. Before purchasing any significant RI portfolio, conduct a structured right-sizing assessment that evaluates: peak utilisation versus average utilisation for each candidate workload; scheduled versus continuous operation patterns; VM series migration feasibility (e.g., can D4s_v3 workloads migrate to D4s_v5 before RI purchase to capture the newer series discount profile?); and planned workload changes within the RI term that would change compute requirements.
The optimal pre-RI sequence is: right-size running VMs first, migrate to target VM series, then purchase RIs against the right-sized, modernised fleet. Enterprises that purchase RIs against an unoptimised fleet pay reservation fees for capacity they would have eliminated in a subsequent right-sizing exercise — a costly sequencing error.
Flexible RI Scoping
Azure offers "instance size flexibility" for most VM series, allowing an RI for a given VM size to discount VMs of different sizes within the same VM series using a normalisation ratio. For example, a D4s_v5 reservation (16 virtual CPUs) can discount two D2s_v5 instances (8 vCPUs each) or half of a D8s_v5 (32 vCPUs). This flexibility significantly reduces the over-commitment risk for VM portfolios with variable sizing, but requires that all VMs sharing the RI pool are in the same VM series family. Understanding the normalisation ratios for your target VM series before purchase is essential for accurate RI portfolio sizing.
RI Utilisation Management
Azure Reserved Instances generate value only when they are applied to running workloads. Unused reservation capacity is 100% wasted — there is no partial credit for underutilisation. Enterprises with RI utilisation rates below 80% are paying more for their reserved capacity commitment than the actual savings generated, resulting in a negative ROI on the reservation investment.
RI utilisation data is available in the Azure Cost Management portal under Reservations > Utilisation. The key metric is "utilisation percentage" — the proportion of each reservation's capacity that was applied to running resources over a given time period. Establish a target utilisation threshold of 85% and review RI utilisation monthly, with quarterly decisions on exchange, cancellation, or supplementary purchase for under- and over-utilised reservations.
Common causes of low RI utilisation include: workload retirement after RI purchase; VM series migration that moves workloads outside the RI's eligible scope; regional migration; and over-sized RI purchases that exceed actual workload requirements. Each cause has a different remediation path — retirement and regional migration typically warrant cancellation (subject to the 12% early termination fee evaluation); VM series migration and over-sizing typically warrant exchange within the product family.
MACC Integration: Using RIs to Optimise EA Terms
The intersection of Azure Reserved Instance purchases and Microsoft Azure Consumption Commitment (MACC) is one of the least-understood but most commercially valuable aspects of Azure enterprise agreements. MACC commitments — committed Azure spend levels that trigger escalating discount tiers within the EA — can be significantly optimised by strategically timing and structuring RI purchases.
Most Azure RI purchases count toward MACC consumption, though the accounting treatment varies by service and purchase structure. Upfront RI payments count toward MACC as a single transaction in the purchase period; monthly RI payments count in each payment period. This creates a powerful lever for MACC management: enterprises approaching period-end MACC shortfalls can use RI purchases to satisfy committed spend requirements, converting potential MACC penalty exposure into genuine RI savings. Conversely, enterprises planning large RI purchases should coordinate timing with MACC period boundaries to maximise MACC tier progression.
Before any significant RI purchase, have your Microsoft account team confirm the MACC treatment in writing for your specific agreement. MACC treatment of RI purchases has changed with Microsoft agreement updates, and the treatment for newer service types (Savings Plans, certain PaaS reservations) is not uniformly MACC-eligible across all agreement structures.
Exchange and Cancellation Policies
Azure's RI exchange and cancellation policies provide meaningful flexibility, but with important constraints that must be understood before committing. Exchange rights allow you to exchange a reservation for a different reservation within the same product family (e.g., VM General Purpose for VM General Purpose; SQL Database for SQL Database) at any point during the term. The exchange is value-neutral: you receive credit for the unused portion of the current reservation and apply it toward a new reservation. Exchanges across product families (e.g., VM reservations for SQL reservations) are not permitted.
Cancellation rights allow early termination with a 12% early termination fee applied to the remaining reservation value. For a 3-year RI with 18 months remaining, the cancellation cost is 12% of the remaining value — typically a reasonable cost for workloads that have been retired or significantly restructured. The cancellation fee threshold of $50,000 per trailing 12 months applies: enterprises cancelling more than $50,000 of reservation value in a 12-month period must obtain Microsoft approval for the excess. This is rarely a practical constraint for individual workload cancellations but can become relevant for large-scale architecture changes.
For complete Azure enterprise strategy, access our Cloud Contract Framework and read Azure Enterprise Agreement Negotiation. Related: Microsoft EA Negotiation: The Complete Guide for 2026.