AWS Savings Plans vs Reserved Instances: Which Saves More in 2026
The biggest bill shock teams get on AWS isn’t from accidental services left running or an exposed S3 bucket. It’s from paying On-Demand rates for workloads that run 24/7. A t3.large runs $0.0832/hour On-Demand in us-east-1. At 8,760 hours a year, that’s $729. Buy a 3-year Compute Savings Plan on No-Upfront terms and you’re at $0.0306/hour — $268 a year. Same instance, same region, two-thirds less cost.
AWS has two mechanisms for getting those discounts: Savings Plans and Reserved Instances. They’re not interchangeable. The wrong choice costs you either money or flexibility, sometimes both. This guide covers how each works, where the discount numbers actually come from, and which one to reach for in which situation.
What You’re Committing To (and What You’re Not)
The core conceptual difference is what the commitment covers.
Reserved Instances are a capacity commitment. You pick an instance type, size, region, operating system, and tenancy — and you pay for that specific configuration for 1 or 3 years. AWS gives you a discount because you’ve told it exactly what you’ll use. If you commit to an m5.xlarge in us-east-1 running Linux, your RI discount applies only when you’re running that exact configuration. Spin up an m5.2xlarge instead, and your RI sits unused while you pay On-Demand for the new instance. The discount is precise because the commitment is precise.
Savings Plans are a spend commitment. You promise to spend a certain number of dollars per hour — say, $1.00/hour — on eligible compute for 1 or 3 years. AWS applies the Savings Plan discount to your compute usage automatically, covering whatever you’re actually running. You still pay the remaining usage at On-Demand rates above your committed spend. No instance type specified. No region locked. Just a dollar amount per hour.
This distinction matters more than any comparison table. If your infrastructure doesn’t change, Reserved Instances give you the deepest discounts. If you change instance types regularly, resize constantly, or haven’t fully stabilized your compute footprint, Savings Plans give you flexibility without wasting the commitment.
Three Types of Savings Plans
AWS offers three Savings Plan types, and they don’t cover the same services.
Compute Savings Plans provide up to 66% off On-Demand pricing and cover the broadest set of services: EC2 instances in any region, any instance family, any operating system, any tenancy — plus AWS Fargate and Lambda. If you commit $1.00/hour and you’re running an m5.large today and a c6i.xlarge next month, both get the discount automatically. For teams running mixed compute or actively right-sizing, this is the most practical option.
EC2 Instance Savings Plans go deeper on discount — up to 72% — but require you to commit to a specific instance family within a single region. You commit to M5 instances in us-east-1, for example. Within that commitment, you can change instance sizes (m5.large to m5.2xlarge), operating systems, and tenancy. You cannot change instance family or region. The 6-7% discount premium over Compute Savings Plans is the trade-off for locking that family and region in.
SageMaker Savings Plans cover SageMaker ML instances specifically — training, inference, Studio Notebooks, Processing, Data Wrangler, Batch Transform — across any instance family, size, or region. Discount is up to 64%. For teams running consistent SageMaker workloads, this is worth looking at. For teams running sporadic training jobs or experiments, On-Demand or Spot is almost always cheaper than committing to a baseline spend you won’t hit every hour.
Reserved Instances: Standard vs Convertible
Reserved Instances split into two offering classes with a key trade-off: discount depth vs. flexibility to change.
Standard Reserved Instances offer up to 72% off, matching EC2 Instance Savings Plans at the ceiling. The catch is inflexibility. You commit to an instance family, size, region, OS, and tenancy. You can modify size within the same family (within the same region) and you can change availability zone, but you cannot change instance family, region, or OS. The one advantage Standard RIs have over everything else: they can be sold on the Reserved Instance Marketplace. If your architecture changes and you don’t need a specific RI anymore, you can list it and recoup some of the upfront cost. AWS takes a 12% fee on each sale, and you must have at least one month remaining on the term to list.
Convertible Reserved Instances discount up to 66%, matching Compute Savings Plans at the ceiling. The trade-off goes the other way: you can exchange a Convertible RI at any time for a different Convertible RI with different attributes — new instance family, new size, different region, different OS, different tenancy — as long as the new RI is equal or greater in value. You cannot exchange for something cheaper without paying the difference. And you cannot sell Convertible RIs on the marketplace. They’re stuck with you until expiration.
The Standard vs Convertible decision is mostly about whether you need the exit hatch. If you’re confident in your instance family and region for three years, Standard with marketplace listing rights is more valuable. If you’re not sure, Convertible lets you adjust.
Discount Rate Summary
| Product | Max Discount | Lock-In |
|---|---|---|
| Compute Savings Plan | 66% | $/hour spend, 1-3 years |
| EC2 Instance Savings Plan | 72% | Instance family + region, 1-3 years |
| SageMaker Savings Plan | 64% | $/hour SageMaker spend, 1-3 years |
| Standard RI | 72% | Instance family, size, region, OS |
| Convertible RI | 66% | Instance family, region (exchangeable) |
These are ceiling numbers from 1-year All-Upfront terms. No-Upfront 1-year terms reduce discounts by roughly 15-20%. 3-year terms increase discounts, sometimes significantly. The actual number for your instance type in your region differs — check the AWS pricing calculator for specific configurations rather than assuming you’ll hit the ceiling.
Payment Options
Both Savings Plans and Reserved Instances offer three payment structures.
All Upfront pays the entire commitment in advance. This gives the deepest discount and eliminates monthly charges. Best when you have capital available and want to maximize savings over the full term.
Partial Upfront pays a portion upfront and the rest monthly. Mid-range discount. Common for teams that want to reduce cash flow impact without sacrificing too much of the discount.
No Upfront has no payment at purchase — you just pay a reduced hourly rate each month for the duration. Smallest discount, but no cash commitment up front. Not available for all instance types or regions for Reserved Instances; Savings Plans are more consistently available on No-Upfront terms.
For most engineering teams running production workloads, Partial Upfront 1-year is a reasonable starting point. It limits the cash locked up to 50% of the commitment while capturing meaningful discounts. Three-year terms make sense when your architecture has been stable for at least 18 months and you’re confident it won’t change drastically.
What Reserved Instances Still Cover That Savings Plans Don’t
Savings Plans only apply to EC2, Fargate, Lambda, and SageMaker. Several other AWS services use Reserved Instance models with no Savings Plan equivalent.
RDS Reserved Instances cover database instances in RDS — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora. Discounts up to 69% compared to On-Demand DB instance pricing. If you’re running RDS continuously, this is worth buying. The AWS FinOps framework covers RDS optimization as part of a broader cost strategy.
ElastiCache Reserved Nodes, Redshift Reserved Nodes, and OpenSearch Reserved Instances all follow the same model. You commit to a specific node type and region; AWS gives you a discount off On-Demand pricing. If you’re running any of these at scale, the reserved pricing is typically 30-50% cheaper than On-Demand for the same sustained usage.
The mistake is focusing only on EC2 when deciding between Savings Plans and Reserved Instances, then leaving RDS on On-Demand because “we’re using Savings Plans.” Savings Plans don’t touch RDS. You have to buy RDS RIs separately regardless.
Shared Billing and Multi-Account Coverage
Both Savings Plans and Reserved Instances apply across all accounts in a consolidated billing family. If you have a management account and five linked accounts, a Savings Plan purchased in the management account can apply to usage in any linked account — AWS applies it to the account with the highest eligible usage first.
You can turn this off. AWS lets you disable Savings Plan sharing or RI sharing per account. If you want a specific account to absorb its own commitments without benefiting from centrally purchased plans, that’s configurable. Most organizations leave sharing enabled to maximize utilization.
As of June 2025, AWS tightened policies around cross-account commitment pooling for managed service providers and resellers — specifically targeting scenarios where MSPs pooled commitments across unrelated customers’ accounts. If you’re in a standard organization structure with accounts owned by a single entity, this change doesn’t affect you.
Capacity Reservations: A Separate Thing
Savings Plans and Reserved Instances both reduce cost. Neither guarantees that your instance will be available when you need it during an AWS capacity crunch.
On-Demand Capacity Reservations are a separate feature that reserves EC2 capacity in a specific Availability Zone regardless of whether you’re running instances. You pay On-Demand rates for reserved capacity, running or not. To get the discount alongside the guaranteed capacity, you combine a Capacity Reservation with either a Savings Plan or a Regional RI.
For anything business-critical that cannot fail over, especially in regions or AZs where capacity has been historically constrained, capacity reservations are worth the cost. For most workloads that can tolerate an AZ failure with cross-AZ redundancy, it’s unnecessary overhead.
Five Gotchas That Cost Teams Money
Commitments don’t pause. If you buy a 1-year Savings Plan and then do a cost-reduction exercise that cuts your EC2 spend by 30%, your commitment still runs. You’ll pay the committed $/hour whether you use it or not, and the unused portion doesn’t apply to anything. Size commitments conservatively — 80% of verified baseline usage, not 100% of peak.
Standard RIs don’t cover Fargate. Many teams migrate EC2 workloads to ECS Fargate without realizing their existing Standard RIs stop applying. Savings Plans cover Fargate; Reserved Instances don’t. If you’re moving to Fargate, transition your commitments to Savings Plans before the EC2 RI term ends.
Convertible RIs can’t be sold. If you buy a Convertible RI expecting marketplace exit as a backup plan, you’re stuck. Only Standard RIs are eligible for the marketplace. If you need the flexibility to exit, either choose Standard RIs (and accept the family lock-in) or choose a shorter 1-year Savings Plan commitment you can re-evaluate annually.
Savings Plan applied retroactively 12 hours. This is a billing mechanic, not a functional delay, but it surprises people reading same-day cost reports. AWS applies Savings Plans retroactively to that day’s usage in the billing cycle, up to 12 hours after usage occurred. Your real-time cost graphs show On-Demand rates; your end-of-day bill reflects the actual Savings Plan discount. Factor this into any real-time cost monitoring setup.
EC2 Instance Savings Plans lock the region. The region is the commitment, not the account. If you buy an EC2 Instance Savings Plan for M5 in us-east-1, then decide to shift primary infrastructure to eu-west-1 for latency reasons, that Savings Plan doesn’t follow you. Compute Savings Plans are the right choice if there’s any chance of regional migration during the commitment period.
The Recommended Approach
The most effective cost structure in 2026 layers commitments rather than treating this as an either/or decision.
Start with a Compute Savings Plan covering 70-80% of your verified baseline compute spend across EC2, Fargate, and Lambda. This covers the largest, most flexible portion of your compute footprint without locking to specific instance families. The discount is real — typically 40-60% off On-Demand for common instance types.
Add EC2 Instance Savings Plans for workloads you know won’t change instance family or region for 2-3 years. Databases running on specific EC2 instance families, batch processing clusters with fixed instance types, anything where the 6-7% additional discount justifies the reduced flexibility.
Buy RDS, ElastiCache, and Redshift Reserved Instances separately for any databases running continuously. These have no Savings Plan equivalent, and the discounts are substantial.
Leave 15-20% of your compute on On-Demand for burst capacity, experiments, and new services that haven’t been running long enough to establish a baseline. Running a new service for 90 days before buying a Savings Plan against it is disciplined financial hygiene.
AWS Cost Explorer’s Savings Plans recommendations tool does a reasonable job of suggesting commitment amounts based on your historical usage. Run it quarterly. The recommendation accounts for your actual usage patterns over the past 30, 60, or 90 days and tells you how much you’re leaving on the table versus what you’re committed to. That gap is where the next purchase decision lives.
Comments