How Compute Savings Plans decide what they cover

Published October 17, 2026

A Compute Savings Plan does not attach to an instance. You commit to spending a fixed number of dollars per hour, at discounted rates, for one or three years. You pay that commitment every hour whether or not there is usage to absorb it, and an hour’s unused commitment cannot be carried into the next.

Each hour, AWS sorts all your eligible usage by discount percentage, highest first, and spends your commitment down that list until the dollars run out. Whatever is left is billed On-Demand. When your commitment is smaller than your eligible usage, the ranking decides which usage that is. The numbers below come from AWS’s own worked example, so you can check the arithmetic against the source.

The order discounts are applied

For each hour, AWS applies pricing in this sequence:

• Reserved Instances come first. EC2 Reserved Instances cover their matching instances before any Savings Plan looks at the hour. The plan only sees what is left.
• EC2 Instance Savings Plans come before Compute Savings Plans. An EC2 Instance plan covers one instance family in one region. Compute plans apply more broadly, so they go second.

With sharing enabled in a consolidated billing family, AWS applies plans first to the owner account’s usage, then to the other accounts’ usage. The ranking described below happens within that sequence, not across all accounts at once.

How usage is ranked

A usage line is one combination of instance type (or Fargate or Lambda resource), region, operating system and tenancy. For every eligible line, AWS compares the Savings Plans rate with the On-Demand rate. That gives a savings percentage per line. Then:

1. The plan covers the line with the highest savings percentage first.
2. If two lines tie, the one with the lowest Savings Plans rate goes first.
3. It keeps going until the usage or the commitment runs out.
4. Anything uncovered is billed at On-Demand rates.

The commitment is spent in plan-rate dollars. A line that costs $2.80 at the plan rate uses up $2.80 of commitment, even though it would have cost $4.00 On-Demand.

Ranking by percentage rather than by dollars saved makes sense from the commitment’s side. Each commitment dollar buys discount ÷ (1 − discount) dollars of savings:

Highest percentage first gives the most savings for a fixed commitment. A dollar spent on a 30% line saves $0.43. Spent on an 18% line it saves $0.22, however large the 18% line is.

The AWS example, line by line

AWS’s example hour contains four kinds of usage:

• 4 × r5.4xlarge, Linux, shared tenancy, us-east-1
• 1 × m5.24xlarge, Windows, dedicated tenancy, us-east-1
• 400 vCPU and 1,600 GB of Fargate, us-west-1
• 1 million Lambda requests at 512 MB for 3 seconds each, us-east-2 (1M × 0.5 GB × 3 s = 1.5M GB-seconds)

The rates are AWS’s illustrative numbers, not real prices. Sorted the way a Compute Savings Plan sorts them, the hour looks like this:

Fargate memory and Fargate vCPU tie at 25%. Memory has the lower plan rate ($0.003 per GB against $0.03 per vCPU), so it goes first.

The whole hour costs $47.125 at plan rates against $59.10 On-Demand, so no commitment can do more than that for this hour. Drag the slider to see where a smaller one runs out:

Three of the presets reproduce AWS’s scenarios, in order of increasing commitment:

• $2.00/hr (scenario 2). The commitment runs out partway through the r5 line. It covers about 2.9 of the 4 instances, and the other 1.1 units cost $1.14 On-Demand. All the other usage is On-Demand too, $55.10. On-Demand charges total $56.24, plus the $2.00 commitment: $58.24 for the hour, saving $0.86.
• $19.60/hr (scenario 3). The commitment ends exactly at the end of rank 3. The r5 instances and all the Fargate usage are covered. The Windows instance and Lambda stay On-Demand at $32.70, plus the $19.60 commitment: $52.30, saving $6.80.
• $50.00/hr (scenario 1). More than the usage can absorb. Everything is covered, but $2.875 of the commitment has nothing to apply to and is still paid. $50.00, saving $9.10, where a $47.125 commitment would have saved $11.975.

Spilling is not a failure

Usage at the bottom of the ranking is where a commitment dollar saves the least. In this hour, the first $27.80 of commitment (ranks 1 to 4) saves $8.60. The next $19.325, which takes in Lambda duration and requests, saves $3.375. Covering everything also exposes you to unused commitment whenever usage dips. A commitment that leaves the bottom of the list On-Demand is often the right size.

Reserved Instances and EC2 Instance plans in the same hour

AWS’s other two scenarios add more discounts to the same hour.

In scenario 5, the $3.00 EC2 Instance plan is $0.60 larger than the r5 usage it can absorb, and nothing else in the hour is eligible for that $0.60. The hour totals $52.50, against $52.30 in scenario 3, where a single $19.60 Compute plan covers the same usage. Had the EC2 Instance plan been $2.40, the total would be $51.90. A narrow plan gives a better discount, but it cannot absorb a shortfall elsewhere.

How a higher discount changes what gets covered

Put the ranking and the fixed commitment together: when your commitment is smaller than your eligible usage, the lines with the lowest discount percentages spill to On-Demand. At a $19.60 commitment in AWS’s example, the 30% instance is covered and the 18% Windows instance is not.

The percentage is a property of the usage line. AWS sets a Savings Plans rate for each combination of family, region, operating system and tenancy, so the percentage differs per combination. In AWS’s example, the Windows, dedicated-tenancy m5.24xlarge gets 18% against 30% for the Linux r5.4xlarge. Windows discounts are generally lower because the license portion of the price is not reduced by a Compute Savings Plan. (For the size of that license charge, see the Windows licensing premium guide.) Check the plan rates for your own families before assuming a percentage.

Here is a hypothetical with invented percentages. A team runs three workloads in one hour with a $5.00/hr Compute plan:

The batch workers sit in the middle of the list and get 47% of their usage covered. The team moves them to a newer instance type whose plan discount is 35% instead of 20%:

Batch moves to rank 1 and is fully covered. The bill drops from $13.13 to $12.57, about 4%, because the same $5.00 now goes to higher-discount usage. The API fleet falls from fully covered to 69% covered: with a fixed commitment, one workload’s gain is another’s loss. If the commitment exceeds your eligible usage, ranking changes nothing, because everything is covered anyway.

This example holds the On-Demand price at $4.00 for both instance types to isolate the ranking effect. A real swap also changes the On-Demand price, and a 35% discount on an expensive instance can cost more than 20% off a cheaper one. Judge a move by the plan rate for the work you need done. The higher percentage matters for where the usage lands in the ranking.

Checks before you buy or migrate

• Measure your floor in plan-rate dollars. A commitment at or below your lowest hourly eligible usage, measured at plan rates after RIs and EC2 Instance plans take their share, is always fully absorbed. Each dollar above that floor pays off only in the hours when usage reaches it.
• Read both Cost Explorer reports. Savings Plans utilization shows how much of the commitment found usage to cover. Savings Plans coverage shows how much eligible usage the plans paid for. Low utilization means over-commitment. Low coverage with high utilization means you are in the shortfall case where ranking decides. Both reports average over the period you pick, and ranking happens hourly, so a month at 95% utilization can hide hours at 60%.
• Look at the lowest-percentage lines when coverage is low. Those are the ones spilling. Windows and dedicated-tenancy usage, and older instance generations, are likely candidates, but the percentages come from your own plan rates.
• Re-check utilization after migrating to cheaper instances. Any move to cheaper instances, including Graviton or rightsizing, lowers the plan-rate dollars the same workload absorbs. A commitment sized for the old fleet can end up partly unused. Compare instance types side by side before you move.
• Know what is eligible. Compute plans cover EC2, Fargate and Lambda. See AWS’s Savings Plans documentation for what falls outside them.