Knowledge Center Monthly Newsletter - July 2025
Stay up to date with the latest from the Knowledge Center. See all new Knowledge Center articles published in the last month, and re:Post’s top contributors.
Optimizing with AWS Savings Plans: Demystifying Utilization and Coverage
This article details how to maximize cost savings with AWS Savings Plans (SPs) by understanding SP Utilization and SP Coverage. It defines SP Utilization as the percentage of your committed hourly dollar spend that is actually consumed, with a high percentage minimizing wasted commitment. SP Coverage is described as the percentage of your total eligible On-Demand equivalent compute spend benefiting from SP discounts, aiming for high coverage to reduce expensive On-Demand usage.
Optimizing with AWS Savings Plans: Demystifying Utilization and Coverage AWS Savings Plans (SPs) offer a flexible way to save money on your compute usage (EC2, Fargate, Lambda, SageMaker) by committing to a consistent dollar amount per hour. While similar to Reserved Instances (RIs) in their commitment nature, SPs provide broader flexibility. To ensure you're maximizing your Savings Plan benefits, understanding SP Utilization and SP Coverage is essential
What is SP Utilization?
SP Utilization measures how much of your committed hourly spend for your Savings Plan you are actually consuming. It tells you if you're getting full value from the dollar amount you committed to.
-
Goal: Ideally, 100% utilization.
-
Why: If your utilization is less than 100%, it means you've committed to a certain hourly spend, but your actual eligible compute usage (at discounted SP rates) didn't meet that commitment. You're paying for a portion of the commitment that isn't being used, leading to wasted spend.
-
Formula:
Example:
You purchase a 1-year Compute Savings Plan with a commitment of $5 per hour.
-
Scenario A: High Utilization
- In a given hour, your eligible EC2, Fargate, and Lambda usage, after applying the Savings Plan discounts, totals $4.90.
- Actual Usage Billed with SP Rates: $4.90
- Total SP Commitment: $5.00
- Utilization: ($4.90/$5.00)×100%=98%
- Explanation: Your utilization is 98%. This is excellent, as almost all of your committed hourly spend was applied to eligible usage, minimizing waste. You pay the full $5.00 for the hour, but nearly all of it provided a discount.
-
Scenario B: Low Utilization (Overcommitment)
- In a given hour, your eligible compute usage, after applying SP discounts, totals only $3.00.
- Actual Usage Billed with SP Rates: $3.00
- Total SP Commitment: $5.00
- Utilization: ($3.00/$5.00)×100%=60%
- Explanation: Your utilization is 60%. This indicates an overcommitment. You committed to spending $5.00/hour, but only $3.00 worth of discounted usage occurred. You still pay the full $5.00 for that hour, meaning $2.00 of your commitment for that hour was unused and effectively wasted.
What is SP Coverage?
SP Coverage measures what percentage of your total eligible On-Demand equivalent compute spend is covered by your Savings Plans. It tells you how much of your actual compute usage is benefiting from the discounted SP rates, versus running at full On-Demand prices.
-
Goal: Maximize coverage for your stable, predictable compute workloads.
-
Why: A low coverage percentage indicates that a significant portion of your eligible compute usage is running On-Demand, which means you're missing out on potential cost savings from your Savings Plan.
-
Formula:
Example:
Using the same $5 per hour Compute Savings Plan commitment:
In a given hour, your total eligible compute usage at On-Demand rates would have been $7.50.
-
Your $5.00 Savings Plan commitment successfully covered a portion of this usage. Let's say, based on the specific services and discounts applied, your $5 SP commitment effectively covered usage that would have cost $6.00 at On-Demand rates.
-
On-Demand Equivalent of Usage Covered by SPs: $6.00
-
Total On-Demand Equivalent Eligible Usage: $7.50
-
Coverage: ($6.00/$7.50)×100%=80%
-
Explanation: Your coverage is 80%. This means 80% of your eligible compute usage for that hour was covered by your Savings Plan discount. The remaining 20% (On-Demand equivalent of $1.50, or $7.50−$6.00) ran at full On-Demand rates. This indicates an under-commitment, where you could save more by increasing your Savings Plan commitment to cover this additional On-Demand usage.
Expanded Examples for SP Coverage:
-
Scenario A: High Coverage
- You have a $10 per hour Compute Savings Plan commitment.
- In a given hour, your total eligible compute usage at On-Demand rates is $10.50.
- Your $10.00 Savings Plan commitment successfully covers usage that would have cost $10.00 at On-Demand rates.
- On-Demand Equivalent of Usage Covered by SPs: $10.00
- Total On-Demand Equivalent Eligible Usage: $10.50
- Coverage: ($10.00/$10.50)×100%≈95.2%
- Explanation: Your coverage is very high. Almost all of your eligible compute usage is benefiting from the Savings Plan discount. Only a small, negligible portion ($0.50 equivalent) is running On-Demand. This demonstrates effective use of your Savings Plan.
-
Scenario B: Low Coverage
- You have a $10 per hour Compute Savings Plan commitment.
- In a given hour, your total eligible compute usage at On-Demand rates is $25.00.
- Your $10.00 Savings Plan commitment successfully covers usage that would have cost $12.00 at On-Demand rates (assuming a particular blend of instances and services is covered by the SP).
- On-Demand Equivalent of Usage Covered by SPs: $12.00
- Total On-Demand Equivalent Eligible Usage: $25.00
- Coverage: ($12.00/$25.00)×100%=48%
- Explanation: Your coverage is low. Less than half of your eligible compute usage is benefiting from the Savings Plan discount. A substantial amount of usage (On-Demand equivalent of $13.00) is running at the higher On-Demand rates. This signifies a significant under-commitment and a considerable opportunity to increase your Savings Plan commitment to achieve greater savings.
Important Note: Savings Plan Hourly Application and Aggregate Reporting
It's crucial to understand that AWS Savings Plans are applied on a strictly hourly basis, and any unused commitment from one hour does not roll over to compensate for usage in subsequent hours. This means if your eligible On-Demand equivalent usage for a particular hour is less than your committed hourly spend, the unused portion of that commitment for that specific hour is forfeited. Conversely, if your usage exceeds your commitment in a given hour, the excess will be charged at the standard On-Demand rates, even if you had "unused" commitment in a previous hour.
The formulas for SP Utilization and SP Coverage provided in this article (and within AWS Cost Explorer) represent the aggregate outcome of these granular hourly calculations over a selected period (e.g., daily, monthly). While these formulas accurately reflect the overall performance of your Savings Plans, it's important to note that they provide the most straightforward interpretation in an ideal situation where eligible services run with consistent usage from the start of the month to the end, without significant hourly interruptions (like instances being stopped or launched frequently mid-hour). When you see "Actual Usage Billed with SP Rates" or "Total On-Demand Equivalent Eligible Usage" in the reports, these are sums that inherently account for all the hour-by-hour applications, including instances where:
-
Usage was below commitment for an hour: This contributes to lower aggregate utilization for the period.
-
Usage exceeded commitment for an hour: This contributes to On-Demand spend in the aggregate coverage calculation.
-
Instances were stopped or launched mid-period: The Savings Plan benefits are only applied for the hours the eligible instances were running, correctly impacting the hourly and thus the aggregate calculations.
This hourly application underscores the importance of aligning your Savings Plan commitment as closely as possible to your lowest predictable hourly spend to maximize the benefit and avoid paying for idle commitment. The aggregate reports effectively summarize these detailed hourly behaviors.
Why Both Metrics Matter for Savings Plans
-
High Utilization (e.g., 98-100%): This is the ideal state. It means you are maximizing the value of your existing Savings Plan commitment, ensuring you're not paying for unused commitment. Your committed hourly spend is almost entirely offset by discounted eligible usage.
-
Low Utilization (e.g., < 80%): Indicates that you have committed to a higher hourly spend than your actual eligible compute usage is consuming. This results in wasted spending, as you are still paying for the full committed amount even though a portion of it is not being utilized. This often signifies an overcommitment to a Savings Plan and requires reviewing your commitment level.
-
High Coverage (e.g., 90%+): This is the desired state for your stable, predictable compute workloads. It means that a vast majority of your eligible compute usage is benefiting from the discounted Savings Plan rates, significantly reducing your overall On-Demand spend. Achieving high coverage ensures you are maximizing the cost-saving potential of your Savings Plans.
-
Low Coverage (e.g., < 80%): Implies that a substantial portion of your eligible compute usage is still running at the more expensive On-Demand rates, even though it could have been covered by a Savings Plan. This indicates an under-commitment, meaning you have an opportunity to purchase additional Savings Plans to bring more of your On-Demand usage under the discounted rates, leading to greater savings.
By actively monitoring both Utilization and Coverage reports in AWS Cost Explorer, you can continuously fine-tune your Savings Plans strategy to achieve significant and sustainable cost optimization.
For more detailed information on how to access and utilize Savings Plan reports, refer to the following official AWS user guide articles:
- Language
- English
Relevant content
- AWS OFFICIALUpdated 3 months ago
- Accepted Answerasked 2 years ago
- asked 3 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago