Comparing reserved vs spend commitments in uncertain demand

After resource optimisation, compare reserved and spend-based commitments by eligible usage, flexibility when demand changes, and the effect of unused commitment in a lower-demand case. Commit only to a dependable base; keep demand that cannot reliably absorb the commitment on pay-as-you-go rates.

Establish the dependable base

Measure eligible use over normal and busy cycles within each offer’s commitment window. Account for workloads due to end, change size or stop outside use hours, and include commitments already purchased.

Test lower, expected and higher demand cases. The lower case should reflect a plausible project ending or migration, while the higher case can include planned growth; treat both as forecasts until observed.

For each case, compare the purchase or commitment charge, matched eligible usage, uncovered usage and remaining storage, networking or software charges. Use current rates, region, currency, contract and billing scope; a headline discount applies only to matching usage.

Compare the matching rules

AWS: EC2 Reserved Instances and Savings Plans

An EC2 Reserved Instance (RI) is a billing discount for usage that matches its attributes, not a physical instance. A regional RI applies across Availability Zones in its region and allows instance-size flexibility within a family only for supported Amazon Linux/Unix RIs with default tenancy; it does not reserve capacity. A zonal RI reserves capacity but applies only in its specified Availability Zone, with no Availability Zone or instance-size flexibility.

AWS Convertible RIs can be exchanged for instance types during the term. The stated maximum discounts are up to 54% for Convertible RIs, compared with up to 72% for Standard RIs.

AWS Compute Savings Plans commit to consistent usage measured in USD per hour and offer discounts up to 66%. They apply across eligible EC2 instance families, sizes, regions, operating systems and tenancy, as well as eligible Fargate and Lambda use.

EC2 Instance Savings Plans offer discounts up to 72% but commit to an instance family in one region. They allow supported changes to instance size, operating system and tenancy within that scope, so they are less restrictive than a matching RI but narrower than a Compute Savings Plan.

When configurations or regions may change, a Compute Savings Plan has broader matching flexibility than an RI or EC2 Instance Savings Plan. A zonal RI is the more specific choice when both a matching workload and capacity in that Availability Zone are needed.

Azure: VM reservations and compute savings plans

A Reserved VM Instance discounts matching Azure VMs by reservation attributes and quantity, covering their infrastructure costs. Unused reserved hours do not carry forward: if no matching resource is found within the scope for an hour, that reservation quantity is lost for that hour. The discount can apply to another matching resource in scope; stopped VMs are billed and continue to use reservation hours.

Azure reservations do not cover storage or networking, which are charged at normal rates; additional software can also be charged separately. This makes a reservation a closer fit for a stable VM base that will keep matching, rather than demand likely to move beyond its resource and scope rules.

An Azure savings plan for compute commits a fixed dollar amount per hour for one or three years. It applies automatically to eligible usage across services and regions; unused hourly commitment expires, while eligible usage beyond the commitment is billed at pay-as-you-go rates. The compute plan does not cover software, networking or storage, and discounts vary by product and term.

Microsoft describes reservations as offering deeper discounts for specific resources, sizes and regions, while savings plans suit changing or dynamic workloads. If VM demand may shift, the spend-based plan has broader eligibility; if demand is stable and continues to match, a reservation may offer the deeper discount.

Google Cloud: committed use discounts

Google Cloud CUDs require a one- or three-year commitment to a minimum level of resources or spend. Resource-based CUDs cover specified Compute Engine resources; spend-based CUDs cover eligible services, with standard spend-based CUDs assessed against an hourly commitment.

Google Cloud also describes a flexible, cross-product spend-based option with a monthly entitlement window rather than the standard hourly window. Usage above the committed amount is charged at on-demand rates; the monthly window accommodates variable or spiky eligible usage, but the commitment still needs to match expected spend.

Choose between resource-based and spend-based CUDs according to whether eligible resource needs or eligible spend is more predictable. Resource-based CUDs suit a dependable resource base; spend-based CUDs can fit demand that moves across eligible services, subject to the offer’s matching rules and commitment window.

Matching Flexibility and Discount Range: AWS, Azure and Google Cloud Commitments

Key Commitment Metrics Across Cloud Providers

Decide with the downside visible

Prefer a resource-based commitment when the optimised demand floor is likely to keep matching its resource, size and scope. Prefer a spend-based commitment when eligible spend is dependable but the services or configurations may change; use pay-as-you-go for the portion that the lower case cannot absorb.

For each candidate, record its eligible base, excluded charges, term, commitment window, existing benefits and total cost in every demand case. Include any planned migration, shutdown or product change that could reduce eligible use, and identify who owns the forecast.

A purchase is a financial decision for the organisation that bears the lower-use obligation. Compare actual eligible usage and benefits with the forecast before considering another commitment.

When to Use Resource-Based vs Spend-Based Commitments