.png)
AWS Savings Plans reduce your compute bill by committing to a minimum hourly spend rate in exchange for a discounted price on eligible services. You pick a plan type, a term length (1 or 3 years), a payment structure, and a dollar-per-hour commitment amount. AWS automatically applies the discounted rate to eligible usage up to that committed amount every hour. Usage above the commitment is billed at standard On-Demand rates.
AWS launched Savings Plans in November 2019 as a more flexible alternative to EC2 Reserved Instances. The key structural difference being Reserved Instances lock you to a specific instance type and region. Savings Plans lock you to a spend rate, which gives the discount room to follow your workloads automatically as they change shape over time. For most engineering teams, that distinction is the difference between a discount that survives infrastructure changes and one that turns into dead committed spend the moment a workload gets rightsized or migrated.
For teams spending $20K/month or more on AWS compute, Savings Plans are not optional – they are the primary lever available to reduce that bill without changing architecture. A Compute Savings Plan running at 90%+ utilization on a $50K/month On-Demand baseline delivers roughly $15K-$30K in annual savings on that spend alone (exact figure depends on instance mix and regional rates, verify at Amazon docs). The reason many teams leave that money unrealized is the lack of confidence in commitment sizing, specifically, the fear of over-committing to usage that later drops.
That is what this guide resolves. It covers how each plan type works mechanically, how the discount math actually calculates, how to size a commitment to a level that captures most of the savings without over-extending, what happens when usage drops below your committed rate (and what AWS does and does not do about it), and how to monitor utilization and coverage so problems surface before they become expensive.
What Are the 4 Types of AWS Savings Plans?
AWS currently offers four distinct Savings Plan types. Each covers a different set of services and offers a different balance between maximum discount and flexibility.
Compute Savings Plans
Compute Savings Plans apply to EC2, AWS Fargate, and AWS Lambda. The defining feature is breadth of coverage: the discount applies regardless of instance family, size, region, operating system, or tenancy. If you move a workload from c5 to m6i, or from us-east-1 to ap-southeast-2, the Savings Plan discount follows automatically.
Maximum discount is up to 66% off On-Demand rates (verify current rates at Amazon Savings Plan Pricing – rates change).
This flexibility comes with a slightly lower discount rate compared to EC2 Instance Savings Plans. For most teams, that tradeoff is worth it, especially those running multi-region architectures or expecting instance family changes within the plan term.
EC2 Instance Savings Plans
EC2 Instance Savings Plans lock you to a specific instance family within a single AWS region. For example, committing to the M5 family in us-east-1 means the discount only applies to M5 instances in that region. Within that constraint, the plan covers all sizes, operating systems, and tenancy options within the family.
Maximum discount is up to 72% off On-Demand rates (verify at Amazon as rates change).
The higher discount reflects the reduced flexibility. This plan type suits teams with stable, predictable, single-region workloads where the instance family is unlikely to change over the plan term.
SageMaker Savings Plans
SageMaker Savings Plans apply to Amazon SageMaker training jobs, real-time inference endpoints, processing jobs, and Studio notebooks. Discounts apply across instance types, regions, and SageMaker components without requiring instance-level specificity.
Maximum discount is up to 64% off On-Demand SageMaker rates (verify at Amazon as rates change).
For teams running production ML workloads at meaningful scale, SageMaker Savings Plans are one of the highest-leverage commitment options available given the typically high On-Demand costs of ML instance types.
Database Savings Plans
Database Savings Plans cover RDS (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle), Amazon Aurora, Amazon Redshift, Amazon ElastiCache, and Amazon OpenSearch Service. This is the newest Savings Plans category and was introduced to reduce reliance on per-service Reserved Instances for database cost management.
Maximum discount is up to 35% off On-Demand database rates (verify at Amazon as rates change).
Note: Compute Savings Plans and EC2 Instance Savings Plans do NOT cover database services. If your RDS or Aurora spend is significant, Database Savings Plans or dedicated database Reserved Instances are separate purchases.
How AWS Savings Plans Pricing and Discounts Actually Work
The commitment is measured in dollars per hour, not in specific instance types or quantities. When you commit to $10/hour, you are agreeing to spend at least $10 every hour (on average, across the term) on eligible services. AWS applies the discounted rate to your usage up to that $10/hour threshold each hour. Any usage beyond the threshold is billed at On-Demand rates.
The discount percentage itself is set per instance type, region, OS, tenancy, and term length. AWS publishes these rates on their pricing page at aws.amazon.com/savingsplans/pricing. The discount is expressed as a percentage reduction from the On-Demand rate for that specific configuration.
A worked example with real math
Scenario: You purchase a Compute Savings Plan at $5.00/hour, No Upfront, 1-year term. Your compute workload in a given hour costs $8.00 at On-Demand rates, and your Compute Savings Plan delivers a 50% discount on covered usage (illustrative – verify your specific rates at Amazon).
AWS applies the discounted rate to the first $5.00/hour of commitment. At 50% off, you pay $2.50 for that covered block. The remaining $3.00 of usage ($8.00 minus $5.00 committed) is billed at On-Demand rates.
Effective hourly cost: $2.50 (committed, discounted) + $3.00 (On-Demand) = $5.50.
- Without any Savings Plan: $8.00.
- Actual savings: $2.50/hour, roughly 31% on total spend.
However, note that the discount applies to the committed dollar amount, not to the total bill. Usage above the commitment gets no discount.
How payment options affect the effective discount rate
AWS offers three payment structures for all Savings Plan types:
- No Upfront – Pay monthly over the full term. The effective discount rate is slightly lower than other options because AWS accounts for the time value of the deferred payment.
- Partial Upfront – Pay a portion of the term cost at purchase, remainder monthly. Delivers a better effective discount than No Upfront.
- All Upfront – Pay the full term cost at purchase. Delivers the maximum possible discount rate for that plan type and term.
The 3-year term always yields a higher discount than the 1-year term for the same payment option and plan type. A 3-year All Upfront commitment will produce the lowest effective hourly rate. A 1-year No Upfront commitment will produce the highest effective hourly rate (smallest discount). Also see: How to Choose Between 1-Year and 3-Year AWS Commitments.
Which option is right depends on your organization’s capital position and appetite for locking up cash. A company optimizing for cash flow typically prefers No Upfront. A company with available capital and a stable long-term architecture that wants to maximize savings often chooses All Upfront.
Compute Savings Plans vs EC2 Instance Savings Plans: Which One to Buy
This is the decision most FinOps engineers wrestle with. Here is a precise comparison across the dimensions that matter for the decision.
| Dimension | Compute Savings Plans | EC2 Instance Savings Plans |
| Maximum discount | Up to 66% | Up to 72% |
| Instance family flexibility | Any family | Locked to one family per region |
| Region flexibility | Any AWS region | Locked to one region |
| Operating system flexibility | Any OS | Any OS (within locked family/region) |
| Instance size flexibility | Any size | Any size (within locked family) |
| Fargate coverage | Yes | No |
| Lambda coverage | Yes | No |
| Best for | Dynamic, multi-region, multi-family | Stable, single-region, predictable |
| Lock-in risk | Lower | Higher |
The discount gap between the two plan types is roughly 6 percentage points at maximum. In most scenarios, that difference in saved dollars is smaller than the cost of accidentally over-committing to a specific instance family that later gets rightsized or migrated.
Choose Compute Savings Plans when: your workloads span multiple regions, you anticipate instance family changes (for example, moving from older generation to newer generation instances), your workloads include Fargate or Lambda, or you want the broadest possible coverage with a single commitment.
Choose EC2 Instance Savings Plans when: you have highly stable, single-region workloads anchored to a specific instance family, the usage pattern has been consistent for 6+ months, and you want to extract the maximum discount from that predictable baseline.
When uncertain, default to Compute Savings Plans. The flexibility premium is worth more than the 6% discount difference in most real-world architectures.
AWS Savings Plans vs Reserved Instances: The Real Differences
These two discount mechanisms are frequently confused. They serve similar goals but operate differently.
| Dimension | Savings Plans | Reserved Instances |
| Commitment unit | $/hour spend rate | Specific instance type and region |
| Flexibility | High (Compute SP) or moderate (EC2 Instance SP) | Low (Standard RI) or moderate (Convertible RI) |
| Automatic application | Yes, to all eligible usage | Yes, to matching instance usage |
| Database coverage | Database Savings Plans | Database-specific Reserved Instances |
| Can be sold | No | Yes (Standard RIs only, on RI Marketplace) |
| Can be converted | No | Yes (Convertible RIs only) |
| Term options | 1 or 3 years | 1 or 3 years |
| Payment options | No Upfront, Partial, All Upfront | No Upfront (1yr), Partial, All Upfront |
| Management overhead | Low (auto-applies) | Moderate (must match instance spec) |
The core structural difference: Savings Plans commit you to a spend rate. Reserved Instances commit you to a specific configuration. That distinction matters when usage patterns change.
If you launch a Savings Plan and then change instance types or regions, the Savings Plan (especially Compute) continues to apply to the new configuration. A Standard Reserved Instance tied to the old instance type stops generating a discount the moment you stop running that specific configuration.
Reserved Instances retain one unique advantage: Standard RIs can be listed and sold on the AWS Reserved Instance Marketplace if you no longer need them. Savings Plans have no equivalent secondary market. This is relevant for organizations that might need to exit a commitment early.
For a deeper breakdown, see: AWS Reserved Instances vs Savings Plans: What Actually Saves More.
How to Buy AWS Savings Plans: Step-by-Step
Prerequisites
Before purchasing, gather the following:
- AWS Cost Management console access (requires billing-level permissions)
- At least 30 days of historical usage data visible in Cost Explorer
- A decision on plan type, term, and payment option
- A carefully calculated commitment amount (see the sizing section below)
Step 1: Open AWS Cost Management and navigate to Savings Plans
Go to console.aws.amazon.com, open the Cost Management section, and select “Savings Plans” from the left navigation menu. The overview page shows your current Savings Plans inventory (if any) and utilization metrics.
Step 2: Review Cost Explorer Recommendations
Navigate to “Recommendations” in the Savings Plans section. AWS Cost Explorer analyzes your historical usage and suggests a commitment amount and plan type. These recommendations are based on a lookback period of your choice (7, 30, or 60 days) and target a coverage percentage you specify.
Important limitation: AWS Cost Explorer refreshes its underlying data every 72 hours or more. If your usage has changed significantly in the past few days – due to a new workload launch, a rightsizing effort, or a workload shutdown – the recommendations will not reflect that change yet.
Review the recommendations as a starting point, not a final answer. Cross-reference against your own understanding of recent workload changes before committing.
Step 3: Choose plan type and term
Select the plan type that matches your coverage goals. Choose 1-year or 3-year term based on how confident you are in your usage trajectory. For most teams new to Savings Plans, 1-year is the lower-risk starting point even if the 3-year discount is more attractive.
Step 4: Select a payment option
Choose No Upfront, Partial Upfront, or All Upfront. The console displays the effective hourly rate for each combination. Higher upfront payment yields a lower effective rate (higher effective discount).
Step 5: Set the commitment amount conservatively
Enter your commitment in $/hour. The right starting point for most teams is 70-80% of current baseline usage, not 100%. This leaves room for usage drops without stranding committed spend. See the next section for detailed sizing guidance.
Step 6: Review and purchase
Confirm all parameters. The console shows an estimated annual savings figure. Complete the purchase. Discounts begin applying to eligible usage within the hour.
How to verify it worked
Check the Savings Plans utilization dashboard in Cost Management 24-48 hours after purchase. Your utilization rate shows what percentage of your committed spend is being consumed each hour. A utilization rate above 90% means your commitment is well-calibrated. Below 80% means you have over-committed.
How to Size a Savings Plan Commitment Without Over-Committing
Correct sizing is the single most important factor in Savings Plans management. Over-commit and you pay for unused capacity. Under-commit and you leave savings unrealized. The goal is to cover the stable, predictable floor of your compute usage without extending into variable or elastic territory.
Step 1: Identify your baseline usage
Pull your On-Demand equivalent spend from Cost Explorer for the last 60-90 days. Exclude Spot Instance spend – Savings Plans do not apply to Spot. Look at the minimum hourly spend across that period, not the average. The minimum represents your true baseline and it is the usage that is always running regardless of traffic spikes.
Step 2: Apply a conservative coverage ratio
Most FinOps practitioners recommend covering 70-80% of baseline with Savings Plans in the first purchase. Covering 100% of even the minimum leaves no buffer for any reduction in steady-state usage. If you add Savings Plans over time (layering additional commitments as confidence grows), you can increase coverage toward 90%+ without the risk of a single large over-commitment.
Step 3: Account for planned changes
If you know a workload is being decommissioned, rightsized, or migrated in the next 3-6 months, exclude that usage from your commitment calculation. Savings Plans cannot be cancelled after purchase (through AWS natively), you will pay the committed rate for the full term regardless.
Step 4: Model the break-even point
For any commitment, calculate the break-even utilization rate. At what utilization level does the Savings Plan save more than it costs? For a plan with a 30% discount, you break even at 100% utilization. At 80% utilization, your effective savings on the committed portion drop to roughly 24% of face value. At 60% utilization, you are likely saving less than the On-Demand equivalent would have cost.
The break-even math is specific to your plan type, term, and discount rate. Run it against your actual discount rate from the AWS pricing page before committing.
What Happens If You Over-Commit or Usage Drops?
This is the question competitors consistently avoid answering clearly. Here is the precise answer.
If you purchase a Savings Plan for $10/hour and your actual compute usage drops to $6/hour, you still owe the committed $10/hour. AWS bills you for the full commitment whether the capacity is consumed or not. The $4/hour gap generates zero discount and zero value. It is committed spend with no return.
At $10/hour over-commitment, the annual cost of that gap is $87,600. At $4/hour underutilization, you are paying $35,040/year for capacity you are not using.
AWS does not offer refunds, credits, or buybacks for underutilized Savings Plans. The commitment is legally binding for its full term. There is no AWS-native mechanism to exit a Savings Plan early, transfer it, or sell it (unlike Standard Reserved Instances, which can be listed on the RI Marketplace).
The most common causes of over-commitment
- Workload migrations. A team commits to cover EC2 usage that subsequently moves to containers on Fargate. The Compute Savings Plan continues to apply to Fargate, so this specific scenario is handled. But if the workload moves to a non-covered service or is shut down entirely, the commitment orphans.
- Organizational rightsizing. A cost optimization initiative reduces instance sizes across a fleet. The On-Demand equivalent spend drops. The Savings Plan commitment stays at the original level.
- Seasonal traffic patterns. A commitment sized for peak season carries excess committed spend through off-peak months.
- Recommendation lag. AWS Cost Explorer recommendations are based on historical data with a 72-hour or longer refresh cycle. A workload reduction that happened two days ago will not appear in the next recommendation you generate.
How to monitor for over-commitment
The Savings Plans utilization dashboard in AWS Cost Management shows your utilization rate by day. Watch for any multi-day drop below 90%, that is the early signal of an emerging over-commitment situation. The earlier you catch it, the more you can compensate by scaling usage (if appropriate) or buying less aggressively on the next commitment purchase.
Understanding Savings Plans Utilization Rate and Coverage Rate
These two metrics are often conflated. They measure opposite failure modes.
Utilization rate answers: of the commitment I purchased, how much am I actually consuming?
A 95% utilization rate means 95 cents of every committed dollar is generating a discount. A 70% utilization rate means 30 cents of every committed dollar is waste; you committed to it, AWS is charging for it, but nothing in your infrastructure is consuming it.
Coverage rate answers: of my eligible On-Demand spend, how much is covered by a Savings Plan?
A 40% coverage rate means 60% of your eligible compute spend is still at On-Demand pricing. That 60% is a savings opportunity you have not captured yet.
The healthy operating range for most teams:
- Utilization rate: 90% or higher (signals appropriately sized commitment)
- Coverage rate: 80% or higher (signals adequate coverage of eligible spend)
Running high utilization with low coverage means you have a well-sized commitment that is too small – you are leaving savings on the table. Running high coverage with low utilization means you have over-committed – you are paying for committed spend that your actual usage does not consume.
Both metrics need to be tracked together. AWS Cost Management shows both in the Savings Plans section under “Coverage” and “Utilization” reports separately.
Four Important Savings Plans Boundaries Most Teams Get Wrong
Savings Plans do not apply to Spot Instances
Savings Plans discounts apply against On-Demand equivalent usage only. Spot Instances are priced through a separate market mechanism and already carry significant discounts from On-Demand rates. Running workloads on Spot while holding Savings Plan commitments means those Spot hours do not count toward your committed usage consumption. If your fleet is heavily Spot-based, your effective Savings Plan utilization will be lower than your total compute spend suggests. Size your commitment only against the portion of your workload that runs On-Demand or reserved-equivalent. Also see: On-Demand vs Reserved vs Spot Instances.
Compute Savings Plans do not cover RDS or other database services
Compute Savings Plans and EC2 Instance Savings Plans do not cover RDS, Aurora, ElastiCache, Redshift, or OpenSearch. Database services require either Database Savings Plans or database-specific Reserved Instances purchased separately per service. Teams that purchase a Compute Savings Plan expecting RDS coverage will see their database spend remain fully at On-Demand pricing. If database services represent a significant share of your AWS bill, that is a separate commitment decision requiring a separate analysis.
Savings Plans discount rates are not uniform across regions
Discount rates vary by region because the underlying On-Demand rates themselves vary by region. An m5.large in us-east-1 has a different On-Demand rate than the same instance in ap-southeast-1, and therefore a different Savings Plan effective rate. A Compute Savings Plan purchased with us-east-1 usage in mind will apply the same committed spend against ap-southeast-2 usage – but the dollar-per-hour goes further in some regions than others depending on relative On-Demand pricing. Always verify regional rates at aws.amazon.com/savingsplans/pricing before sizing a commitment.
Savings Plans cannot be sold or transferred
Unlike Standard Reserved Instances, which can be listed and sold on the AWS Reserved Instance Marketplace, Savings Plans have no secondary market. Once purchased, the commitment runs for its full term with no exit option through AWS. This is a meaningful distinction for organizations that might need early exit flexibility. If there is a reasonable chance a workload will be decommissioned within the plan term, either size the commitment conservatively or evaluate whether Standard Reserved Instances (with their marketability) are a better fit for that specific use case.
How the AWS Cost Explorer recommendation engine actually works
AWS Cost Explorer analyzes historical usage and calculates a commitment amount that would have achieved a specified coverage target (typically 80%) over the lookback period you select: 7, 30, or 60 days. The output is retrospective. It tells you what commitment would have been optimal for past usage. It does not predict future usage, account for planned workload changes, or factor in decommissions. The 72-hour data refresh cycle means any usage change in the last three days is invisible to the recommendation. Use Cost Explorer recommendations as a starting data point, then adjust based on your own understanding of where usage is heading.
A Note on Automated Savings Plans Management
For engineering teams managing large AWS bills, typically $100K/month or more in compute spend, manually tracking utilization rate, coverage rate, and recommendation freshness across multiple accounts becomes a material operational burden. A 72-hour lag in detecting an over-commitment at $10K/day in committed spend costs real money.
Usage.ai automates this workflow: it refreshes commitment recommendations every 24 hours (versus Cost Explorer’s 72-hour cycle), purchases commitments with a buyback guarantee on underutilization, and pays cashback on any unused commitment in real money rather than credits. The platform covers EC2, Fargate, Lambda, RDS, ElastiCache, OpenSearch, Redshift, and DynamoDB with zero upfront cost and no multi-year lock-in. The fee model is a percentage of realized savings. Zero fee if nothing is saved.
If your team is spending engineering hours on what should be an automated process, it is worth running the numbers.
Frequently Asked Questions
1. What is an AWS Savings Plan and how does it work?
An AWS Savings Plan is a commitment-based pricing model that reduces compute, database, and ML service costs by 20-66% in exchange for a consistent hourly spend commitment over 1 or 3 years. You commit to a minimum dollar-per-hour rate. AWS automatically applies the discounted price to eligible usage up to that rate each hour. Any usage exceeding the commitment is billed at standard On-Demand rates. Discounts apply automatically with no manual instance-level reservation required.
2. What happens if I don’t use all my AWS Savings Plan?
If your actual usage falls below your committed hourly rate, you still pay the full committed amount. AWS bills the committed rate regardless of actual consumption. The unused portion generates no discount and cannot be refunded, credited, or transferred. At a $10/hour over-commitment, the annual exposure is $87,600.
3. Is it worth buying AWS Savings Plans in 2026?
For teams with stable, predictable baseline compute usage, Savings Plans remain one of the most effective ways to reduce AWS bills by 30-66%. The calculation changes when usage is volatile or declining. If your workloads are in flux, may be due to migrations, rightsizing, or organizational changes, a conservative commitment (70-80% of current baseline) reduces the risk of stranded committed spend.
4. What is the difference between Compute Savings Plans and EC2 Instance Savings Plans?
Compute Savings Plans deliver up to 66% savings across any EC2 instance family, region, OS, and tenancy, plus Fargate and Lambda. EC2 Instance Savings Plans deliver up to 72% savings but lock coverage to a specific instance family within one region. The 6% discount difference rarely justifies the flexibility penalty unless you have highly stable, single-region workloads anchored to one instance family. For most architectures, Compute Savings Plans are the correct default.
5. Do AWS Savings Plans cover RDS or database services?
No, Compute Savings Plans and EC2 Instance Savings Plans do not cover RDS, Aurora, ElastiCache, Redshift, or OpenSearch. Database services require Database Savings Plans (up to 35% savings – verify at Amazon) or dedicated database Reserved Instances purchased separately per service. Purchasing a Compute Savings Plan with the expectation that it covers RDS is one of the most common and expensive planning errors in AWS cost management.
6. How are AWS Savings Plans different from Reserved Instances?
Savings Plans commit you to an hourly spend rate and automatically apply across eligible service families. Reserved Instances commit you to a specific instance configuration and region. Standard Reserved Instances can be sold on the AWS Marketplace if unused; Savings Plans cannot. For most use cases, Savings Plans now offer better flexibility than Standard RIs. Convertible Reserved Instances offer some exchange flexibility but at a lower discount than Standard RIs.
7. How do I check if my Savings Plans are being fully utilized?
Open AWS Cost Management and navigate to Savings Plans, then select the Utilization report. A healthy utilization rate is 90% or higher. Rates below 80% indicate over-commitment – you are paying for committed spend that your infrastructure is not consuming. Check utilization daily or weekly, not monthly. A multi-day utilization drop is an early warning signal that requires either scaling usage toward the commitment or sizing future commitments more conservatively.
8. What is the minimum purchase amount for AWS Savings Plans?
AWS does not publish a formal minimum dollar amount. The commitment is expressed as $/hour, and technically any non-zero commitment is valid. In practice, meaningful savings only materialize when the commitment is sized against a substantial portion of your compute baseline. AWS Cost Explorer will not generate recommendations below a threshold that produces meaningful projected savings. Use the recommendations as a floor and adjust based on your actual usage analysis.
