Are You Committing Too Much of Your Cloud Spend?

Is Higher Commitment Coverage Always Better?

A team reports 95% commitment coverage. That looks strong, but it does not show how much the organization is actually saving. Savings Plans, Reserved Instances, and Committed Use Discounts (CUDs) lower cloud rates in exchange for a spending commitment, so covering more usage also means committing more against future demand. For stable workloads, that trade is usually sound. For workloads facing migration, rightsizing, or shrinking demand, it can become costly. The practical question is not how close coverage can get to 100%, but how much usage can be committed with confidence.

Coverage, Utilization, and Effective Savings Rate

Coverage. Coverage is the share of eligible usage that receives a commitment discount, typically valued at its On-Demand equivalent. If eligible usage is worth $100 per hour at On-Demand rates and $80 of it is discounted by commitments, coverage is 80%.

Utilization. Utilization is the share of the purchased commitment that is actually consumed. It is unrelated to CPU or memory load. A team can show high coverage and still pay for commitment it does not fully use. AWS reports the two metrics separately, and its utilization report can be viewed at hourly, daily, or monthly granularity.

Effective Savings Rate (ESR). ESR expresses realized savings as a share of On-Demand-equivalent spend. The FinOps Foundation defines it as commitment savings, minus the cost of achieving them, divided by On-Demand-equivalent spend. It also describes a shorthand: utilization × coverage × discount.

The break-even point. Consider a unit that costs $10 per hour On-Demand and $7 per hour under a commitment, a 30% discount. The $7 is owed regardless of use, while the On-Demand value of what is consumed equals $10 multiplied by utilization. Break-even occurs where $10 × utilization = $7, so break-even utilization equals 1 minus the discount, or 70%. Below that level, the commitment costs more than buying the same consumption On-Demand. The model assumes a fixed commitment cost, uniform pricing, and no other charges or discounts, so real decisions require each provider’s billing rules.

How Much Usage to Commit

Start from retained demand. A baseline begins with historical hourly consumption rather than the largest available discount. Recurring usage, weekday and weekend patterns, and quiet periods all matter, because a monthly average hides the hours when demand drops below the commitment. Ineligible spend and existing commitments should be excluded, and planned migrations, rightsizing, or retirements should be reflected, since they change how much usage stays eligible. One practical method is to identify the recurring usage floor, then test any purchase above that floor against realistic demand declines. The FinOps Foundation’s purchasing guidance describes an iterative cycle of analysis and purchase, and notes that risk tolerance shapes how commitments are bought.

Native tools support this step. Since June 2026, the AWS Savings Plans Purchase Analyzer lets teams set a target coverage percentage and returns the hourly commitment needed to reach it. The analysis rests on historical usage, so it cannot anticipate planned changes.

Modeled example: 60%, 80%, and 95% coverage. Assume $100 per hour of eligible On-Demand-equivalent usage, a uniform 30% discount, commitments payable regardless of use, and no other fees or discounts. The three coverage levels are hypothetical purchasing choices, not recommendations from any provider or the FinOps Foundation.

At full demand, higher coverage produces higher savings. If demand falls to $60 per hour, the 60% commitment stays fully used and still saves $18, the 80% commitment saves only $4, and the 95% commitment costs $66.50 against usage worth $60, a loss of $6.50 per hour.Higher coverage increases savings when eligible demand remains stable. However, falling demand can leave commitments unused, reducing realized savings or even creating a net loss compared with On-Demand pricing.

FinOps Foundation practitioner material describes one approach that targets 85% to 90% coverage of existing usage through staggered one-year and three-year purchases. It is an example of a method, not a standard.

How AWS, Google Cloud, and Azure Differ

An 80% coverage level carries different risk on each platform, depending on what the commitment covers and how much flexibility remains when workloads change.

AWS. Compute Savings Plans offer up to 66% off across eligible EC2, Fargate, and Lambda usage. EC2 Instance Savings Plans offer up to 72% but apply to a specific instance family within a Region, so they depend more on retaining compatible workloads. SageMaker AI and Database Savings Plans also exist. Database Savings Plans, introduced in December 2025, offer up to 35% on eligible serverless usage and up to 20% on provisioned instances, with a one-year term.

Google Cloud. Resource-based CUDs apply to defined compute resources, while compute flexible CUDs are spend-based and cover eligible Compute Engine, GKE, and Cloud Run usage. Google Cloud’s updated spend-based model applied to existing commitments from January 21, 2026. Under it, discounts appear directly in per-SKU prices, and commitments are denominated in discounted spend rather than On-Demand-equivalent spend. Coverage figures from before and after the change therefore need consistent units for comparison.

Azure. Reservations offer up to 72% for matching resources, and savings plans for compute offer up to 65% across eligible compute services, with database savings plans also available. When both apply, reservations are applied first. Savings plan purchases cannot be canceled or refunded. From February 1, 2027, reservations bought on or after that date cannot be exchanged for services covered by savings plans. Earlier purchases keep one final exchange, and the cancellation policy is unchanged.

A safe coverage level therefore reflects the eligible workloads behind the commitment, not only the advertised discount.

A Framework for Setting a Coverage Target

Four questions structure the decision.

Will the demand persist? Confirm that the workloads behind the commitment are expected to run for the full term, accounting for approved migrations and retirements.

Will it stay eligible? Changes in service, instance family, Region, or billing scope can leave usage unable to consume the commitment even when total spend is stable.

What happens if consumption falls? Compare net savings under expected and downside demand, including unused commitment and any usage left at On-Demand rates.

How much flexibility is needed? Compare commitment types and terms. Staggering purchases and expirations limits exposure to forecast error, and FinOps Foundation guidance recommends purchasing several times a year.

After purchase, regular review of coverage, utilization, unused commitment, and upcoming expirations is advisable. Declining utilization is worth investigating before coverage is increased.

To Concluse Optimize for Net Savings, Not Maximum Coverage

There is no fixed correct coverage ratio. The appropriate level depends on how predictable the workloads are, which discounts they qualify for, and how much financial risk the organization accepts. Higher coverage raises savings only while enough eligible demand remains through the term. Comparing expected savings against realistic demand changes, and reviewing the flexibility of each option, helps keep commitments aligned with durable usage.

To compare commitment and pricing options across AWS, Google Cloud, and Azure before purchasing, explore the pricing tools available on the platform.