Commitment coverage is the share of eligible usage that ran under a commitment discount in a period; its counterpart, utilisation, is the share of the purchased commitment that usage actually consumed. Only the pair is meaningful: low coverage means eligible usage pays the on-demand rate and discount is left on the table, while low utilisation means commitment that was paid for goes to waste. For the bill, the two numbers show whether a commitment is too small or too large, and both feed the effective savings rate.
How it works
Coverage divides covered by total eligible usage, utilisation divides used by purchased commitment. The measure is hours, normalised units or money at the on-demand equivalent, and the choice changes the result. The FinOps Foundation's Rate Optimization capability counts reporting coverage and vacancy as part of managing commitment discounts; where that capability sits is shown in the four FinOps domains and their capabilities.
AWS
Cost Explorer has an RI Utilization and an RI Coverage report for EC2, Redshift, RDS, OpenSearch Service and ElastiCache reservations, in hours or normalised units. Utilisation is the share of purchased RI hours that matching instances used; net savings are the saving against on-demand minus the cost of unused hours. Coverage is the share of instance hours that ran under a reservation, with the on-demand cost of the rest beside it. Both reports take a target, and AWS Budgets can alert when it is missed. For Savings Plans there is a utilisation report per plan (at a commitment of USD 10 per hour and USD 9.80 of usage at plan rates, 98% for that hour) and a coverage report on the share of eligible usage cost. The reports are covered in AWS Cost Explorer and AWS Budgets, the programmes in AWS Reserved Instances and AWS Savings Plans.
Azure
Under Reservations, the portal shows each reservation's last known utilisation percentage and its history; billing administrators see the same under Cost Management + Billing. For savings plans the list shows utilisation for the last day and the last seven days; the first data appear up to 48 hours after purchase. Reservation utilization alerts under Cost alerts report low utilisation by email. These pages name no coverage report; the Cost Management Power BI app for Enterprise Agreements contains the VM RI Coverage reports, and for other agreements coverage has to be built from the cost data. The programmes are described in Azure reservations and Azure savings plans.
Google Cloud
The CUD analysis report in the console has the tabs CUD Coverage and CUD Utilization, with cards for savings, coverage as a share of eligible spend and utilisation, and the effective discount in the summary table. Google points out that the report uses cost data only and does not distinguish usage from unused reservations, so it suits CUDs, not reservations. Across several CUD types it computes no utilisation, because the units differ. Hourly granularity reaches back 30 days and daily three years, the CSV download stops at 10,000 rows, and project roles are not enough: it takes Billing Account Administrator or Billing Account Viewer. The programme is described in Google Cloud committed use discounts.
What it means for your cost
Computing both measures from the billing data takes different fields per source:
| Source | Coverage from | Utilisation from | Unit |
|---|---|---|---|
| AWS Reserved Instances | line items with a reservation ARN against all eligible instance hours | reservation_unused_quantity, reservation_unused_normalized_unit_quantity | hours, normalised units |
| AWS Savings Plans | covered against eligible on-demand cost | savings_plan_used_commitment against savings_plan_total_commitment_to_date | USD |
| Azure reservations | usage with a ReservationId against eligible usage without | ChargeType = UnusedReservation in amortized cost | hours, money |
| Azure savings plans | PricingModel = SavingsPlan against eligible OnDemand | ChargeType = UnusedSavingsPlan in amortized cost | money |
| Google Cloud | cost with a CUD discount or CUD credit against eligible cost | in the new model FEE_UTILIZATION_OFFSET against the fee, otherwise the CUD Utilization tab | money, resources for resource-based CUDs |
| FOCUS | CommitmentDiscountStatus = Used against eligible rows | CommitmentDiscountStatus = Unused | Spend or Usage per CommitmentDiscountCategory |
The denominator of coverage is the hard half: not every row without a discount could have had one. FOCUS 1.4 adds the column CommitmentProgramEligibilityDetails for this, which marks eligible charges. AWS documents its FOCUS export as version 1.2 and Microsoft up to 1.2-preview, where Microsoft describes CommitmentDiscountStatus as currently empty; Google's FOCUS export provides no commitment columns and carries CUDs in x_Credits. Which columns are filled where is collected in FOCUS columns and the providers' mapping, the standard itself under FOCUS.
The two numbers lead to two different questions. High utilisation with low coverage points to a savings opportunity in the uncovered usage; low utilisation points to a commitment that is too large or in the wrong place, and leads to modification, exchange or expiry as described in exchange, cancellation and expiry. How much to buy and when is the subject of the chapter optimisation and savings.
Where it goes wrong
- A monthly average hides gaps. Symptom: the monthly report shows high utilisation, yet commitment is lost every night. Cause: Savings Plans and spend-based CUDs work per hour, and a daily or monthly average evens out hours above and below the commitment; see granularity.
- Shared scope moves the numbers. Symptom: utilisation in one account fluctuates while nothing changes there. Cause: with discount sharing at AWS, shared scope at Azure or CUD sharing at Google, the discount moves to matching usage in other accounts, subscriptions or projects.
- Hours against money. Symptom: two reports give different coverage for the same month. Cause: the RI reports count instance hours or normalised units, Savings Plans and the Google report count cost, and a large and a small instance weigh differently in each.
- Empty FOCUS columns. Symptom: the unused share is zero for Azure or Google. Cause: Microsoft leaves
CommitmentDiscountStatusempty in 1.2-preview, and Google provides no commitment columns at all. - Above 100% at Azure. Symptom: a savings plan shows more than 100% utilisation for recent hours, or the values still change. Cause: Azure reallocates usage arriving up to 48 hours after the hour.
Sources
Read on 2026-10-16. AWS Using the default Cost Explorer reports, Using the Savings Plans utilization report, Using the Savings Plans coverage report, Reservation columns, Savings Plans columns, FOCUS 1.2 with AWS columns conformance gaps; Microsoft View reservation utilization after purchase, View savings plan utilization after purchase, Reservation utilization alerts, EA and MCA reservation costs and usage, View savings plan cost and usage details, How a savings plan discount is applied, Cost Management Power BI app for EA, FOCUS cost and usage details file schema; Google Cloud Analyze the effectiveness of your CUDs, Structure of the FOCUS data export; FinOps Foundation Rate Optimization; FOCUS Column Library, Commitment Discount Status, Commitment Program Eligibility Details.