.png)
How It Works
Reservation coverage answers one question: of all the hours your compute or database resources ran, how many were protected by a commitment-based discount? Cloud providers calculate it by dividing discounted usage hours by total eligible hours in a given period. A coverage rate of 80% means one in five hours still ran at on-demand pricing. The remaining 20% is money left on the table.
Coverage is a distinct concept from utilization. Utilization measures how fully your existing commitments are being consumed. Coverage measures how much of your total workload those commitments actually protect. Both metrics matter, and optimizing one without the other leads to blind spots.
On AWS, coverage tracks how much eligible EC2, RDS, Fargate, and Lambda usage falls under Reserved Instances or Savings Plans. On Azure, the equivalent concept applies to Azure Reservations and Azure Savings Plans. On GCP, coverage reflects how much eligible Compute Engine, Cloud SQL, and other workload usage falls under Committed Use Discounts. All three providers expose coverage data in their billing and cost management consoles.
Why It Matters for Cloud Cost
Low reservation coverage is a direct cost leak. Every uncovered hour is billed at the full on-demand rate, which can be up to 72% higher than the discounted rate available through a commitment. For a company running $1M per month in eligible cloud compute, even a 20% coverage gap can represent hundreds of thousands of dollars per year in avoidable spend.
Coverage gaps typically accumulate in two ways. First, teams purchase commitments to cover their workloads at a point in time, but usage grows and new services launch without corresponding commitment purchases. Second, teams under-commit intentionally, fearing lock-in, and never close the gap. Both patterns produce the same outcome: a growing share of spend billed at the most expensive possible rate.
Key Characteristics
- Reservation coverage is calculated as discounted usage hours divided by total eligible usage hours, expressed as a percentage.
- A coverage rate below 70% typically signals a significant optimization opportunity in most cloud environments.
- Coverage is provider-agnostic in concept: AWS tracks it via Cost Explorer, Azure surfaces it in Azure Advisor and Cost Management, and GCP exposes it in the Billing Reports console.
- Improving coverage requires ongoing commitment management, not a one-time purchase, because eligible usage changes as workloads scale and shift.
How Usage AI Handles This
Usage AI’s Autopilot mode monitors your eligible usage daily across AWS, GCP, and Azure and adjusts commitment purchases to maintain high reservation coverage without manual intervention. CoPilot surfaces coverage gaps with projected savings so finance and engineering teams can review before any commitment is executed.
See how Usage AI saves 30 to 50% on AWS, GCP, and Azure.
Common Questions
1. How is reservation coverage different from commitment utilization?
Coverage measures what share of your total eligible usage is protected by a discount. Utilization measures how fully you are consuming the commitments you have already purchased. High utilization with low coverage means your commitments are well-used but too small for your actual workload.
2. What is a good reservation coverage target?
Most FinOps practitioners target 80% or higher for stable, predictable workloads. The right target depends on how consistent your usage is, because highly variable workloads carry more risk of underutilization if coverage is pushed too high without flexibility built in.
3. Does reservation coverage apply the same way across AWS, Azure, and GCP?
The concept is consistent across providers, but the mechanics differ. AWS measures coverage against Reserved Instances and Savings Plans separately. Azure tracks coverage for Reservations and Savings Plans across VM families and regions. GCP measures coverage through Committed Use Discount reports in the Billing console. Usage AI normalizes these into a single view across all three clouds.