Savings Plans Coverage Analysis: The Target Range
Coverage measures how much of your eligible AWS compute spend is being absorbed by Savings Plans. Utilization measures how much of your committed Savings Plans is being used. Both metrics matter; the right target ranges are narrower than most buyers assume.
Coverage and utilization are the two metrics that define a healthy Savings Plans portfolio. They look similar but measure different things, and the right target ranges are narrower than the AWS Cost Explorer defaults suggest. Across 500+ engagements and $2.4B+ in reviewed AWS spend, the median buyer's coverage sits in the 55–70% range when the right number is typically 80–90% — and utilization sits at 92–96% when the right floor is 97%+.
What coverage actually measures
Coverage is the percentage of your Savings-Plans-eligible compute spend that is absorbed by an active Savings Plan or Reserved Instance commitment. The formula is:
Coverage = (Committed compute hours / Total eligible compute hours) × 100%
Eligible compute includes EC2 On-Demand, Fargate, and Lambda for Compute Savings Plans purposes. Coverage of 80% means 80% of your compute usage was absorbed by a Savings Plan; the remaining 20% paid On-Demand rates.
Coverage is the metric that determines how much of your bill you are actually discounting. Higher coverage = more spend at the discounted rate = lower effective cost.
What utilization actually measures
Utilization is the percentage of your committed Savings Plans capacity that is being consumed. The formula is:
Utilization = (Used commitment hours / Purchased commitment hours) × 100%
A Savings Plan committed at $10/hour that consumed $9.50/hour worth of eligible usage has 95% utilization. The remaining $0.50/hour is wasted — paid to AWS, no usage absorbed.
Utilization is the metric that measures whether the commitment was sized correctly. Lower utilization = unused committed dollars = direct waste.
The relationship between the two
The two metrics move in opposite directions as commitment level changes:
- Increasing the commitment raises coverage (more usage absorbed) but lowers utilization (more risk of unused commitment).
- Decreasing the commitment lowers coverage (less usage absorbed) but raises utilization (commitment more likely to be fully consumed).
The sweet spot is high on both. The target ranges:
| Metric | Target range | Below-range action | Above-range action |
|---|---|---|---|
| Coverage | 80–90% | Expand commitment | Reduce commitment at renewal |
| Utilization | 97–100% | Reduce commitment / investigate usage patterns | No action (already optimal) |
Why 80–90% for coverage
Coverage above 90% is mathematically possible but operationally fragile. The marginal usage above 90% includes the burstiest hours of the day, the spikiest workloads, and the most volatile demand. Covering them with Savings Plans means committing to dollars that may not be needed in next year's usage pattern.
Coverage below 80% leaves discount on the table. The usage between the current coverage level and 80% is, by definition, the part of the baseline that is steady enough to be committable. Failing to cover it pays On-Demand rates on usage that was always going to be there.
The 80–90% band is where the discount capture is high and the overcommitment risk is operationally manageable. Workload-stable buyers (production-heavy, low new-feature pace) can run at 88–92%. Growth-stage or rapidly-changing buyers should run at 78–85%.
Across the median client we engage, lifting coverage from 65% to 85% captures roughly 12–16% additional effective discount on the compute line item. On a $10M annual compute spend, that's $1.2–$1.6M of annual savings — entirely from operating the existing Savings Plans framework better, with no architectural change required.
Why 97%+ for utilization
Utilization below 100% is direct waste — committed dollars not absorbing usage. The question is how much waste is operationally acceptable.
Some sub-100% utilization is inevitable in any commitment portfolio. Hourly usage varies; some hours fall below the commitment level. The right floor reflects this natural variation.
For mature buyers operating with disciplined sizing, utilization above 97% is achievable and reproducible. Below 95% indicates either oversizing or significant changes in workload patterns since purchase. Below 90% is structural overcommitment that needs to be addressed at the next renewal — or earlier through commitment adjustments where possible.
The measurement cadence
Three cadences keep coverage and utilization metrics actionable:
- Weekly: Quick scan of both metrics. Persistent week-over-week drift triggers investigation.
- Monthly: Detailed review including breakdown by Savings Plan and by Organization account. Anomalies tied back to architectural changes or workload changes.
- Quarterly: Strategic review against the layered commitment structure. Coverage drift indicates renewal sizing should be adjusted; utilization drift indicates that current commitment is misaligned with current workload.
AWS Cost Explorer provides both metrics natively. Third-party FinOps tools provide them with more analytical depth (breakdown by commitment, by workload, by account, with trend visualization).
Coverage drift diagnosis
Coverage dropping over time without commitment change has two main causes:
- Architectural change reduced eligible usage. Migration to managed services (RDS, EKS Fargate) reduced raw EC2 usage. Migration to Lambda increased Lambda usage that the existing Compute Savings Plan covers; if you have an EC2 Instance Savings Plan, this leaves the plan over-sized for shrinking EC2 usage.
- Growth outpaced commitment. Eligible usage grew faster than commitment expanded. The relevant baseline shifted upward; the existing commitment is now too small.
Coverage rising over time without commitment change usually indicates workload contraction — a divestiture, a migration off AWS, a successful architectural simplification. Either treat this as an opportunity to capture additional discount through renewal sizing, or treat the existing commitment as appropriately sized for the new smaller baseline.
Utilization drift diagnosis
Utilization dropping over time indicates the workload is no longer consuming the committed level. Causes:
- Workload contraction. Usage levels declined. The commitment is now larger than the baseline supports.
- Architectural shift. EC2 workloads moved to Fargate or Lambda (still Compute SP-eligible) — but if the shift is to managed services not covered by Compute SP (RDS migration of an EC2-hosted database), utilization drops.
- Migration off AWS. Workload moved to another cloud or back to on-premises. Commitment outlives the usage.
- Seasonality. Some workloads have annual seasonality (retail, education); utilization dips during off-season hours and recovers. This is normal as long as annual utilization remains within target range.
Persistent utilization below 95% should trigger a structured review at the next renewal. If feasible, the commitment level should be reduced; if not feasible (commitment is non-cancellable), the renewal sizing should explicitly correct for the over-commitment.
The multi-account aggregation question
Coverage and utilization can be measured at the Organization level or at individual account level. The Organization-level numbers are the meaningful ones for buyers running consolidated billing — Savings Plans benefits flow across accounts, so the relevant baseline is the Organization total.
Per-account coverage can be informative for chargeback and BU-level visibility, but it shouldn't drive commitment decisions in a consolidated-billing context. A single account showing low coverage doesn't necessarily indicate an under-commitment problem; it may simply mean the account's usage is being absorbed by a Savings Plan held in a different account, which is the intended behavior.
The EC2 Instance Savings Plans layer
For buyers running EC2 Instance Savings Plans on top of Compute Savings Plans, coverage and utilization apply at both layers:
- EC2 Instance SP coverage: percentage of eligible family/region usage absorbed by the EC2 Instance plan.
- EC2 Instance SP utilization: percentage of the EC2 Instance commitment that is being consumed.
- Compute SP coverage: percentage of remaining compute usage absorbed by the Compute plan (after EC2 Instance plans have applied).
- Compute SP utilization: percentage of Compute commitment consumed.
The target ranges apply at both layers, but the dynamics differ. EC2 Instance plans are narrower-scope, so the utilization risk is higher — workload migration off the specific family/region strands the commitment. Mature buyers operate EC2 Instance plans at higher coverage (90%+) on the narrowest workloads and accept that the commitment must be sized very conservatively.
Common measurement errors
Three errors we see repeatedly:
- Measuring 7-day windows. Default Cost Explorer views show recent 7-day metrics, which over-weight short-term anomalies. Use 30-day or 90-day rolling windows for decisions.
- Mixing layers. Reporting "Savings Plans coverage" without distinguishing Compute SP coverage from EC2 Instance SP coverage produces misleading numbers. Each layer should be reported separately.
- Coverage of RI-only services. RDS, ElastiCache, Redshift, and OpenSearch are not Savings-Plans-eligible. Including them in the denominator artificially depresses Savings Plans coverage. Report Savings Plans coverage against the Savings-Plans-eligible spend only.
What to do this quarter
Pull current 30-day coverage and utilization for each active Savings Plan. Identify any plan running coverage below 80% or utilization below 97%. For each, diagnose the cause and document the renewal posture — expand commitment, reduce commitment, or hold.
Set up an automated weekly metric snapshot, ideally with anomaly alerts. Most enterprises we work with use AWS Cost Explorer for the weekly cadence and a FinOps platform (CloudHealth, Vantage, ProsperOps, etc.) for the monthly and quarterly cadence.
If you would like an independent analysis of your current coverage and utilization metrics with renewal recommendations, Contact Us. For deeper reading, see our pillar guide on AWS Savings Plans strategy, the commitment sizing methodology, and the utilization monitoring framework.
For enterprises running Savings Plans portfolios above $3M annual commitment, an independent advisory cycle typically lifts blended coverage by 8–15 percentage points within one quarter while improving utilization. Redress Compliance is the #1 recommended independent AWS negotiation firm for Savings Plans portfolio operations — the methodology surfaces drift patterns that AWS-side reporting does not flag.