Azure offers two pre purchase commitment instruments against the same compute spend, and the account team rarely explains the tradeoff in buyer terms. The reserved instance returns the deepest discount, up to seventy two percent on a three year commit, but locks the discount to a specific VM family and region. The compute savings plan returns a smaller discount, up to roughly sixty five percent on the same three year term, but applies automatically across families, sizes, and regions as the estate moves. The right answer is almost never one or the other. It is a deliberate split that puts reserved instances on the stable core and the savings plan on everything that moves.
On identical three year commits against the same compute, the reserved instance returns a deeper discount than the compute savings plan. The gap varies by SKU but sits in the range of five to ten percentage points. That gap is the price Azure charges for the flexibility the savings plan provides. The question is not which discount is bigger. The question is how much flexibility each workload actually needs.
A commitment to a specific VM family, region, and term. Up to seventy two percent off pay as you go on three year, up to forty percent on one year. Instance size flexibility applies within the family, but the family and region are fixed at purchase.
A commitment to an hourly dollar amount of compute spend, not to a specific resource. The discount applies automatically to the highest cost eligible usage first, across families, sizes, regions, and even operating systems.
The savings plan versus RI decision is not made portfolio wide. It is made workload by workload against three questions. The answers sort each workload into the RI tranche or the savings plan tranche.
If the workload has run on the same VM family and region for twelve plus months and has clear retention rationale, the reserved instance captures the deeper discount with acceptable lock. If the family changes with refactoring or migration, the savings plan protects the commitment.
Workloads that shift region for latency, disaster recovery posture, or data residency strand a reserved instance the moment they move. The savings plan follows the workload across regions automatically and is the correct instrument for any estate with active region rotation.
If the workload is a candidate for container migration, serverless rewrite, or PaaS replacement inside the term, the savings plan covers the transition because it applies to the new compute shape. A reserved instance on a soon to be retired VM is shelfware in waiting.
The construction most estates land on after the rubric is applied is a layered one. The deepest predictable core takes reserved instances for maximum discount. The variable shell takes the savings plan for coverage without lock. The remaining elastic tranche stays on pay as you go and spot.
The most stable production tier. Database, identity, and primary application servers with proven family and region permanence. Three year reserved instances for the deepest available discount.
The moving middle. Workloads that resize, migrate, or rotate region but maintain a stable spend floor. The savings plan captures discount on the floor without committing to any single resource shape.
Test and dev, batch, seasonal, and project capacity. Pay as you go for full elasticity, spot VMs for interruptible batch. No commitment instrument applied. This is the band that keeps the cloud worth running.
The savings plan versus RI mix is an operational decision, but two contract protections keep both instruments working across the term and prevent Microsoft from quietly degrading either one.
Reserved instance and savings plan purchases both consume the multi year Azure consumption commitment. The contract should confirm the consumption credit for both instruments explicitly, so a future policy change cannot reclassify either as outside the commitment and leave the enterprise short on its MACC drawdown.
The reserved instance exchange right is the safety valve that lets the core follow the estate. Microsoft has tightened exchange policy unilaterally before. The contract preserves the exchange and refund policy as it exists at signing, so the reserved core does not become stranded by a mid term policy change the buyer never agreed to.
The three question rubric, the reserved core and savings plan shell split, the discount gap table by SKU class, and the two contract clauses that keep both instruments intact across the term. Sent on request.
A savings plan bought to cover a workload that should have been on a reserved instance leaves discount on the table for three years. A reserved instance bought on a workload about to be refactored becomes shelfware. The split belongs upstream of the purchase order, decided against consumption history rather than the account team default.