AWS Compute Savings Plans Guide (2026)

Updated: June 11, 2026

An AWS Compute Savings Plan is a flexible hourly-spend commitment (think "$10/hour for 1 year") that grants up to 66% off EC2, Fargate, and Lambda on-demand prices in exchange for that promise. Unlike Reserved Instances, the discount automatically follows your workload across instance families, sizes, AZs, regions, OS, and tenancy. So a c7g.large in us-east-1 and a m6i.xlarge in eu-west-2 both draw down the same commitment. The catch? Pick the wrong hourly number and you either overspend on-demand (low coverage) or pay for unused commitment hours (low utilization). This guide walks through the exact math, the dashboards I check weekly, and the layering strategy I use with Reserved Instances and Spot.

Compute Savings Plans give up to 66% off EC2, ~50% off Fargate, and ~17% off Lambda Duration in exchange for a 1- or 3-year hourly spend commitment.
Target 75–85% coverage and 95%+ utilization. Pushing either further creates the opposite problem.
EC2 Instance Savings Plans give a deeper ~72% discount but lock you to one instance family in one region. Treat them as a niche tool, not a default.
Compute SPs are non-cancelable and non-transferable, but commitments can be shared across accounts in an AWS Organization with consolidated billing.
Layer Spot for fault-tolerant workloads first, then cover the steady-state baseline with Compute SPs, then top up specialty workloads with RIs (RDS, ElastiCache, OpenSearch).
The Cost Explorer recommendation engine is decent but biased toward 3-year No Upfront. Always sanity-check against a 30-day on-demand floor before signing.

How Compute Savings Plans actually work

A Compute Savings Plan is a contractual commitment to spend a certain dollar amount of compute every hour for either 1 or 3 years. For each commitment hour, AWS first applies your discounted rate to whichever eligible usage runs that hour, and only bills on-demand for usage above the commitment. The mechanics are stricter than most people realize, so let me unpack them.

The commitment is per-hour, not per-month. If you commit to $10/hour for one year, AWS expects $10 of discounted usage every one of the 8,760 hours in that year. Run $20/hr during business hours and $0 overnight, and you'll show 100% utilization during the day and 0% at night, averaging out to roughly 50%. You paid for hours you didn't use, and you paid full on-demand for the spike above $10/hr. That's why a flat baseline workload is the textbook fit for a Savings Plan.

The discount is applied as a "discounted equivalent" rate. AWS publishes per-instance SP rates for every EC2 family, and your commitment dollars buy that many hours of discounted usage. A c7i.xlarge in us-east-1 is roughly $0.1734/hr on-demand and around $0.1093/hr under a 1-year No Upfront Compute SP, so $1 of commitment covers about 9.15 hours of that instance. The same $1 of commitment covers a different number of hours of a m7g.2xlarge, but AWS handles the conversion automatically. You commit in dollars, not instance-hours.

Compute vs EC2 Instance Savings Plans

AWS sells two SP flavors, and the difference shows up on every cost report. Compute Savings Plans (the focus of this guide) give a flat ~66% maximum discount on EC2 and apply across every instance family, every region, Linux/Windows, shared/dedicated tenancy, plus Fargate and Lambda. EC2 Instance Savings Plans go deeper, up to 72% off, but they lock you to a single instance family in a single region. Change from m5 to m7i and your EC2 Instance SP no longer covers the new workload at the deep rate; it falls back to the Compute SP rate (if you have one) or on-demand.

Honestly, I default to Compute Savings Plans for almost every fleet. The extra 6% on EC2 Instance SPs sounds attractive on a spreadsheet, but in three years of doing this I've watched four customers buy a 3-year m5 Instance SP and then migrate to Graviton (m7g) six months later. Their Graviton migration savings got partially eaten by stranded m5 commitment. A Compute SP would have followed them across the family change automatically.

The narrow case where I do recommend EC2 Instance SPs: a database fleet on r6i.metal that legitimately cannot move (memory-bound license constraints, a Windows workload that's pinned to the family forever), and only for the 1-year term. Three-year Instance SPs are a bet against AWS shipping a better SKU before your term ends, and AWS ships a better SKU every 12–18 months.

Savings Plans vs Reserved Instances

Reserved Instances predate Savings Plans by years, and AWS still sells them for EC2 even though Compute SPs are strictly more flexible. The reason? RIs remain the only commitment vehicle for RDS, ElastiCache, OpenSearch, Redshift, and DynamoDB. So in practice you'll run both: RIs for those services, Compute SPs for everything else.

Dimension	Compute Savings Plan	EC2 Instance Savings Plan	Standard RI	Convertible RI
Max discount vs on-demand	~66%	~72%	~72%	~66%
Commitment unit	$/hour	$/hour	Instance-hours	Instance-hours
Family flexibility	Yes (all)	No	No (size only)	Yes (exchange)
Region flexibility	Yes	No	No	No
OS / tenancy flexibility	Yes	Yes	No	Yes (exchange)
Covers Fargate	Yes	No	No	No
Covers Lambda Duration	Yes	No	No	No
Sellable on Marketplace	No	No	Yes	No
Terms available	1yr, 3yr	1yr, 3yr	1yr, 3yr	1yr, 3yr

The "sellable on Marketplace" row matters more than people think. Standard RIs that turn out to be wrong-sized can be listed on the Reserved Instance Marketplace and recouped at a discount. Savings Plans cannot be sold, transferred to another account outside your Organization, or cancelled. Treat the commitment like a non-refundable plane ticket.

How do I calculate my hourly commitment?

The mistake I see most often: people commit to their average hourly on-demand spend, then discover 30% utilization because their workload is spiky. The correct anchor is the floor, the minimum eligible compute spend you sustain in every hour of every week, including weekends, holidays, and the December lull.

Pull 30–90 days of hourly on-demand-equivalent spend from Cost Explorer (filter to EC2 + Fargate + Lambda usage type, group by hour), sort ascending, and look at the value at the 5th percentile. That's roughly your 24x7 baseline. Commit to about 85–90% of that number to leave headroom for the inevitable scale-down weeks. Here's the script I run on every onboarding.

# Pull hourly Compute SP-eligible spend for the last 60 days
# and calculate a defensible commitment floor.

aws ce get-cost-and-usage \
  --time-period Start=$(date -u -v-60d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
  --granularity HOURLY \
  --metrics UnblendedCost \
  --filter '{
    "Dimensions": {
      "Key": "USAGE_TYPE_GROUP",
      "Values": [
        "EC2: Running Hours",
        "Fargate - Pricing",
        "Lambda - Total Compute"
      ]
    }
  }' \
  --output json \
  | jq -r '.ResultsByTime[].Total.UnblendedCost.Amount' \
  | sort -g \
  | awk '
      { values[NR] = $1 }
      END {
        p05 = values[int(NR * 0.05)]
        p50 = values[int(NR * 0.50)]
        printf "5th percentile (commit floor):  $%.2f/hr\n", p05
        printf "Median hourly spend:            $%.2f/hr\n", p50
        printf "Suggested commitment (85%% of p05): $%.2f/hr\n", p05 * 0.85
      }'

Run AWS's own engine too: 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. Cross-check the two numbers. If AWS recommends $14/hr and your floor analysis says $11/hr, the truth is $11. AWS optimizes for utilization assuming you'll keep your current workload forever, which you won't.

What is a good Savings Plan coverage percentage?

Coverage = (eligible spend covered by SPs) ÷ (total eligible compute spend). Utilization = (commitment hours used) ÷ (commitment hours purchased). They pull in opposite directions, and the trade-off is the whole game.

Coverage below 70%: you're leaving discount dollars on the table by over-paying on-demand. Buy more.
Coverage 75–85%: the sweet spot for most steady-state fleets. The top 15–25% of usage stays on-demand to absorb scale-up bursts.
Coverage above 90%: dangerous. The moment you scale down (and you will, at some point), utilization collapses.
Utilization above 99.5%: you're under-committed. You're saturating the SP every single hour and paying on-demand for the overflow.
Utilization below 95%: you're over-committed. Some hours of the day you're paying for capacity you don't use.

I check both numbers in the Cost Explorer "Savings Plans" dashboard every Monday. When coverage drifts below 70%, I queue a small incremental commitment (1-year No Upfront, $1–$2/hr) instead of replacing the whole commitment. Stacking small 1-year SPs every quarter is a useful pattern, because your commitment naturally rolls with your workload instead of going through a painful three-year cliff.

All Upfront, Partial Upfront, or No Upfront?

Each Savings Plan has a term (1 or 3 years) and a payment option (All Upfront, Partial Upfront, No Upfront). The discount difference between the three payment options is small, usually 1–3 percentage points, but the cash impact is significant. A $10/hr 1-year Compute SP at All Upfront costs around $76k cash on day one; the same commitment at No Upfront is $0 on day one and roughly $87.6k metered out hourly.

My defaults:

1-year No Upfront for rolling commitment on top of an existing fleet. The ~1% discount you give up vs All Upfront is dwarfed by the cash flexibility, and you can recommit every quarter without forecasting a full year of cash.
3-year No Upfront for genuinely permanent workloads (the core data platform, the production EKS clusters). The deeper discount is worth the longer commitment when you're confident the workload outlives the term.
All Upfront only when finance specifically asks for it (e.g., to use a budget that's about to expire) or when the incremental discount clears your internal weighted average cost of capital.

The official AWS Savings Plans User Guide publishes the exact rate cards. I keep a spreadsheet that converts each payment option to an effective annual percentage rate so finance can compare against treasury yields. Sometimes leaving the cash in T-bills actually beats the All Upfront discount.

Do Savings Plans cover Lambda and Fargate?

Yes, but only Compute Savings Plans, and the discount rates are different from EC2. Compute SPs give roughly 17% off Lambda Duration (the $/GB-second component, not the per-request fee) and roughly 50% off Fargate vCPU and memory pricing. There's no SP discount for Lambda Provisioned Concurrency invocations or Fargate Spot. Those are already discounted vehicles.

One gotcha I hit on a recent migration: Lambda Duration coverage only kicks in for functions running in regions where you have eligible Compute SP capacity. If you commit $5/hr in us-east-1 and your Lambda fleet is split across three regions, your Lambda traffic in us-west-2 and eu-west-1 will still pull from that same commitment dollar pool (Compute SPs are region-flexible), but the rate conversion happens at each region's per-region Lambda price. The math is correct, just non-obvious. Confirm by checking the "Coverage by service" view in Cost Explorer.

If your fleet is Lambda-heavy and EC2-light, the SP economics shift. The 17% Lambda discount alone isn't usually enough to justify a 3-year commitment, but blended with Fargate at 50%, it often is. Run the numbers against your specific mix before signing.

By default, a Savings Plan purchased in any linked account is shared across the entire Organization for billing purposes. The payer account pools all eligible usage and applies SP discounts greedily, account by account, until the hourly commitment is consumed. This is great when your fleet is spread across dev, staging, and production accounts: a single SP in the management account covers everything.

It's also a trap if you charge departments back. If team A buys an SP and team B's workload greedily consumes the discount, team A pays for the SP but team B's bill drops. That's a chargeback dispute waiting to happen. Two fixes:

Disable SP sharing at the account level in Billing preferences. Each linked account then only applies SPs purchased within that account. Strict but predictable.
Centralize all SP purchasing in the management account and treat the discount as a corporate-wide benefit, allocated back through cost allocation tags. This is what I recommend for organizations of more than five accounts.

If you haven't already implemented tags consistently, our cloud cost tagging strategy guide walks through enforcing tags with Terraform and SCPs, which is a prerequisite to fair SP chargeback.

Layering Compute SPs with RIs and Spot

A mature cost strategy uses three commitment vehicles in concert. AWS applies discounts in a specific waterfall (Reserved Instances first, then Savings Plans, then on-demand), and getting the layering wrong leaves money on the floor.

The order I recommend customers build up coverage:

Move every fault-tolerant workload to Spot first. Spot is up to 90% off and doesn't require a commitment. Anything stateless, retry-safe, or batch-oriented goes here. See our Spot Instances guide for the patterns.
Right-size everything that remains. Use AWS Compute Optimizer recommendations. Committing to over-provisioned instances is the most expensive way to save money.
Cover the steady-state baseline with Compute SPs. This is the 75–85% coverage target above. Use 1-year terms unless you're certain about a 3-year horizon.
Top up specialty services with RIs. RDS, ElastiCache, OpenSearch, Redshift, and Aurora Reserved Instances cover what SPs can't.
Leave 10–20% on-demand for elasticity. Never aim for 100% coverage.

RDS RIs in particular are a common gap. Teams cover their EC2 fleet with SPs, forget RDS exists, and pay full on-demand for three years on a database that's clearly permanent. If your bill suddenly spiked and you don't know why, our AWS bill spike triage playbook walks through finding gaps like this.

My weekly Savings Plans review routine

Here's what I actually do every Monday morning, in order. The whole thing takes about 20 minutes once you've automated the queries.

Open Cost Explorer → Savings Plans → Coverage report. Filter to last 7 days. Confirm coverage is between 75% and 85%.
Switch to the Utilization report, same range. Confirm utilization is between 95% and 99.5%.
Check the upcoming expirations report. Anything expiring in the next 60 days gets a re-evaluation kicked off.
Pull this week's Compute Optimizer right-sizing recommendations. Estimate the SP coverage impact if all "high confidence" recommendations were applied.
Cross-reference against the AWS-generated SP purchase recommendation. If AWS suggests more commitment than my floor analysis, ignore it; if less, dig in to find out what changed.
Post the four numbers (coverage %, utilization %, on-demand baseline, recommended action) to the team Slack channel. Visibility is half the battle.

The single biggest mistake I see teams make? Buying a commitment and never looking at it again until renewal. SPs aren't fire-and-forget. The fleet shifts, Graviton migrations happen, products get sunset, traffic patterns evolve, and your commitment needs to evolve with them. A 20-minute Monday routine catches drift before it costs real money.

Frequently Asked Questions

Can you cancel a Savings Plan once purchased?

No. Savings Plans are non-cancelable, non-refundable, and non-transferable to a different AWS account outside your Organization. The only escape valve is consolidated billing, which lets the commitment apply against eligible usage anywhere in the Organization. Plan conservatively, because overcommitment is permanent.

What happens to my Savings Plan when it expires?

The commitment ends and all formerly-discounted usage flips to on-demand rates. AWS sends expiration notices 60, 30, and 7 days before, and you can configure auto-renewal in the Billing console. I prefer to disable auto-renewal and re-run the floor analysis instead, because workloads after a year rarely match the assumptions of the original commitment.

Do Savings Plans cover On-Demand Capacity Reservations?

On-Demand Capacity Reservations (ODCRs) and Savings Plans are independent. An SP discounts the rate of usage; an ODCR guarantees capacity. You can pair them (the ODCR holds the instance, the SP discounts the running cost), but neither implies the other. Unused ODCRs are still billed, and the SP will only discount that idle billing if eligible coverage capacity is available.

Should I buy a 1-year or 3-year Savings Plan?

Default to 1-year No Upfront unless you have a specific, durable baseline. The 3-year term adds roughly 15 percentage points of discount, but it locks you to an hourly commitment for 36 months — during which AWS will ship at least one or two faster, cheaper instance generations. Long terms only make sense for clearly permanent workloads.

Why is my Savings Plan utilization below 100%?

Either your workload is bursty (high during business hours, low overnight) and you overcommitted, or you recently right-sized a chunk of your fleet down. Check Cost Explorer's hourly utilization view. Flat-line dips overnight indicate the first cause, sudden step-changes mid-month indicate the second. The fix is the same either way: grow eligible workload back, or absorb the gap and aim lower on the next commitment.