Your AWS account rep, or Trusted Advisor, or a coworker who read a pricing blog, is telling you to buy an EC2 Savings Plan. The pitch is always the same shape: commit to a number, save up to 72%. What it skips is what happens if your usage doesn't match that number for the next one or three years — and that gap is exactly where teams end up paying more than on-demand for the privilege of a discount.
How do EC2 Savings Plans actually work?
A Savings Plan is not a discount on an instance type. It's a promise: you commit to a steady amount of spend, measured in dollars per hour, for a one- or three-year term. AWS bills your matching usage at the discounted rate up to that commitment; anything above it bills at the regular on-demand rate. The commitment itself is fixed — it doesn't shrink if your usage does.
AWS offers two flavors that apply to EC2 usage, and they trade flexibility for discount depth:
| Plan type | Max discount off On-Demand | What it covers | What you give up |
|---|---|---|---|
| Compute Savings Plans | up to 66% | EC2 (any family, size, region, OS, tenancy), plus Fargate and Lambda | A few points of discount versus the EC2-only plan |
| EC2 Instance Savings Plans | up to 72% | EC2 usage within one instance family in one region (any size, OS, or tenancy) | Locked to that family and region for the whole term |
These are AWS's published discount ceilings at the time of writing. Actual savings depend on term length, payment option (no upfront, partial upfront, all upfront), and instance family — check the Savings Plans pricing page and run AWS's own recommendation tool (below) before you sign anything.
Compute Savings Plans are the flexible option: move a workload from c5 to m5, shift a Region, or migrate a service from EC2 to Fargate mid-term, and the discount follows you. EC2 Instance Savings Plans pay more — up to 72% versus 66% — but only within the family and Region you picked at purchase; you can still change instance size or OS inside that family, just not the family itself.
Which one should I buy?
The honest answer is "whichever one matches how confident you are about the next one to three years," not "whichever number is bigger."
If your fleet is stable — the same instance family, in the same Region, for the life of the commitment — an EC2 Instance Savings Plan captures the extra six points of discount for free. If you're mid-migration, evaluating Graviton, expect to consolidate Regions, or might move a service onto Fargate, that flexibility is worth more than six percentage points, because a Compute Savings Plan keeps discounting your usage through all of those changes and an EC2 Instance plan does not follow you to a different family.
When does a Savings Plan actually pay off?
This is the question the sales pitch skips, and it has a clean answer once you do the algebra on what happens when you don't use the full commitment.
Say you commit to $H an hour. That $H covers a fixed amount of on-demand-equivalent usage — call it the plan's covered capacity — at the discounted rate. If your actual usage that hour is at or above the covered capacity, you pay $H for the covered portion plus on-demand for the overage, and you save money outright: the discount applies in full to everything the plan covers, no matter how close to the edge you are.
The risk is the other direction. If your actual usage falls under the covered capacity, you still owe the full $H — that's the commitment, not a cap — and the unused slice buys nothing. Work out the point where the fixed $H commitment costs exactly the same as paying on-demand for your real usage, and it falls out to a single number: you break even once your usage covers roughly (1 − discount) of what you committed to.
- Compute Savings Plans (up to 66% off): break-even around 34% utilization of the committed capacity.
- EC2 Instance Savings Plans (up to 72% off): break-even around 28% utilization of the committed capacity.
Below those lines, on-demand would have been cheaper for the exact same workload — you're paying for capacity you never touched, discount included. Above them, every additional point of utilization is money the plan is genuinely saving you, up to the full 66–72% once usage matches or exceeds the commitment.
Unused commitment in one hour does not carry into the next — there's no banking it for a slow week to spend on a busy one. And once purchased, a Savings Plan can't be cancelled, exchanged, or resold for the rest of the term (Reserved Instances have more flexibility here — see the limits of this estimate for how Parsivex frames that trade-off). Size the commitment against the trough of your usage, not the average, and you stay above the break-even line even in a quiet month.
How do I check whether my usage actually clears that line?
Don't estimate your break-even utilization by eye — AWS will compute it from your real usage history, and getting the real number is one call:
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS
The response includes AWS's suggested hourly commitment, the projected monthly saving, and — the field worth reading twice — the estimated utilization of that commitment. If AWS's own model puts your projected utilization anywhere near the 28–34% break-even band above, that's a signal to buy smaller, not to walk away: a commitment sized to your trough usage clears the line comfortably, while one sized to your average or your peak is the version that ends up underwater the first time a workload gets decommissioned.
The console shows the same recommendation under Billing and Cost Management → Savings Plans → Recommendations, alongside the equivalent Reserved Instance view if you want to compare the two commitment types side by side before choosing.
What should I fix before I buy anything?
A Savings Plan discounts the rate you pay for compute you run. It does nothing about compute you shouldn't be running at all — an idle m5.xlarge covered by a three-year commitment is still $0 of business value, just at a discounted price. Committing before cleanup locks the waste in at a rate you can't get out of for the length of the term.
Work through your EC2 fleet first:
# 30-day average CPU for a candidate instance
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-07-23T00:00:00Z --end-time 2026-08-22T00:00:00Z \
--period 86400 --statistics Average Maximum
Instances sitting under roughly 5% average CPU with negligible network traffic are idle — stop or terminate them before they factor into any commitment math at all. What's left after that cleanup is your real steady-state footprint, and it's the number a Savings Plan should be sized against.
What else should I check before I commit?
If part of the reason you're weighing a Savings Plan is that EC2's instance-hour meter feels wasteful for spiky or scheduled work, it's worth pricing the alternative before you lock in a multi-year rate on the current shape of your fleet — Fargate vs EC2: which is actually cheaper? breaks down when a per-second meter beats paying for reserved capacity, and a Compute Savings Plan discounts Fargate usage too, so the commitment isn't wasted if you do move a workload over.
And if the EC2 fleet in question is orchestrated by ECS or EKS, the control-plane fee sits entirely outside anything a Savings Plan touches — it's priced separately from the compute underneath it. ECS vs EKS: which costs less to operate? breaks down that standing fee on its own terms.
More broadly, a commitment only pays off against real usage, and idle EC2 is rarely the only thing worth cleaning up before you sign one — our tour of every other place an AWS bill leaks works through the rest of the account in order of savings per minute spent.
How do I find this — and keep it accurate — across my whole AWS account?
Checking utilization by hand against a single commitment is a few minutes. Keeping the picture current as instances get added, resized, and retired over a one- or three-year term is the part that never happens twice, and it's exactly where a commitment sized for last quarter's fleet turns into this quarter's waste. That's what a scan is for. Parsivex checks every region for EC2 (and RDS) usage stable enough to be worth committing against, and keeps watching afterward, so a fresh batch of idle or newly launched instances doesn't quietly get swept into the next commitment decision by mistake.
For what this finding means once it appears in your report, including how the estimate is modeled and its limits, see Reserved Instance opportunity.