Savings Plans are not just cheaper Reserved Instances: three types, three payment options, and three limits rarely mentioned - no capacity reservation, a 7-day return window, and billing that continues after account closure.
Search for AWS Savings Plans and you will find two opposite claims: one says they are flexible enough to replace Reserved Instances entirely, the other says they are a trap. Neither is accurate.
Savings Plans and Reserved Instances are two instruments at the same layer, and they differ along three axes: flexibility, discount depth, exit cost. Understand those three and the decision becomes obvious.
This page follows the order you actually decide in: before you buy, how much to buy, and what to watch afterwards.
First: Savings Plans and Reserved Instances are not the same thing
Both ask you to commit in advance in exchange for a lower unit price. What you commit to is different, and that decides everything else:
| Reserved Instances (RI) | Savings Plans (SP) | |
|---|---|---|
| What you commit | A specific configuration (standard RI) or a convertible one | An hourly spend amount |
| Flexibility | Low - a standard RI locks family and region | High - Compute SP spans families, sizes, OS and regions, and covers Lambda and Fargate |
| Discount depth | Deeper (a standard RI is on par with an EC2 Instance SP) | Compute SP is shallower; EC2 Instance SP goes deeper |
| Capacity reservation | Optional (useful when you must have the instance) | Not provided |
| Exit route | A standard RI can be resold on the RI Marketplace | No resale route - only a 7-day return window |
| Ongoing management | Buy per family, track coverage per family | Buy once, applied automatically to everything eligible |
In one line: an RI trades "more locked-in" for "deeper discount plus capacity reservation plus resale". A Savings Plan trades "slightly shallower discount" for "almost no management". You can hold both at once - it is not either/or.
The same trade-off appears at the other providers (Alibaba Cloud International savings plans commit an amount, Tencent Cloud International reservations lock the spec) - all five compared in cloud discount mechanisms compared.
Three types, and where the discount depth differs
A Savings Plan is not one product but three, with different coverage and depth:
| Type | Coverage | Published ceiling |
|---|---|---|
| Compute Savings Plans | EC2 + Lambda + Fargate; across families, sizes, OS, tenancy and regions | Up to 66% |
| EC2 Instance Savings Plans | One instance family in one region (sizes, OS and tenancy stay flexible) | Up to 72% |
| SageMaker Savings Plans | SageMaker machine learning instance usage | Up to 64% |
The gap between those numbers is what you pay for flexibility: Compute is the most flexible and therefore the shallowest; EC2 Instance SP locks region plus family and goes deepest. Note that it locks less than an RI - within the family you can change size, operating system and tenancy and still keep the discount. Only changing family or region breaks it.
There are also Database Savings Plans, covering Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream and DMS, published at up to 35%, currently a one-year term with no upfront option. If databases dominate your bill - which is common - this deserves its own calculation.
⛔ Do not read "up to" as an expectation. Those are ceilings published by AWS; what you actually get depends on usage shape, region, term and payment option, and the official live pricing is authoritative. Note also that published figures differ by region (the China Regions pages carry different numbers, because those regions are independently operated and priced) - compare against the pricing page for the region you actually use.
Three payment options: more upfront is cheaper, and riskier
The same plan comes with three payment options, and the discount deepens in this order:
| Option | How you pay | Who it suits |
|---|---|---|
| No Upfront | Billed monthly throughout | Cash-flow first, or a first experiment |
| Partial Upfront | Part paid up front, the rest monthly | The balance point for most teams |
| All Upfront | Paid in full up front | Cash-rich, wants the deepest discount |
Fundamentally this is trading cash flow for discount. Compare the discount difference against your cost of capital and the answer falls out. In practice, first-time buyers are better off starting with No Upfront: if the judgement turns out wrong, the loss is "did not capture the full discount" rather than "a large sum already gone".
⛔ Whatever the payment option, the commitment itself is not reversible. All Upfront maximises the consequence of that sentence: the money is spent, and lower usage does not give it back. The only exception is the 7-day return window - see the second limit below.
Do this first: right-size before you commit
A commitment discount applies to the usage you have now. If the instances are over-provisioned, buying a commitment means locking the waste in for one or three years. So the order matters:
- Right-size first: use something like Compute Optimizer to find obvious over-provisioning. Low CPU alone does not mean you should downsize - check memory and I/O together.
- Then look at architecture: moving to a better price-performance chip (Graviton, for example) cuts cost directly and carries no lock-in, so it can be reverted at will.
- Only then buy the commitment, covering the usage you are confident will stay.
⛔ Reverse the order and you lose twice: commit against over-provisioned usage, then change architecture to cut cost - coverage drops, and the commitment cannot be returned. That is where "architecture first, then commitment" comes from; more in what Graviton actually saves.
How much: start at 70-80% of the steady baseline, not 100%
Cost Explorer will suggest a commitment level based on historical usage, and the console buys it in one click. That is where people go wrong:
- The suggestion is built from the past, and things change: promotions end, experiments stop, architectures migrate.
- Buying 100% means every drop in usage becomes pure loss - and Savings Plans have no resale route, unlike Reserved Instances.
- Buying too little is not a loss: uncovered usage is simply billed at on-demand rates. You just did not capture the saving.
A steadier approach is to commit 70-80% of the steady baseline, watch coverage for a month, then decide whether to top up. If the judgement is off, the error is confined to the part you did not commit. The same logic applies in how to buy AWS Reserved Instances without regretting it.
Three limits almost nobody mentions
None of these are prominent on the marketing pages, and all three affect real cost:
- Savings Plans do not reserve capacity. They lower the unit price; they do not guarantee the instance you want will be available. If your scenario needs guaranteed capacity - a launch event, a critical workload, a scarce GPU type - buy an On-Demand Capacity Reservation as well. The good news is that they stack: the reservation secures the capacity, the Savings Plan pays for it at the discounted rate.
- The return window is 7 days, with a dollar cap. Officially, a plan purchased within the last 7 days whose hourly commitment is 100 USD or less can be returned, with any upfront amount refunded. Past that window you ride the plan to term - and unlike a standard Reserved Instance there is no Marketplace to resell it on.
- Closing the account does not stop the billing. The documentation states it plainly: after an account is closed, active Reserved Instances and Savings Plans keep billing until their term ends, and Marketplace subscriptions are not cancelled automatically - they must be terminated manually.
⛔ The third one hits the "spin it up for a project, then close the account" habit hardest. Before closing anything, check for unexpired commitments - otherwise you keep paying for a project that no longer exists, at the committed amount, with no reduction for the usage you stopped using.
When to choose Reserved Instances instead
Match your situation to the answer:
| Your situation | Choose |
|---|---|
| You need guaranteed capacity | Reserved Instance (or a separate On-Demand Capacity Reservation) |
| The instance family is fixed and you want the deepest discount | EC2 Instance Savings Plan, or a standard Reserved Instance |
| You want a resale exit route | Standard Reserved Instance (resellable on the RI Marketplace) |
| Usage drifts and you want minimum management | Compute Savings Plan |
| You want both | Mix them: cover the steady part with reservations, let Compute Savings Plans cover the drift |
Note the last row: AWS states both can be active at once - Reserved Instances apply first, Savings Plans cover the remainder. This is not a single-choice question. If you also plan to push the elastic part onto interruptible spare capacity, that is the mixed base pattern in a practical guide to AWS Spot Instances.
FAQ
Can a Savings Plan be shared across accounts?
Yes. Buy it inside AWS Organizations or a consolidated billing family and it applies across all accounts by default. You can also group accounts with cost categories and buy at the group level to control where the benefit lands first, or restrict it to the purchasing account only. For multi-account teams this matters: there is no need to buy a plan per account.
I already own Reserved Instances - can I add Savings Plans?
Yes, they coexist and both apply: Reserved Instances are applied first, then Savings Plans cover what remains. AWS also suggests moving to Savings Plans as reservations expire, since the discount is comparable and the flexibility is greater.
Will I actually get the "up to 72%" from the website?
That is the ceiling AWS publishes, not an expectation you can count on. The real figure depends on usage shape, region, term and payment option, and the official live pricing is authoritative. We see this go wrong often when the ceiling is used as a budgeting input - estimating your saving at 70-80% coverage is far safer than estimating at the ceiling.
Can I return one if I get it wrong?
Only within a narrow window: a plan purchased within the last 7 days with an hourly commitment of 100 USD or less can be returned, with any upfront amount refunded in full. Past that, Savings Plans have no resale route (unlike a standard Reserved Instance). So the point is not "how do I recover from a mistake" but how do I limit risk before buying: right-size, settle the architecture, and start with a one-year No Upfront plan at 70-80%.
Do Savings Plans renew automatically when they expire?
They do not roll over on the same terms indefinitely. Expiry means the discount stops applying and usage returns to on-demand pricing - your bill takes a step up. As with Reserved Instances, put the date in a calendar and decide in advance whether to renew, switch type, or reduce usage through architecture work. Official discounts and what you actually pay are different layers: the channel side is in AWS discounts and reseller pricing, and the mechanism itself in AWS Savings Plans vs Reserved Instances vs Spot.