// Table of Contents
  1. Commitment Discounts: The Core Concept
  2. AWS: Reserved Instances vs Compute Savings Plans
  3. Azure: Reserved VM Instances vs Azure Savings Plans
  4. GCP: Committed Use Discounts
  5. Decision Framework: Which to Choose
  6. Commitment Portfolio Management
  7. Common Commitment Portfolio Mistakes
  8. Next Steps

Commitment-based cloud discounts — Reserved Instances, Savings Plans, and Committed Use Discounts — are the single most impactful technical lever for reducing enterprise cloud costs. On-demand pricing carries a 30–72% premium over equivalent committed pricing depending on the provider, service, and term. For an enterprise spending $20M annually on cloud compute, shifting to an optimised commitment portfolio can represent $6M–$12M in annual savings. Yet most enterprises either under-invest in commitments (accepting unnecessary on-demand charges) or over-invest (buying commitments that don't align with actual workloads). This guide is part of our enterprise cloud cost optimisation framework.

// The Commitment Portfolio Gap

FinOps Foundation research estimates that only 45% of enterprise cloud compute is covered by commitment-based pricing. The remaining 55% runs at on-demand rates — paying a 30–70% premium that is entirely avoidable. For a $30M annual cloud estate, that means $4.5M–$10M in preventable spend. The root cause is not lack of awareness — most FinOps practitioners know about commitments — but lack of a systematic process for building and managing the portfolio.

Commitment Discounts: The Core Concept

Commitment-based discounts are a straightforward commercial exchange: the enterprise commits to consuming a specified quantity of cloud resources (or spending a specified dollar amount) over a defined period (typically 1 or 3 years), and in return the hyperscaler provides a discounted rate versus on-demand pricing. The core trade-off is between flexibility and cost: on-demand pricing offers maximum flexibility (pay per second, stop at any time) at maximum cost; multi-year committed pricing offers minimum flexibility at minimum cost.

There are three fundamental dimensions along which commitment instruments differ across providers: the unit of commitment (resource-specific vs spend-level), the scope of applicability (specific instance type vs flexible portfolio), and the term options (1-year vs 3-year). Understanding how these dimensions work for each major hyperscaler is the prerequisite for building an effective commitment strategy.

AWS: Reserved Instances vs Compute Savings Plans

AWS offers two primary commitment discount mechanisms: Reserved Instances (RIs) and Savings Plans (SPs). These are not equivalent instruments — they have different structures, applicability scopes, and optimal use cases. Most enterprise AWS environments should use both in a complementary portfolio, not choose one over the other.

Free Guide

Microsoft EA Negotiation Tactics

How Fortune 500 buyers slash Microsoft EA costs — true-up traps, ELP rules, and renewal leverage.

Download Free Guide → Microsoft EA Negotiation Service

AWS Reserved Instances

Reserved Instances commit to a specific EC2 instance type in a specific AWS region for 1 or 3 years. In exchange, AWS provides a discount of up to 72% (3-year, all-upfront) versus the equivalent on-demand rate. RIs come in three payment options: All-Upfront (maximum discount), Partial-Upfront (moderate discount, partial payment at purchase), and No-Upfront (minimum discount, monthly payments, no capital requirement).

RIs apply at the instance level: a c5.2xlarge RI in us-east-1 will discount EC2 charges for c5.2xlarge instances in us-east-1. If the workload migrates to a different instance type or region, the RI becomes stranded — the enterprise pays for it but does not benefit from it. This inflexibility is the primary limitation of RIs.

AWS provides some flexibility through Convertible RIs, which allow exchange for a different instance type within the same or a higher price point during the commitment term. Convertible RIs carry a lower maximum discount (up to 54% vs 72% for Standard RIs) but significantly more flexibility, making them appropriate for workloads where the instance configuration may evolve.

AWS Compute Savings Plans

Savings Plans, introduced by AWS in 2019, commit to a minimum compute spend level in dollars per hour regardless of instance type, family, size, or region. Compute Savings Plans — the most flexible variant — provide up to 66% discount versus on-demand and apply to any EC2 usage, AWS Lambda, and AWS Fargate. EC2 Instance Savings Plans commit to a specific instance family in a region, providing up to 72% discount with more flexibility than Standard RIs but less than Compute Savings Plans.

Stay Ahead of Vendors

Get Negotiation Intel in Your Inbox

Monthly briefings on vendor pricing changes, audit trends, and contract tactics. Unsubscribe any time.

No spam. No vendor affiliations. Buyer-side only.

The key advantage of Compute Savings Plans over Reserved Instances is their portfolio-wide flexibility. As workloads migrate between instance types, scale up or down, or add new workloads, the Savings Plan continues to provide discounts across the entire compute portfolio. For environments with dynamic workloads or active infrastructure evolution, Compute Savings Plans provide materially better coverage than an RI portfolio that requires constant management.

Instrument Max Discount Flexibility Best For
Standard RI (3yr, all-upfront) 72% Very Low — specific instance/region Stable, long-lived workloads
Convertible RI (3yr) 54% Low — exchangeable Stable but evolving workloads
EC2 Instance Savings Plan (1yr) 72% Medium — instance family flexible Instance family stable, size flexible
Compute Savings Plan (1yr) 66% High — any EC2/Lambda/Fargate Dynamic or mixed compute portfolio
Compute Savings Plan (3yr) 66% High Stable baseline, any instance type

The AWS RI + Savings Plan Layered Portfolio

The optimal AWS commitment strategy for most large enterprises is a layered portfolio. Compute Savings Plans cover the broad baseline compute spend — typically targeting 65–75% of the stable EC2 baseline. EC2 Instance Savings Plans or Standard RIs cover specific high-stability, high-volume workloads (large database clusters, application server farms) where the maximum discount depth is warranted and the configuration is stable enough to justify the reduced flexibility. Spot Instances handle interruptible, fault-tolerant workloads at 60–90% discounts. Our AWS cost optimisation guide covers the full strategy.

Azure: Reserved VM Instances vs Azure Savings Plans

Microsoft Azure's commitment discount architecture mirrors AWS with Reserved VM Instances (equivalent to RIs) and Azure Savings Plans for Compute (equivalent to Compute Savings Plans). Azure also offers Azure Hybrid Benefit — a separate discount mechanism for enterprises with existing Windows Server and SQL Server licenses — which stacks on top of commitment discounts and is uniquely valuable for Microsoft-centric enterprises.

Azure Reserved VM Instances

Azure Reserved VM Instances commit to a specific VM SKU in a specific Azure region for 1 or 3 years, providing up to 72% discount versus pay-as-you-go pricing. Azure reservations offer an Instance Size Flexibility option (enabled by default for most VM families) that allows the reservation to apply across different VM sizes within the same family — a meaningful improvement in flexibility over AWS Standard RIs.

Azure Savings Plans for Compute

Azure Savings Plans for Compute — launched in 2022 — commit to a minimum per-hour spend on compute services (Virtual Machines, Azure Dedicated Hosts, Container Instances, Azure Functions, App Service) across all regions and VM families. Discounts reach up to 65% versus pay-as-you-go. Like AWS Compute Savings Plans, Azure Savings Plans provide superior flexibility for dynamic environments at the cost of slightly lower maximum discounts versus the most specific reservation type.

Azure Hybrid Benefit: The Microsoft-Specific Multiplier

Azure Hybrid Benefit deserves special attention for Microsoft-heavy enterprises. AHB allows enterprises to use existing Windows Server and SQL Server licenses (with Software Assurance) in Azure, eliminating the licence cost component of Azure VM pricing — typically a 40–56% reduction in VM costs depending on the SKU. AHB is stackable with Azure Reserved Instances and Azure Savings Plans, meaning the total discount versus base pay-as-you-go pricing can reach 85%+ for SQL Server VMs in certain configurations. Ensuring AHB is applied to all eligible workloads is one of the first checks in any Azure cost review. See our Azure cost management guide for the full AHB playbook.

Is Your Commitment Portfolio Optimised?

Our advisors analyse your cloud commitment portfolio and identify unutilised, stranded, or suboptimal commitments. Typical finding: 20–35% recoverable value in the existing portfolio alone.

GCP: Committed Use Discounts

Google Cloud Platform does not use the "Reserved Instance" or "Savings Plan" terminology, but its Committed Use Discount (CUD) programme serves the same function. GCP CUDs come in resource-based (committing to specific vCPU and memory in a region) and spend-based (committing to a minimum $/hour spend) variants. Resource-based CUDs provide up to 55% discount for 3-year terms; spend-based CUDs provide up to 46%.

GCP also offers Sustained Use Discounts (SUD) — an automatic 20–30% discount that applies to VMs that run for a significant portion of the billing month with no commitment required. Critically, CUDs and SUDs do not stack: you receive one or the other, not both. For stable workloads where 37–55% CUD discounts are available, the SUD is not the right choice. Our dedicated guide to GCP CUD vs SUD optimisation covers the full decision framework.

Decision Framework: Which to Choose

The fundamental decision framework for choosing between Reserved Instances (resource-specific) and Savings Plans (spend-level) — or their GCP equivalents — follows from a workload stability assessment. The decision factors are workload uptime consistency (does the resource run 24/7?), configuration stability (is the instance type or size likely to change?), portfolio homogeneity (is the estate concentrated in specific instance types?), and growth trajectory (is the estate growing, stable, or shrinking?).

For workloads with high uptime, stable configuration, and concentrated instance types (e.g., a large Oracle database cluster on consistent m5.4xlarge instances), Standard RIs or resource-based CUDs provide the maximum discount at acceptable risk. For workloads with high uptime but variable configuration, or for diverse compute portfolios with multiple instance families, Compute Savings Plans or spend-based CUDs provide the best balance of discount depth and flexibility.

The Right Coverage Ratio

A key question in commitment portfolio sizing is coverage ratio: what percentage of baseline compute should be covered by commitments? The standard FinOps guidance is to target 70–80% coverage of the stable baseline (the compute that runs reliably every month), leaving 20–30% uncovered to handle variability. Attempting 100% coverage of current compute creates stranded commitment risk if workloads decrease. Covering only 40–50% of stable compute leaves significant on-demand spend that could be discounted. The 70–80% target balances discount realisation with commitment risk.

Commitment Portfolio Management

Building the initial commitment portfolio is the first step; managing it over time is where most enterprises falter. Commitment portfolios decay in effectiveness as workloads evolve, instance types change, and new services come online. Without active portfolio management, utilisation rates fall — meaning the enterprise is paying for commitments that are not generating benefit.

Monthly Utilisation Monitoring

Every commitment portfolio should be monitored monthly for utilisation. AWS provides RI and Savings Plan utilisation metrics in Cost Explorer (target: >85% utilisation). Azure provides reservation utilisation in the Azure Cost Management portal. GCP provides CUD utilisation in the Billing Console. Any commitment instrument running below 80% utilisation requires investigation: is the workload still running? Has it migrated to a different instance type? Has the engineering team decomissioned the application?

Quarterly Portfolio Rebalancing

Quarterly rebalancing reviews the commitment portfolio against the current workload landscape and identifies adjustments needed. For AWS RIs, this includes identifying convertible RIs that should be exchanged for more appropriate instance types, RIs that are near expiry and should be renewed or let lapse, and new workloads that have reached stability and should be covered. For Savings Plans, the primary action is assessing whether the current $/hour commitment level still matches the baseline compute spend level.

The broader multi-cloud commitment strategy — including how to use commitment decisions as commercial leverage in hyperscaler negotiations — is covered in our multi-cloud cost optimisation guide. For EDP and MACC negotiation specifically, see our guide on negotiating cloud enterprise discount agreements.

Common Commitment Portfolio Mistakes

After reviewing cloud commitment portfolios across dozens of enterprise engagements, we consistently encounter the same errors. These mistakes are costly and correctable.

Mistake 1: Buying RIs for Dynamic Workloads

Standard RIs committed to specific instance types generate stranded commitments when engineering teams change instance sizes, migrate to different instance families, or decommission workloads. Enterprises with high infrastructure churn — frequent migrations, continuous re-architecture, active Kubernetes adoption — should heavily favour Savings Plans over RIs. The slightly lower maximum discount is worth the flexibility given their workload dynamics.

Mistake 2: Not Consolidating to the Payer Account

AWS RIs and Savings Plans purchased in individual member accounts only apply within those accounts. Purchasing commitments at the management (payer) account level with "share" enabled allows them to benefit any linked account in the consolidated billing family — dramatically improving utilisation. The same principle applies to Azure reservations (shared scope) and GCP CUDs (billing account sharing). Not enabling cross-account sharing is one of the most common and most easily correctable FinOps errors we see.

Mistake 3: Neglecting the Commitment Renewal Cycle

Commitments that are allowed to expire without renewal revert to on-demand pricing — often without the engineering or FinOps team noticing for weeks or months. Building an automated alert for commitments within 90 days of expiry ensures adequate time for renewal decisions, competitive evaluation (should this workload be migrated?), and commercial negotiation (can a better rate be achieved at renewal?).

Next Steps

The commitment discount framework — Reserved Instances, Savings Plans, and CUDs — sits at the intersection of technical FinOps and commercial negotiation. Getting the portfolio right requires systematic workload analysis, disciplined portfolio management, and integration with the hyperscaler commercial negotiation strategy.

For the full cloud cost optimisation framework covering all dimensions — commitment discounts, waste elimination, EDP/MACC negotiation, and FinOps governance — return to our enterprise cloud cost optimisation pillar guide. For eliminating the cloud waste that commitment discounts alone cannot solve, see our article on cloud waste reduction strategies. IT Negotiations provides independent advisory on cloud commitment portfolio optimisation and hyperscaler commercial negotiations — contact us for a no-obligation assessment.