Savings Plans: coverage vs utilization (2026)

Coverage and utilization are different numbers that both look like "how well is my Savings Plan doing", and they move in opposite directions. Driving one to 100% guarantees you are wasting money on the other. Nobody tells you which one you are optimising.

What is Savings Plans utilization?

How much of what you committed to buy, you actually used. The utilization report documentation defines it as "the percentage of your Savings Plans commitment that you're using across your On-Demand usage", with a worked example that removes any ambiguity:

For example, if you have a $10/hour commitment, and your usage billed with Savings Plans rates totals to $9.80 for the hour, your utilization for that hour is 98 percent.

The API states the formula outright. In SavingsPlansUtilization, UtilizationPercentage is "The amount of UsedCommitment divided by the TotalCommitment for your Savings Plans", and UnusedCommitment is "The amount of your Savings Plans commitment that wasn't consumed from Savings Plans eligible usage in a specific period."

Unused commitment is money that left your account and bought nothing. It is the single clearest waste number in AWS billing, and unlike most waste it is unrecoverable: the hour has passed.

What is Savings Plans coverage?

The opposite direction. The coverage report documentation says it "shows what percentage of your applicable AWS usage costs are being covered by your Savings Plans during your selected time period."

Utilization asks: of my commitment, how much got used. Coverage asks: of my eligible usage, how much got discounted. Same relationship, opposite denominators.

Why can't you maximise both?

Because they are the two sides of one decision, and the boundary between them is the size of your commitment. Raise the commitment and coverage goes up while utilization goes down. Lower it and the reverse. The only way both are high is if your usage is genuinely flat, and usage is not flat.

Which plan type applies to which usage is set out in Savings Plans types and services eligible for Savings Plans benefits.

That last row is the one people misdiagnose. Both numbers being mediocre usually means a commitment aimed at the wrong thing: an EC2 Instance Savings Plan tied to a family you have since migrated off, or a plan in a Region where the workload no longer runs. Buying more makes both numbers worse.

The practical rule we use: commit to the floor, not the average. Utilization is unforgiving because unused commitment is never refunded, while the cost of low coverage is only the difference between On-Demand and the plan rate on the uncovered portion. Under-committing is the cheaper mistake.

How does AWS decide which usage gets the discount?

In a documented order, and knowing it explains most surprising coverage reports. From how Savings Plans apply to your usage:

1. "Savings Plans apply to your usage after the Amazon EC2 Reserved Instances (RI) are applied."
2. "EC2 Instance Savings Plans are applied before Compute Savings Plans because Compute Savings Plans have broader applicability."
3. "In a Consolidated Billing Family, Savings Plans are applied first to the owner account's usage, and then to other accounts' usage. This occurs only if you have sharing enabled."
4. "Your Savings Plans are applied to your highest savings percentage first. If there are multiple usages with equal savings percentages, Savings Plans are applied to the first usage with the lowest Savings Plans rate."
5. "Savings Plans continue to apply until there are no more remaining usages, or your commitment is exhausted. Any remaining usage is charged at the On-Demand rates."

Two consequences worth acting on. Step 3 means the account that owns the commitment gets covered first, so in an organisation the owner account will show high coverage and everyone else will absorb the shortfall. That is a chargeback problem, not a purchasing problem, and it is invisible unless you read coverage per account.

Step 4 means the discount goes where the saving is largest, not where you might prefer it. You cannot direct a Savings Plan at a particular team's workload, so any internal allocation model that assumes you can is fiction. What you can do is measure where it actually landed, using the effective-cost columns in the CUR.

How do you pull both numbers?

Two API calls, and they are worth running together on a schedule rather than looking at the console:

aws ce get-savings-plans-utilization \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --query 'SavingsPlansUtilizationsByTime[].{
      period:TimePeriod.Start,
      used:Utilization.UsedCommitment,
      unused:Utilization.UnusedCommitment,
      pct:Utilization.UtilizationPercentage}'

aws ce get-savings-plans-coverage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT

Group coverage by linked account. Because of the owner-account ordering above, the aggregate number tells you almost nothing about whether individual teams are paying On-Demand rates.

One caveat if you use Billing Conductor. Both report pages carry the same note: "When your account is in a billing group (standard or billing transfer), Savings Plans utilization reports show pro forma data." Pro forma is not what AWS charged you, so reconcile against the CUR rather than against the report in that case, keeping in mind the documented reasons those two disagree.

Should you alarm on these?

On utilization, yes, and AWS supports it directly: the monitoring documentation notes "You can also set budgets for your Savings Plans utilization, coverage, and costs."

A utilization budget is the right instrument because falling utilization means active waste starting now, and it has a clean threshold: anything under 100% is money gone. A coverage budget is weaker, because low coverage is a missed opportunity rather than a loss, and it moves whenever usage grows.

This is one of the few cases where a budget beats anomaly detection. The trade-offs between the two are set out in AWS Budgets vs Cost Anomaly Detection. And if you hold Capacity Reservations as well, note that commitment reaches unused reserved capacity only after covering real instance usage, so tight utilization and idle reservations are an expensive combination.