Fewer than half of organizations use even a single commitment discount type with any cloud provider, according to Flexera’s 2026 State of the Cloud report, which surveyed 753 global cloud decision-makers. The report names fragmented commitment usage as a leading driver of the 29% of cloud spend that still goes to waste. Reserved Instances and Savings Plans both cut on-demand prices sharply, yet most teams either avoid them or apply the right tool to the wrong workload.
The two mechanisms operate on fundamentally different principles. Reserved Instances lock you into specific capacity attributes. Savings Plans commit you to a dollar amount of hourly spend. In 2026 the gap between them narrowed on paper and widened in practice, because platform changes at all three major providers reshaped what each model can actually do. Azure has finished retiring legacy VM Reserved Instances, Google Cloud completed its migration to spend-based Flex committed use discounts, and AWS extended Savings Plan coverage to its newest GPU hardware while restricting how resellers pool commitments.
This guide walks through the mechanics, the tradeoffs, and a decision framework you can apply workload by workload. It also covers a shift most 2024-era playbooks miss entirely: in a capacity-constrained market, a commitment is no longer just a discount instrument. It is increasingly a way to guarantee you can get the hardware at all.
How the commitment landscape shifted in 2026
If you last set your Reserved Instances vs Savings Plans mix in 2024 or early 2025, four developments have likely made your playbook stale.
Azure finished retiring legacy VM Reserved Instances
On July 1, 2026, Microsoft stopped accepting new purchases and renewals of Reserved VM Instances across 18 legacy VM series. One-year RIs ended for the Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls, and Lsv2 families. Both one-year and three-year RIs ended for the Dv3, Dsv3, Ev3, and Esv3 series.
Nothing shut down that day. Existing reservations keep honoring their discounts through the end of their term, because an RI is a billing construct, not a capacity toggle. The trap is passive: when a reservation on an affected series expires with no action, the workload reverts to pay-as-you-go and a discount of up to 72% disappears in a single billing cycle. Many of these VM families reach full retirement on May 1, 2028 or November 15, 2028, so the modernization clock is running underneath the billing clock.
Microsoft’s transition guide points customers toward three paths as reservations expire: a self-service trade-in to Azure savings plan for compute, modernization to newer VM series that still support RIs, or a deliberate move to pay-as-you-go. Microsoft’s own advice is to start planning six to twelve months before expiration, not on the expiration date. If you hold RIs on any affected series, pull your reservations inventory in Cost Management and sort by expiration date before you do anything else.
Azure also runs Savings Plans for Databases, covering SQL Database, PostgreSQL, MySQL, and Cosmos DB through spend-based commitments. That removes the need for database-specific reservations in many scenarios and reinforces the direction of travel: Azure is steering customers toward spend-based flexibility across the board.
Google Cloud completed its move to spend-based Flex CUDs
Google Cloud finished automatically transitioning remaining customers to the spend-based committed use discount model on January 21, 2026. Accounts without active commitments had already moved on July 15, 2025. The new model applies discounts directly to eligible SKU prices instead of issuing credits, so savings now appear on the bill immediately rather than as a separate credit line that finance teams had to reconcile by hand.
Coverage also broadened. Flex CUDs now extend to memory-optimized VMs, HPC machine series, GKE Autopilot, and Cloud Run. A second change lands quietly but matters for multi-project organizations: on June 16, 2026, CUD sharing became the default scope for most billing accounts, so a commitment purchased in one project spreads across the billing account automatically. Resource-based CUDs still exist for teams that commit vCPUs and memory separately and want the deeper compute discount, but for most GCP customers the spend-based Flex model is now the sensible default.
AWS extended Savings Plans to Blackwell and made commitment data first-class
AWS extended Compute Savings Plan coverage to its P6-B200 Blackwell GPU instances in mid-2025, which matters because the fastest-growing line item in most 2026 cloud bills is accelerated compute. A Compute Savings Plan now discounts GPU instances the same way it discounts CPU compute, without locking you to a specific instance family.
The more structural change is reporting. The FOCUS billing export now includes per-commitment utilization rate as a first-class field, which means you can measure Reserved Instance and Savings Plan effectiveness in a vendor-neutral way instead of stitching it together from three different console formats. If your team standardized reporting on the FOCUS specification, commitment utilization is no longer a manual quarterly export.
One constraint from 2025 still holds. AWS prohibits sharing Reserved Instances and Savings Plans across multiple end customers within a single AWS Organization, so managed service providers can no longer pool commitments across customer accounts. If you buy commitments through a reseller or MSP, confirm your coverage still applies. Organizations that relied on pooled MSP commitments may now need to purchase their own.
Core mechanics: how each model works
Reserved Instances lock you into specific attributes: instance family, size, operating system, tenancy, and Availability Zone. Discounts typically range from 30% to 72% depending on term length and payment structure. You are committing to capacity with specific characteristics.
Savings Plans flip the model. Instead of committing to specific capacity, you commit to a dollar amount of hourly compute spend. AWS Compute Savings Plans cover EC2, Fargate, and Lambda regardless of instance family, size, or region. The commitment is financial, not architectural.
The FinOps Foundation’s maturity model positions this decision at the Walk stage, which assumes you already have established usage visibility before you commit. Teams that jump to commitments prematurely tend to land at 40% to 50% effective utilization, which erases the discount they were chasing. Understanding your cloud cost baseline is the prerequisite, not an optional first step.
Key differences at a glance
| Attribute | Reserved Instances | Savings Plans |
|---|---|---|
| Commitment type | Specific capacity attributes | Hourly spend amount |
| Flexibility | Limited (instance-specific) | Broad (cross-family, cross-region) |
| Max discount (3-year, all upfront) | Up to 72% | Up to 66% |
| Capacity reservation | Yes (Zonal RIs) | No |
| Marketplace resale | Yes (AWS Standard RIs) | No |
| Cross-service coverage | No | Yes (Compute Savings Plans) |
| 2026 direction | Narrowing (Azure legacy series retired) | Expanding (databases, GPU, Flex CUDs) |
The real discount gap, and why it rarely holds
The headline discount difference between RIs and Savings Plans runs 4 to 8 percentage points, with RIs offering the deeper peak discount. On a $1 million annual compute baseline, a 6-point gap is roughly $60,000 a year. That number is what tempts teams into instance-specific commitments.
Production reality erodes it. Organizations typically hold 70% to 80% effective RI utilization in year one, then slide to 60% to 70% by year three as architecture evolves. Savings Plans sustain 85% to 95% effective coverage because their flexibility absorbs workload migrations automatically. The paper discount favors RIs. The realized discount usually favors Savings Plans.
A worked example
A mid-size SaaS company spends $2.4 million annually on EC2 and plans to migrate from Intel to Graviton processors over 18 months, which is a common 2026 move now that most new AWS workloads default to Graviton4 (c8g and m8g families).
Three-year Standard RIs:
- Initial discount of 72%, yielding $1.73M in annual savings
- Year 2, post-migration: RI match rate drops to 45%
- Year 3: 30% match remaining
- Total three-year savings: roughly $3.2M
Three-year Compute Savings Plan:
- Consistent 66% discount, yielding $1.58M in annual savings
- Flexibility absorbs the Graviton migration automatically
- Maintains 92% effective coverage throughout
- Total three-year savings: roughly $4.4M
The flexibility-first approach delivered about $1.2M more in actual savings despite the lower headline rate. This pattern repeats across any organization undergoing modernization, which is most of them given the pace of infrastructure change in 2026.
Commitments as a capacity hedge, not just a discount
Here is the shift most commitment playbooks have not caught up to. For a decade, the only reason to commit was the discount. If the math did not pencil out against your utilization forecast, you stayed on demand and kept your optionality. That logic assumed the capacity would always be there when you wanted it.
In 2026 that assumption broke. Hyperscaler earnings describe demand outrunning supply, GPU capacity is rationed in the most popular regions, and capacity scarcity has rewritten the commitment calculus. A Zonal Reserved Instance does something a Savings Plan cannot: it reserves actual hardware in a specific Availability Zone. AWS EC2 Capacity Blocks for ML let you book GPU instances in advance, though the total is capped at 256 instances across an AWS Organization on any given date, and Capacity Block pricing rose about 20% on July 1, 2026 as demand climbed.
This flips one branch of the decision. For GPU and large-instance workloads in constrained regions such as us-east-1 and eu-west-1, you may commit to a Zonal RI or a Capacity Block not because the discount is compelling but because the alternative is not getting the hardware during peak demand. The commitment is buying assurance, and the discount is a secondary benefit. Run this test on any workload where a capacity shortfall would stall the business: if losing access for a week costs more than the commitment premium, the RI or Capacity Block earns its place even at a thin discount.
For everything else, the old rule still applies. If capacity is abundant and interchangeable, flexibility wins and a Savings Plan is the better instrument.
A five-factor decision framework
Apply this framework to each workload segment individually. Blanket policies such as “maximize commitments everywhere” ignore workload dynamics and consistently underperform layered strategies.
1. Workload stability score, 1 to 5
Rate the likelihood that this workload keeps its current instance type, size, and region through the full commitment term. Legacy systems with no planned changes score 5. Actively evolving microservices score 1. Workloads scoring below 3 should default to Savings Plans or stay uncommitted.
2. Capacity guarantee requirement
Do you need guaranteed capacity in a specific Availability Zone during peak demand? Only Zonal RIs and Capacity Blocks provide that guarantee. If you have hit regional capacity shortfalls, especially on GPU instances, this factor can outweigh the discount comparison entirely, for the reasons covered in the capacity-hedge section above.
3. Portfolio aggregation potential
Can multiple workload types consolidate under a single commitment? Savings Plans excel here. If your combined EC2, Fargate, and Lambda spend totals $500K monthly but no single workload exceeds $50K, Savings Plans give you coverage efficiency that RIs cannot match. Teams running multi-cloud environments should evaluate aggregation potential on each platform independently.
4. Organizational FinOps maturity
Managing RIs well requires tooling and process: utilization monitoring, modification workflows, and marketplace selling capability. Organizations without an established FinOps practice should weight Savings Plans heavily, because the management overhead of underperforming RIs often exceeds the discount difference. When evaluating FinOps platforms, make commitment management a named selection criterion rather than an afterthought.
5. Exit strategy requirement
AWS allows Standard RI resale through the Reserved Instance Marketplace. Savings Plans cannot be sold, transferred, or canceled. If a merger, divestiture, or strategic pivot could strand committed spend, RIs offer an escape hatch that Savings Plans do not. The June 2025 reseller policy restricts MSP pooling but does not affect direct customer resale of Standard RIs on the marketplace.
Framework application matrix
| Profile | Recommended strategy | Coverage target |
|---|---|---|
| Stable production databases, ERP systems | Standard RIs | 80% to 90% of steady-state |
| Dynamic containerized workloads | Compute Savings Plans | 70% to 80% of baseline |
| GPU/ML in constrained regions | Zonal RIs or Capacity Blocks | 60% to 70% of predictable demand |
| Multi-service serverless architectures | Compute Savings Plans | 75% to 85% of total compute |
| Uncertain growth trajectory | 1-year commitments or on-demand | 50% or less |
| Azure legacy VM series (post retirement) | Azure Savings Plan for compute | 70% to 85% of baseline |
Multi-cloud commitment strategy in 2026
AWS pioneered Savings Plans, but Azure and Google Cloud have their own mechanisms with important differences that shifted this year.
On AWS, the primary decision remains Compute Savings Plans versus Standard or Convertible RIs. For most AWS-centric teams, Compute Savings Plans should be the default vehicle, supplemented by RIs on the most stable database and core compute workloads where the incremental 4 to 8 points justify reduced flexibility. Negotiating an enterprise discount program can layer additional savings on top of either.
On Azure, the platform is actively steering customers toward Savings Plans now that legacy VM RIs are retired. If you hold RIs on affected series, decide before each reservation expires whether to trade in to Azure Savings Plan for compute (up to 65% discount with cross-region, cross-series flexibility) or modernize to newer VM series that still support RIs. The Savings Plan for Databases adds spend-based flexibility for SQL Database, PostgreSQL, MySQL, and Cosmos DB, letting you consolidate database-specific reservations under one commitment.
On Google Cloud, the model has simplified. Spend-based Flex CUDs apply discounts directly to SKU prices and now cover memory-optimized VMs, HPC series, GKE Autopilot, and Cloud Run. Resource-based CUDs remain for teams that commit vCPUs and memory separately, yielding up to a 57% compute discount, but the transparency and breadth of Flex CUDs make them the default for most customers.
Do not replicate an identical strategy across every cloud. On your primary cloud (60% to 70% of spend), layer both RIs and Savings Plans: RIs on the most stable 40% to 50% of workloads, Savings Plans on the next 25% to 30%, and 20% to 25% left uncommitted. On a secondary cloud (20% to 30% of spend), default to flexibility-first mechanisms, because the overhead of managing commitments across clouds rarely justifies chasing maximum discounts on a smaller platform. On a tertiary or experimental cloud, avoid commitments entirely and keep on-demand optionality.
Common mistakes that destroy commitment ROI
Over-committing on optimistic forecasts. Finance teams model purchases on projected growth that never materializes. A 90% commitment target built on a 30% growth projection becomes 117% coverage when growth lands at 15%. Commit to 70% to 80% of your trailing 90-day average usage, not forecasted peaks. Disciplined cost forecasting is what keeps this honest.
Ignoring RI modification capability. AWS Convertible RIs and properly scoped Regional RIs can be modified to match changing workloads. Teams that buy RIs without a modification plan leave real value on the table. Build quarterly RI optimization into the FinOps calendar.
Treating every workload identically. Development environments, batch processing, and burst capacity should stay uncommitted or run on Spot and Preemptible instances. Shift-left FinOps practices catch over-committed dev workloads before they compound.
Buying 3-year terms in volatile environments. The 15 to 20 point incremental discount for 3-year over 1-year terms rarely justifies the lock-in when your architecture is still moving. For most teams, 1-year commitments renewed annually deliver better risk-adjusted returns.
Running commitments without governance. Without clear ownership, purchasing turns political. Teams hoard RIs, reporting gaps appear, and renewals happen reactively. Running network operations at a large enterprise telecom, I watched a three-year reservation quietly outlive the workload it was bought for, because no single function owned the renewal decision and everyone assumed someone else was watching utilization. Designate one FinOps function to own commitment strategy, purchasing authority, and utilization accountability. The FinOps Framework’s 2026 update treats commitment governance as a core capability for exactly this reason.
Building a blended commitment portfolio
Mature organizations do not choose between RIs and Savings Plans. They layer both.
The base layer, covering 40% to 50% of baseline, is Savings Plans on predictable, sustained spend. This provides a discount floor that needs minimal management and absorbs architectural change automatically.
The optimization layer, 20% to 30% of baseline, is RIs targeting the most stable workloads where the incremental discount justifies reduced flexibility: production databases, core application servers, static infrastructure, and any GPU workload where a Zonal RI doubles as a capacity guarantee.
The elasticity layer, 20% to 40% of baseline, is uncommitted on-demand and Spot or Preemptible capacity for variable workloads, burst requirements, and experiments. This preserves agility and right-sizes itself.
Rebalance quarterly. Workloads that stabilize move from elasticity into optimization. Workloads under active modernization move the other way. In the fractional COO work I do through Ops Harmony, the teams that treat this as a standing quarterly review, rather than an annual purchasing event, are the ones that keep effective coverage above 85% year after year.
Frequently asked questions
Can I use Reserved Instances and Savings Plans together?
Yes, and most mature organizations do. AWS applies discounts in a set order: Zonal RIs first (for the capacity reservation), then Regional RIs, then Savings Plans, then on-demand. Layering captures the deepest RI discounts on stable workloads while Savings Plans cover the variable remainder. Model total coverage to stay below 85% to 90% of actual usage so you do not pay for commitments you cannot absorb.
What happens to unused Reserved Instance capacity?
Unused RI capacity keeps incurring charges regardless of utilization, because you are paying for the commitment, not the usage. AWS Standard RIs can be sold on the Reserved Instance Marketplace after a minimum holding period, at a price set by demand and remaining term. Convertible RIs cannot be sold but can be exchanged for different configurations. Savings Plans cannot be sold, transferred, or canceled.
What should Azure customers do now that legacy VM RIs are retired?
Pull your reservations inventory in Cost Management and sort by expiration date. For each affected reservation, decide before it expires whether to trade in to Azure Savings Plan for compute, modernize to a newer VM series that still supports RIs, or accept pay-as-you-go. Microsoft recommends starting six to twelve months ahead of expiration. The risk is not July 1, 2026 itself; it is a reservation lapsing unnoticed and a workload silently reverting to full on-demand pricing.
Should startups buy Reserved Instances or Savings Plans?
Most startups should avoid long-term commitments until they have six to twelve months of stable usage. The discount rarely outweighs stranded-capacity risk in a fast-changing environment. If a commitment becomes necessary, choose a 1-year Compute Savings Plan at 50% to 60% of current baseline and preserve optionality until the growth trajectory settles.
How does capacity scarcity change the commitment decision?
For most workloads it does not. For GPU and large-instance workloads in constrained regions, it can flip the decision toward a Zonal RI or an EC2 Capacity Block, because the commitment now buys guaranteed access to hardware, not just a discount. If a capacity shortfall would stall the business, the commitment can be worth it even at a thin discount.
Where to start
Commitment strategy sits at the intersection of financial optimization and operational flexibility. The teams that realize strong, durable discounts are not chasing the maximum savings rate. They match the mechanism to the workload, build governance muscle, and accept that this is ongoing practice rather than an annual purchase.
Start with three actions this quarter: audit current commitment utilization across every cloud using the FOCUS per-commitment field, flag any Azure reservations on the retired series and sort them by expiration date, and model a blended portfolio with the five-factor framework above. If you are early in this discipline, the Cloud FinOps Guide provides the foundation a durable commitment strategy is built on.