AWS Savings Plans reduce the price of eligible AWS usage in exchange for a commitment to spend a fixed amount every hour for a defined term. Instead of reserving a particular server, you commit to an hourly amount—such as $10 per hour—and AWS automatically applies discounted Savings Plans rates to matching usage.
The basic idea is simple: commit to predictable usage and receive a lower rate than On-Demand pricing. The difficult part is deciding which type of Savings Plan to buy, how large the commitment should be, whether to choose one or three years, and how much flexibility you may need as your infrastructure changes.
AWS currently offers four types of Savings Plans:
- Compute Savings Plans
- EC2 Instance Savings Plans
- Database Savings Plans
- SageMaker AI Savings Plans
Each has different eligible services, discount ceilings, terms, and flexibility. A well-sized plan can materially reduce an AWS bill with no application changes. A badly sized plan can create years of unavoidable spend.
What is an AWS Savings Plan?
An AWS Savings Plan is a pricing commitment, not a prepaid balance and not a guarantee that a particular instance will be available. You agree to a consistent amount of eligible usage, measured in dollars per hour. AWS then charges the lower Savings Plans rate for matching usage until that hourly commitment is consumed.
Usage above the commitment remains eligible to run, but the excess is normally charged at On-Demand rates unless another discount applies. If eligible usage falls below the commitment in a particular hour, you still pay the full committed amount. The unused portion does not roll into the next hour.
That hourly calculation matters. A workload can look stable when viewed monthly while falling below its commitment at night or on weekends. Monthly averages can therefore hide underutilization.
Savings Plans are billing instruments. They do not change how an application runs, require a code deployment, or reserve EC2 capacity. If capacity assurance is required, an On-Demand Capacity Reservation must be managed separately; an applicable Savings Plan can still discount the eligible compute running within it.
How does the hourly commitment work?
Assume you purchase a one-year Compute Savings Plan with a $10-per-hour commitment and no upfront payment. You are agreeing to pay $10 for every hour of the term at the applicable Savings Plans pricing basis.
The simple annual commitment is:
$10 × 24 hours × 365 days = $87,600
In an hour where your eligible usage consumes the full $10 commitment at Savings Plans rates, the plan is 100% utilized. If only $8 applies, you still pay $10 and $2 is unused. If $13 of eligible usage exists at Savings Plans rates, the plan covers $10 and the remaining usage is charged at the applicable rate—typically On-Demand unless another discount instrument covers it.
Do not confuse a $10-per-hour commitment with $10 of On-Demand usage. The commitment is consumed using Savings Plans rates. Because those rates are lower, a $10 commitment may cover an On-Demand equivalent worth materially more than $10.
AWS applies Savings Plans automatically. You do not manually attach a Compute Savings Plan to an individual EC2 instance. The billing system evaluates eligible usage during each hour and uses the commitment where it produces the highest savings percentage.
This produces two core metrics:
- Utilization measures how much of the purchased commitment was used. A $10 commitment with $9.80 applied has 98% utilization.
- Coverage measures how much eligible usage received Savings Plans pricing. High coverage can reduce On-Demand exposure, but pursuing 100% coverage can create overcommitment when usage falls.
The objective is not maximum coverage in isolation. It is maximum net savings after unused commitments, fees, and remaining On-Demand spend.
The four types of AWS Savings Plans compared
| Savings Plan type | Eligible usage | Flexibility | Maximum advertised saving | Available term |
|---|---|---|---|---|
| Compute Savings Plans | EC2, Fargate and Lambda | Across instance families, sizes, operating systems, tenancy and Regions; can move among eligible compute services | Up to 66% | 1 or 3 years |
| EC2 Instance Savings Plans | EC2 | Limited to one instance family in one Region; flexible across size, OS, tenancy and Availability Zone within that scope | Up to 72% | 1 or 3 years |
| Database Savings Plans | Eligible database services and usage types | Broad movement across supported services, engines, sizes, Regions and deployment models | Up to 35% | 1 year |
| SageMaker AI Savings Plans | Eligible SageMaker AI instance usage | Across eligible instance families, sizes, components and Regions | Up to 64% | 1 or 3 years |
The advertised figures are maximums, not expected savings for every workload. Actual rates depend on the service, usage type, term, payment option, operating system, Region, and other configuration details.
Compute Savings Plans
Compute Savings Plans offer the broadest compute flexibility. They apply to eligible Amazon EC2, AWS Fargate, and AWS Lambda usage. For EC2, the discount can follow a workload across instance families, sizes, Regions, operating systems, and tenancy options.
This makes Compute Savings Plans suitable when the baseline spend is predictable but the underlying technology may change. A team can migrate from an older x86 EC2 family to Graviton, move a service between Regions, or refactor EC2 workloads to Fargate or Lambda while retaining eligible coverage.
Compute Savings Plans can also cover the underlying EC2 instances used by Amazon ECS, Amazon EKS, and Amazon EMR. They do not automatically discount every separate service charge. For example, the EKS cluster fee is not covered merely because the worker-node EC2 usage is eligible.
The trade-off is price. AWS advertises savings of up to 66%, below the up-to-72% ceiling of EC2 Instance Savings Plans. The difference is the cost of broader technical flexibility.
EC2 Instance Savings Plans
EC2 Instance Savings Plans offer deeper potential discounts in exchange for a narrower commitment. The plan is tied to an EC2 instance family in a specific AWS Region, such as the m7g family in eu-west-1.
Within that family and Region, the plan can apply across instance sizes, Availability Zones, operating systems, and tenancy. It therefore offers more flexibility than reserving one exact EC2 configuration, but much less than a Compute Savings Plan.
This option fits workloads with a stable, well-understood baseline and little probability of changing family or Region during the term. It is riskier when rightsizing, architecture changes, Graviton adoption, regional migration, or a move to serverless compute is likely.
Database Savings Plans
Database Savings Plans reduce eligible database costs by up to 35% for a one-year hourly commitment. They are broader than a traditional database Reserved Instance because qualifying usage can move across supported engines, services, instance types, Regions, and provisioned or serverless deployment models.
AWS lists coverage across services including Amazon Aurora, Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB, Amazon Neptune, Amazon Keyspaces, Amazon Timestream, AWS Database Migration Service, and Amazon OpenSearch Service. Eligibility has important limits. AWS currently specifies Generation 7 and newer instances for covered instance usage, as well as service-specific restrictions such as Valkey for eligible ElastiCache coverage and InfluxDB for eligible Timestream coverage.
Database Savings Plans are available for one year with no upfront payment. Paying AWS in advance through its billing advance-pay feature is not the same as selecting a separate all-upfront Database Savings Plan pricing option.
The same workload cannot receive both a Database Savings Plans discount and an RDS Reserved Instance or DynamoDB reserved-capacity discount. Different instruments can still cover different parts of the environment.
SageMaker AI Savings Plans
SageMaker AI Savings Plans apply to eligible SageMaker AI instance usage across components such as notebooks, processing, training, Data Wrangler, real-time inference, and batch transform. AWS advertises savings of up to 64%.
They are useful when SageMaker AI usage is consistently present but shifts between instance families, sizes, components, or Regions. They do not serve as a general compute plan for EC2, Fargate, or Lambda; Compute Savings Plans and SageMaker AI Savings Plans cover different service categories.
One-year versus three-year Savings Plans
Compute, EC2 Instance, and SageMaker AI Savings Plans offer one-year and three-year terms. Three-year terms normally provide higher discount rates, but they also extend the period during which incorrect assumptions can create waste. Database Savings Plans currently use a one-year term only.
A one-year plan is often presented as the safe middle ground. In practice, it can combine a relatively modest discount with most of the structural rigidity of a longer Savings Plan. It cannot normally be sold on a secondary market, and AWS does not let you freely modify the terms after purchase.
AWS does allow a narrow return window for qualifying recent purchases: a plan with an hourly commitment of $100 or less may be returned when it was purchased within the previous seven days and remains in the same calendar month. This is an error-correction window, not a long-term exit mechanism.
Our separate analysis, 1-Year Savings Plans: The Worst Tool for Cutting AWS Costs, explains why automatically choosing one year can provide less flexibility than it appears to. The central problem is not that every one-year plan is wrong. It is that term length is often used as a substitute for proper workload analysis, portfolio design, and active commitment management.
Three-year commitments belong only under usage that is genuinely durable or in a strategy with practical flexibility elsewhere. Variable, experimental, or shrinking workloads should not be committed merely to increase a coverage percentage.
No upfront, partial upfront, or all upfront
For Compute, EC2 Instance, and SageMaker AI Savings Plans, AWS offers three payment options:
- No Upfront: no initial payment; the commitment is charged over the term. This preserves cash but normally carries the highest rate among the three choices.
- Partial Upfront: at least half of the commitment is paid initially and the remainder is charged over time. The rate is lower than No Upfront.
- All Upfront: the entire commitment is paid at purchase and AWS provides the lowest price.
The lowest unit rate is not automatically the best financial decision. All Upfront increases cash concentration and exposes the entire purchase amount immediately if the workload disappears. Compare total savings, utilization risk, cost of capital, cash flow, and accounting treatment—not only the displayed discount percentage.
In what order does AWS apply Savings Plans?
AWS calculates discounts automatically rather than letting teams assign every plan manually. For compute usage, the main order is:
- Eligible EC2 Reserved Instances apply first.
- EC2 Instance Savings Plans apply before Compute Savings Plans because they have narrower scope.
- Within the remaining eligible usage, AWS generally applies commitments where they produce the highest savings percentage.
- Usage left after all applicable commitments is charged at On-Demand rates unless another pricing model applies.
Savings Plans do not apply to Spot usage or usage already covered by an EC2 Reserved Instance. Lambda request charges are also distinct from eligible Lambda duration usage, so a Compute Savings Plan does not simply discount every line item bearing the Lambda name.
This automated application is useful, but it does not eliminate planning risk. AWS can efficiently apply the commitment you purchased; it cannot make an oversized or poorly chosen commitment disappear.
How Savings Plans work across multiple AWS accounts
Within AWS Organizations and consolidated billing, Savings Plans can be purchased in a member or management account. With discount sharing enabled, benefits can apply across eligible accounts. AWS applies a plan first to eligible usage in the account that owns it, then shares remaining benefit with other accounts in the billing family.
Centralized purchasing usually creates a broader usage pool and can improve utilization because hourly fluctuations in separate accounts may offset each other. A development account may be busy during office hours while a batch account peaks overnight.
The purchasing-account decision still matters. Account affinity, discount-sharing settings, divestitures, billing transfers, internal chargeback, and business-unit autonomy can all affect where benefits land. AWS management-account recommendations consider shared usage across participating accounts, while member-account recommendations optimize each account in isolation. Those recommendation sets should not be blindly added together.
AWS Savings Plans versus Reserved Instances
Savings Plans and Reserved Instances both reduce rates in exchange for commitment, but they are not interchangeable.
| Question | Savings Plans | Reserved Instances |
|---|---|---|
| What is committed? | A monetary usage amount per hour | A reservation or billing benefit tied to defined attributes |
| Application | Automatically applied to eligible usage | Depends on RI type and attributes |
| Flexibility | Highest with Compute and Database Savings Plans | Convertible RIs can be exchanged; Standard EC2 RIs are narrower |
| Secondary market | No general resale market | Eligible Standard EC2 RIs may be listed on the RI Marketplace |
| Capacity reservation | No | Zonal EC2 RIs can reserve capacity; regional RIs do not |
| Maximum compute discount | Up to 72% for EC2 Instance Savings Plans | Up to 72% for Standard RIs, depending on configuration |
Savings Plans are often easier to operate because the billing benefit follows eligible usage automatically. Standard EC2 RIs can offer something Savings Plans cannot: an exit path through the Reserved Instance Marketplace for eligible listings. Marketplace liquidity is not guaranteed, and technical, account, and geographic restrictions apply, but the distinction matters when flexibility is a primary objective.
The right answer is often a portfolio rather than a single instrument. Stable workloads can justify deeper, narrower commitments. Changing workloads require broader coverage or retained On-Demand exposure. Tradable or convertible instruments can add optionality where static Savings Plans cannot.
How to choose the right Savings Plan
Start with the workload, not the discount percentage.
1. Remove obvious waste first
Do not buy commitments to cover idle instances, oversized databases, abandoned environments, or resources scheduled for retirement. A discount on unnecessary usage is still unnecessary spend.
2. Measure the hourly baseline
Analyze at least several representative months and inspect hourly lows, not only monthly averages. Separate permanent baseline consumption from seasonal growth, launches, temporary projects, and one-off migration activity.
3. Map the technical roadmap
Identify expected family changes, Graviton migrations, rightsizing, regional moves, acquisitions, divestitures, Fargate or Lambda adoption, database modernization, and workload shutdowns. A plan that matches today’s environment can be wrong six months later.
4. Choose scope before term
Use EC2 Instance Savings Plans only for the portion expected to remain in the same family and Region. Use Compute Savings Plans when the spend is durable but its technical form may change. Use Database or SageMaker AI Savings Plans only after verifying that the exact usage types are eligible.
5. Commit in layers
Avoid treating a forecast as one irreversible purchase. Cover the hardest baseline first, preserve On-Demand headroom for uncertainty, and add commitments as evidence strengthens. Staggering purchases can reduce renewal cliffs and the risk of locking an entire portfolio to one historical snapshot.
6. Compare net savings, not headline rates
Model the cost of unused commitment, remaining On-Demand spend, upfront cash, internal operating effort, and any external management fee. Effective Savings Rate—actual savings divided by the equivalent On-Demand cost—is more useful than the maximum advertised discount.
Common AWS Savings Plans mistakes
Buying directly from a short lookback
AWS recommendations can use 7-, 30-, or 60-day lookback periods. A recommendation is a historical simulation, not knowledge of your roadmap. Recent launches, seasonal traffic, or migrations can distort the result.
Combining overlapping recommendations
AWS states that Compute and EC2 Instance Savings Plans recommendations use the same underlying usage and are not intended to be purchased together as two additive recommendations. Doing so can double-count the opportunity.
Targeting 100% coverage
Full coverage often means committing variable peaks. High utilization of a conservative baseline can produce better net savings than 100% coverage followed by years of unused commitments.
Assuming “flexible” means cancellable
Compute Savings Plans are flexible in where the discount applies, not in whether the financial commitment remains. Outside the limited return window, Savings Plans cannot simply be cancelled when strategy changes.
Ignoring expiration and renewal timing
When several plans expire together, coverage can collapse overnight or teams can rush into a poorly sized renewal. Maintain an inventory of start dates, end dates, payment types, hourly commitments, utilization, and accountable owners.
Monitoring utilization without net savings
A plan can show high utilization and still be inferior to a better commitment mix. Track utilization, coverage, On-Demand equivalent cost, realized net savings, and effective discount together.
How to monitor AWS Savings Plans
AWS Cost Explorer provides recommendations, coverage reports, utilization reports, inventory, and a Purchase Analyzer. The Cost and Usage Report or AWS Data Exports provides more granular line-item data for allocation and independent analysis.
Review at least these controls:
- Hourly and monthly utilization by plan
- Coverage by service, account, Region, and instance family
- Unused commitment and associated cost
- Remaining eligible On-Demand spend
- Effective Savings Rate against the On-Demand equivalent
- Plans approaching expiration
- Planned engineering or business changes that could affect demand
- Discount-sharing and Cost Categories configuration
Monitoring does not change an existing Savings Plan. It identifies risk early enough to change future purchases, redistribute eligible usage where operationally valid, or adjust the wider mix of Savings Plans and Reserved Instances.
Frequently asked questions about AWS Savings Plans
Do AWS Savings Plans save money automatically?
AWS automatically applies an active plan to eligible usage, but the plan only saves money overall when the discounted benefit exceeds the cost of unused commitment. Application is automatic; good purchasing is not.
Can you cancel an AWS Savings Plan?
Not as a general rule. AWS currently allows qualifying plans of $100 per hour or less to be returned within seven days of purchase and within the same calendar month. After that narrow window, treat the plan as non-cancellable for its term.
Can AWS Savings Plans be sold or transferred?
Savings Plans do not have a general secondary marketplace. Benefits can be shared across eligible accounts within the same consolidated billing family when sharing is enabled, but that is not the same as selling or transferring the contract to another organization.
Do Savings Plans cover Amazon EKS and ECS?
Compute and EC2 Instance Savings Plans can cover eligible underlying EC2 compute used by EKS or ECS. Compute Savings Plans can also cover eligible Fargate compute. Separate service charges, including the EKS cluster fee, are not automatically covered.
Do Savings Plans cover RDS?
Compute and EC2 Instance Savings Plans do not cover RDS. Eligible RDS usage may be covered by Database Savings Plans, subject to current eligibility rules, or by RDS Reserved Instances.
Do Savings Plans cover data transfer, storage, or support?
No. Savings Plans target defined eligible compute, database, or SageMaker AI usage. They do not broadly discount data transfer, EBS volumes, S3 storage, AWS Support, taxes, or every charge generated by a covered service.
Do Savings Plans provide EC2 capacity reservations?
No. A Savings Plan is a billing discount. Use On-Demand Capacity Reservations or an applicable zonal Reserved Instance when capacity assurance is required.
Is a one-year or three-year Savings Plan better?
Three-year plans normally offer deeper discounts; one-year plans reduce the duration of forecast risk. Neither is automatically better. Choose based on the durability of the hourly baseline, technical roadmap, payment option, and available flexibility in the rest of the commitment portfolio.
What is good Savings Plans utilization?
There is no universal target. Consistently high utilization is desirable, but the correct threshold depends on discount depth and opportunity cost. A 95% utilized plan can be economically strong, while a 100% utilized plan may still leave too much usage at On-Demand rates. Net savings is the final measure.
When should you avoid a Savings Plan?
Avoid or limit Savings Plans when usage is temporary, highly variable, expected to shrink, in the middle of major rightsizing, or likely to move outside the plan’s eligibility. Spot pricing, On-Demand usage, Reserved Instances, or a smaller layered commitment may be more appropriate.
Automate AWS discount management without sacrificing flexibility
Savings Plans are easy to buy and difficult to size correctly for a changing environment. The real work is continuous: measuring the durable baseline, selecting the right instrument, tracking utilization, planning renewals, and adapting the portfolio as engineering priorities change.
Hykell automates AWS Savings Plans and Reserved Instance optimization at the billing layer, with no application changes and no ongoing commitment-management workload for your engineering team. Hykell combines Savings Plans with Standard and Convertible Reserved Instances to pursue higher net savings while retaining more practical flexibility than a static, Savings-Plans-only strategy.
Get a free AWS cost and commitment analysis to identify unused commitments, eligible On-Demand spend, and a safer route to better discount coverage. Automate discount management, save engineering and FinOps time, and build flexibility into the way commitments are selected and managed.
