- What you are actually buying
- Where the number comes from
- Deciding what to commit to
- Laddering instead of one large purchase
- What to watch afterwards
- Frequently asked questions
Every other cost finding asks you to change something: delete a volume, shrink a task, lower a floor. A Savings Plan asks you to change nothing at all and pay less for exactly the workload you already run. That makes it the highest-leverage line in most accounts, and also the one people put off longest, because it is the only one that involves a commitment.
What you are actually buying
A Savings Plan is not a reservation of capacity. You are not holding instances. You are committing to spend a certain number of dollars per hour on compute for one or three years, and in exchange AWS discounts everything up to that amount.
That distinction matters because it removes most of what people fear. You are not locked to an instance type, a size, a family, a region, or even a service. Change the instance, move the region, migrate to Fargate: the commitment follows the spend rather than the resource.
| Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instance | |
|---|---|---|---|
| Discount | Up to about 66% | Up to about 72% | Up to about 72% |
| Covers | EC2, Fargate, Lambda | EC2 only, one family, one region | EC2 and some managed services |
| Change instance family | Yes | No | Only within the same family |
| Change region | Yes | No | Regional RIs, within region |
| Resellable | No | No | Standard RIs, on the marketplace |
The deeper discount on the narrower products is the price of flexibility. A Compute Savings Plan gives up roughly six percentage points and in return stops being something you have to manage every time the architecture moves. For most teams that trade is worth making, because the alternative is a portfolio of commitments that quietly stop matching what is running.
Where the number comes from
This is the one finding InfraSync does not compute. AWS Cost Explorer already knows exactly what you spent at on-demand rates, hour by hour, and it produces the recommendation itself. Recomputing that from the outside would mean approximating data AWS holds exactly, and getting a worse answer.
The specific request made is deliberate on all four axes:
- Compute Savings Plan, not EC2 Instance. The flexible product, for the reason above.
- One year, not three. A three-year term discounts more and asks you to predict your architecture three years out. One year is the low-commitment default.
- No upfront. Partial and all-upfront payment discount further, at the cost of cash now. No-upfront is the version that does not require a finance conversation.
- Sixty-day lookback. Long enough to include a full billing cycle and month-end peaks, short enough that a recent architectural change is reflected rather than averaged away.
Cost Explorer is a global service, so this runs once per account rather than once per region, and the finding is marked account-wide rather than attached to any one region. A commitment does not belong to a region and reporting it as if it did would make it vanish under a region filter.
If the recommendation comes back with no meaningful saving, nothing is reported. An account with no steady baseline has nothing to commit to, and inventing a finding there would be recommending a commitment against usage that is not there.
Deciding what to commit to
The single number that matters is your steady-state floor: the compute spend that is present at three in the morning on a quiet Sunday. That is the part that is safe to commit, because it is running whether or not anything else happens.
Commit to the floor and you capture the discount on the predictable part while leaving the variable part on demand, where it can scale to zero without stranding a commitment. Commit above the floor and you pay for coverage you do not use during the troughs, which is the one way a Savings Plan actually loses money.
Cost Explorer's recommendation is sized from your recent usage rather than from that floor, so treat it as the starting point rather than the answer. Two adjustments are worth making before you buy.
Subtract anything you are about to remove. If the last two months included instances you have since deleted, or a migration that is about to reduce compute, the recommendation is sized on spend that will not recur. This is the most common way people over-commit: the recommendation looks at history, and history included the thing you just fixed.
Do the other findings first. Committing to a baseline that still contains an oversized Auto Scaling floor and a set of over-reserved tasks means locking in a discount on waste. Fix the waste, let usage settle for a few weeks, then size the commitment. This ordering is the single most valuable thing on this page.
A Savings Plan applied to an unoptimised account is a cheaper price for the wrong amount of compute. Rightsize first, commit second. The commitment is much harder to unwind than the rightsizing.
Laddering instead of one large purchase
A single large commitment made on one day expires on one day, which means a cliff: a moment where your entire discount lapses at once and you have to re-forecast under time pressure.
Buying smaller amounts at intervals avoids that. Several plans that begin and end at different times mean coverage steps down gradually rather than falling off, each renewal is sized against recent reality rather than a year-old forecast, and an over-commitment is bounded by the size of one tranche.
It also lets you start conservatively. Commit to a portion of the floor, watch the coverage and utilization reports for a month, and add more when the numbers confirm the shape. That is a much better first purchase than the full recommendation.
What to watch afterwards
Two reports in Cost Explorer, and they answer different questions.
Utilization is how much of what you committed to is being used. Below 100% means you are paying for commitment you did not consume. That is the number that tells you whether you over-committed, and it should sit at or very near 100%.
Coverage is how much of your eligible spend is covered by a commitment. Low coverage means there is more discount available. It is the number that tells you whether to buy more.
High utilization with low coverage is the healthy state to grow from: everything you committed to is being used, and there is room to commit further. Low utilization is the state to stop and reassess, because more commitment would make it worse.
How this finding sits alongside the rest, and why some findings deliberately carry no dollar figure at all, is in the AWS cost optimization guide.
Frequently asked questions
What is the difference between a Savings Plan and a Reserved Instance?
A Savings Plan commits you to a dollar amount of compute spend per hour, not to specific capacity, so you can change instance type, size, family, region and even service without losing the discount. A Reserved Instance is tied much more closely to what you reserved. Compute Savings Plans discount up to roughly 66 percent against about 72 percent for the narrower products, and that gap is the price of the flexibility.
Should I buy a one-year or three-year Savings Plan?
One year unless you have strong reasons otherwise. Three years discounts more and asks you to predict your architecture three years ahead. One year with no upfront payment is the low-commitment default, and it is the recommendation InfraSync requests from Cost Explorer for that reason.
How much should I commit to?
To your steady-state floor, meaning the compute spend present at three in the morning on a quiet Sunday. That part runs regardless, so it is safe to commit. Leave the variable part on demand where it can scale to zero. Committing above the floor means paying for coverage you do not use during troughs, which is the main way a Savings Plan loses money.
Should I rightsize before buying a Savings Plan?
Yes, and this is the most valuable ordering decision available. Committing to a baseline that still contains oversized Auto Scaling floors and over-reserved tasks locks in a discount on waste. Fix the waste, let usage settle for a few weeks, then size the commitment. The commitment is far harder to unwind than the rightsizing.
Why does Cost Explorer's recommendation sometimes over-estimate?
Because it is sized from recent history, and that history may include instances you have since deleted or a migration that is about to reduce compute. Subtract anything you are about to remove before you buy. This is the most common cause of over-commitment: the recommendation looks backwards, and backwards included the thing you just fixed.
Is it better to buy one large Savings Plan or several smaller ones?
Several smaller ones bought at intervals. A single large commitment expires on a single day, creating a cliff where the whole discount lapses at once under time pressure. Staggered plans step down gradually, each renewal is sized against recent reality rather than a year-old forecast, and any over-commitment is bounded by one tranche.
What do the utilization and coverage reports mean?
Utilization is how much of what you committed to is actually being used, and it should sit at or very near 100 percent; below that you are paying for commitment you did not consume. Coverage is how much of your eligible spend has a commitment against it, so low coverage means more discount is available. High utilization with low coverage is the healthy state to buy more from.