Savings Plans vs Reserved Instances: which to buy on AWS

Savings Plans and Reserved Instances are the two ways AWS trades a lower rate for a commitment of one or three years. A Savings Plan commits to an amount of spend per hour; a Reserved Instance commits to an instance configuration. For EC2, AWS's own documentation settles the general question in one line, and the rest of this guide is about the details that decide the bill:

• What each one covers: EC2, Fargate and Lambda, but also RDS, ElastiCache, OpenSearch Service, Redshift, DynamoDB and SageMaker AI, each with its own commitment.
• What each one costs: one m7g.large and one RDS db.m7g.large in Paris, at every term and payment option the AWS Price List sells.
• How the discounts apply, how to read coverage and utilization, how to size a commitment from Cost Explorer's recommendations, and the traps.

The short answer

We recommend Savings Plans over Reserved Instances.

The reason is flexibility, not price. "With Reserved Instances, you make a commitment to a specific instance configuration, whereas with Savings Plans, you have the flexibility to use the instance configurations that best meet your needs". On price, the pairs AWS calls similar come out the same: on an m7g.large in Paris, an EC2 Instance Savings Plan and a Standard Reserved Instance differ by less than a hundredth of a cent an hour at every term and payment option, and so do a Compute Savings Plan and a Convertible Reserved Instance, computed (What each commitment costs).

Reserved Instances still matter outside EC2: RDS, ElastiCache, OpenSearch Service, Redshift, MemoryDB and DynamoDB all have reservations of their own, and for some of them no Savings Plan applies.

In short: For EC2, Fargate and Lambda, buy Savings Plans: at the same rate as the matching Reserved Instance, they follow more changes; reservations remain the tool for the services Savings Plans do not cover.

What each commitment is

Savings Plans: an amount per hour

Savings Plans "provide savings beyond On-Demand rates in exchange for a commitment of using a specified amount of compute power (measured per hour) for a one or three year period". The commitment is in dollars per hour, not in instances: "you can reduce your bill by committing to a consistent amount of compute usage (measured in $/hour), instead of specific instance configurations". AWS sells four types:

Database Savings Plans are sold "over a 1-year term", "with no upfront payment"; the Paris price list has one plan, "1 year No Upfront Database Savings Plan". Two limits hold for every type: "The terms of the commitment can't be changed after purchase", and "Savings Plans doesn't provide capacity reservations".

Reserved Instances: a configuration

Reserved Instances "are not physical instances, but rather a billing discount applied to the use of On-Demand Instances in your account", and those instances "must match certain attributes, such as instance type and Region". An EC2 Reserved Instance is priced on four of them: instance type, Region, tenancy and platform. It comes in two offering classes:

• Standard: "These provide the most significant discount, but can only be modified. Standard Reserved Instances can't be exchanged."
• Convertible: "These provide a lower discount than Standard Reserved Instances, but can be exchanged for another Convertible Reserved Instance with different instance attributes."

Neither renews: "when they expire, you can continue using the EC2 instance without interruption, but you are charged On-Demand rates" (Reserved Instances overview).

Beyond EC2: the other services' reservations

Cost Explorer gives reservation recommendations for "Amazon EC2, Amazon RDS, ElastiCache, OpenSearch Service, Amazon Redshift, Amazon MemoryDB, and Amazon DynamoDB", reservations that provide "a discounted hourly rate (up to 75%)". Each service words its reservation its own way:

The same rule runs through all of them: a reservation is owed for its whole term. Redshift says it most plainly, "You are charged for reserved nodes regardless of usage", and OpenSearch Service adds that "upfront payments are nonrefundable".

In short: A Savings Plan commits to dollars per hour and lets the usage change shape; a reservation commits to one configuration of one service, and only Redshift among the services above has no Savings Plan to fall back on.

Flexibility: what follows a change

AWS's comparison table, for EC2:

"No" for a Convertible Reserved Instance means "not automatically": "Convertible RIs can be changed across instance family, instance size, OS, and tenancy, but requires you to manually perform exchanges". An exchange keeps the Region and the end date, and the new reservation must be "of an equal or higher value". A Savings Plan needs none of that: it gives "the flexibility to use the compute option that best suits your needs at low prices, without having to perform exchanges or modifications".

Flexibility has a price when the usage moves. One m7i.large committed for a year, No Upfront, then moved to Graviton, an m7g.large, for the rest of the year: the EC2 Instance Savings Plan stays with the m7i family, while the Compute Savings Plan follows the move (why the move pays, in the Graviton article).

A · EC2 Instance Savings Plan

The plan stays with m7i Illustrative

Line	A month
Compute	$126.12
Plan for 1 m7i.large, billed, unused730 h × $0.07756 /h	$56.62
1 × m7g.large, On-Demand730 h × $0.0952 /h	$69.50
A month, computed	$126.12

B · Compute Savings Plan

The plan follows the move Illustrative

Line	A month
Compute
Plan for 1 m7i.large, now covering the m7g.large730 h × $0.08919 /h	$65.11
A month, computed	$65.11

Compute Savings Plan costs $61.01 a month less than EC2 Instance Savings Plan (48.4% less), computed.

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published November 7, 2026, fetched November 9, 2026. Illustrative configuration, not a client case.

The Compute Savings Plan's commitment covers the m7g.large at its own plan rate ($52.71 of the month) and leaves $12.40 unused, computed; the EC2 Instance Savings Plan is paid in full and the m7g.large runs at $69.50 On-Demand on top of it.

In short: Pay for the EC2 Instance Savings Plan's deeper rate only for a family and a Region you will keep for the whole term; anything that may move to Graviton, another Region, Fargate or Lambda belongs under a Compute Savings Plan.

Terms and payment options

Both commitments last one or three years, and AWS defines them to the second: "A year is defined as 365 days (31,536,000 seconds)" and "Three years is defined as 1,095 days (94,608,000 seconds)". Each is sold three ways (Reserved Instances overview):

• All Upfront: "Full payment is made at the start of the term, with no other costs or additional hourly charges incurred for the remainder of the term, regardless of hours used."
• Partial Upfront: "A portion of the cost must be paid upfront and the remaining hours in the term are billed at a discounted hourly rate, regardless of whether the Reserved Instance is being used."
• No Upfront: "You are billed a discounted hourly rate for every hour within the term, regardless of whether the Reserved Instance is being used."

"Generally speaking, you can save more money making a higher upfront payment for Reserved Instances." A Savings Plan is paid the same three ways (What are Savings Plans?), and its rates "do not change based on the amount of hourly commitment".

What each commitment costs: one m7g.large in Paris

An m7g.large costs $0.0952 per hour On-Demand in Paris, $69.50 a month. No Upfront, each Savings Plan sits on the same rung as the Reserved Instance AWS pairs it with:

With the upfront options, a reservation has two prices, a one-time fee and an hourly rate, while a Savings Plan has one rate per instance hour. To compare them, this guide spreads the fee over the hours of the term (8,760 or 26,280) and adds it to the hourly rate:

Three things show. The term matters more than the payment: three years No Upfront takes more off than one year All Upfront for every commitment. Paying upfront adds a few points, not tens. And the pairs match within a hundredth of a cent an hour, the rounding of the upfront fee aside: the largest gap is $0.000053 an hour between an EC2 Instance Savings Plan and a Standard Reserved Instance, $0.000074 between a Compute Savings Plan and a Convertible one, computed. AWS's "up to 72%" is a ceiling: the deepest commitment here, three years All Upfront on an EC2 Instance Savings Plan, costs 60.3% less than On-Demand, computed.

In short: On an m7g.large in Paris, the term moves the rate more than the payment option, and a Savings Plan costs what its matching Reserved Instance costs at every term and payment.

How AWS applies the discounts, in order

When several commitments could cover the same hour, AWS applies them in a fixed order (Understanding how Savings Plans apply to your usage):

1. 1

   Reserved Instances

   "Savings Plans apply to your usage after the Amazon EC2 Reserved Instances (RI) are applied." Usage a Reserved Instance covers is out of reach of every plan.

2. 2

   EC2 Instance Savings Plans

   They are "applied before Compute Savings Plans because Compute Savings Plans have broader applicability".

3. 3

   Compute Savings Plans

   Within each plan, to "your highest savings percentage first", then, at equal percentages, to the usage with the lowest Savings Plans rate.

4. 4

   On-Demand

   "Any remaining usage is charged at the On-Demand rates."

Two more rules decide who benefits. In an organization, "Savings Plans are applied first to the owner account's usage, and then to other accounts' usage. This occurs only if you have sharing enabled." And time does not carry over: "Each hour's commitment can only be used within that hour and cannot be carried over". An hour of low usage is lost, not banked.

In short: Reservations take the usage first, then EC2 Instance Savings Plans, then Compute Savings Plans, each to the highest discount first, hour by hour, with nothing carried over.

Coverage and utilization

Two ratios tell whether a commitment works, and Cost Explorer reports both (Monitoring your Savings Plans):

• Utilization: "the percentage of your Savings Plans commitment that you're using". AWS's example: "if you have a $10/ hour commitment, and your usage billed with Savings Plans rates totals to $9.80 for the hour, your utilization for that hour is 98 percent."
• Coverage: "what percentage of your applicable AWS usage costs are being covered by your Savings Plans".

Utilization is the risk: an unused hour of commitment is paid. Coverage is the opportunity: an uncovered hour is paid On-Demand. The FinOps Foundation's Rate Optimization capability asks the same question from the other side: "Organizations should evaluate the level of consistently-running resources coverable by a certain discount."

The break-even: how many hours a commitment needs

A No Upfront commitment on one m7g.large costs less than On-Demand only if the instance runs more than this share of the hours, computed from the Paris rates:

Below that line, On-Demand would have been cheaper. That is why a commitment covers the floor of the usage, the instances that run every hour, and not its average.

A commitment set too high

A fleet of 10 m7g.large gets a one-year No Upfront EC2 Instance Savings Plan sized for all of them, a commitment of $0.62800 an hour. Then rightsizing brings the fleet down to 6. The commitment does not shrink:

A · No plan, On-Demand

Six instances, no plan Illustrative

Line	A month
Compute
6 × m7g.large, On-Demand4,380 h × $0.0952 /h	$416.98
A month, computed	$416.98

B · A plan for ten

Six instances, a plan sized for ten Illustrative

Line	A month
Compute
Plan for 10 m7g.large: 6 covered, 4 unused7,300 h × $0.0628 /h	$458.44
A month, computed	$458.44

A plan for ten costs $41.46 a month more than no plan, On-Demand (9.9% more), computed.

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published November 7, 2026, fetched November 9, 2026. Illustrative configuration, not a client case.

Utilization falls to 60.0%, below the 66.0% break-even, and $183.38 a month of commitment buys nothing, computed. The order of the work follows from it: rightsize and clean up first, commit last (the cost levers of the EC2 article, in that order).

In short: Commit to the usage that runs every hour once rightsized, and watch utilization: below the break-even, the commitment costs more than the On-Demand it replaced.

How to size a commitment

Cost Explorer does the first pass. For Savings Plans, its recommendations give a "Monthly On-Demand spend", an "Estimated monthly spend" (the recommended commitment "and any usage projected to remain on On-Demand due to hour-to-hour variations in usage") and an "Estimated monthly savings". For reservations, its recommendations are "based on a single account or organization usage of the past seven, 30, or 60 days", and are updated "at least once every 24 hours". Both read the past:

Cost Explorer doesn't forecast your usage or take forecasts into account when recommending reservations.

So the recommendation is a starting point, read in this order:

1. Clean the usage first. A recommendation computed on oversized or idle instances commits to them. Rightsize and move to Graviton before buying (what the move takes off, in the Graviton article).
2. Pick the lookback that matches the future. The past 7, 30 or 60 days: a fleet that just shrank needs the short one, a seasonal one the long one.
3. Model the amount. Purchase Analyzer shows "the impact on savings, coverage, and utilization" of "the recommended purchase amount, targeting a coverage percentage, or entering your own custom amount", and lets you "Compare savings and risk for different commitment amounts".
4. Buy in steps. "As your usage changes, you can sign up for additional Savings Plans" (Savings Plans types): a first plan below the floor, a second one once the first holds.
5. Watch it. Set budgets on utilization and coverage, which AWS offers for Savings Plans (Monitoring your Savings Plans), and read commitments on amortized cost (why, in the Cost Explorer article).

For reservations, Cost Explorer "recommends the smallest size instance in an instance family", so that the purchase is size-flexible, and assumes "that you are renewing any expiring reservations" (Accessing reservation recommendations).

In short: Start from Cost Explorer's recommendation, but only after rightsizing, on the lookback that looks like the coming year, modelled in Purchase Analyzer, bought in steps and watched with budgets.

The traps

• A commitment too high. It is owed every hour of the term (A commitment set too high). A Savings Plan "can't be cancelled during the term", and a Reserved Instance neither: "After you purchase a Reserved Instance, you cannot cancel your purchase" (Reserved Instances overview).
• A short return window. A Savings Plan "with an hourly commitment of $100 or less that has been purchased in the last seven days and in the same calendar month can be returned, provided you haven't reached your return limit" (Returning a purchased Savings Plan). After that, it runs to its end.
• Reserved Instances nothing uses. A Reserved Instance whose instances changed type, Region or platform keeps billing. On Redshift, a resize to another node type leaves the old reservation billed "until their term ends. Meanwhile, the nodes of the new type might be billed at the on-demand rate" (Redshift reserved nodes).
• Plans that never reach the usage. "Savings Plans doesn't apply to spot usage or usage covered by RIs" (Compute Savings Plans and Reserved Instances): a plan bought on top of reservations that already cover the same hours sits unused.
• Counting on the Reserved Instance Marketplace. Only "Amazon EC2 Standard regional and zonal Reserved Instances can be sold"; Convertible ones and other services' reservations cannot. The reservation must have been active "for at least 30 days" with "at least one month remaining", AWS keeps "a service fee of 12 percent of the total upfront price", the seller's bank "must have a US address", and an account can sell "up to $50,000 in Reserved Instances" in its lifetime (Reserved Instance Marketplace).
• An expiry nobody saw. A Reserved Instance does not renew, and the instance goes back to On-Demand.

In short: Every commitment is paid to its end: size it below the floor, keep reservations matched to what runs, and do not plan on reselling one.

Databases: reserved DB instances or a Database Savings Plan

RDS has both. A reserved DB instance is "a billing discount applied to the use of certain on-demand DB instances in your account", tied to Region, engine and class type, size-flexible for most engines, for one or three years; its No Upfront option "is only available as a one-year reservation". A Database Savings Plan follows the database "regardless of engine, instance family, size, deployment option, or AWS Region" (Database Savings Plans pricing). For an RDS for PostgreSQL db.m7g.large Single-AZ in Paris, $142.35 a month On-Demand:

On this class, the reservation goes deeper and the plan travels further: a team that may change engine, move Region or go serverless keeps its rate with the plan, at a few points less. The RDS article shows which Paris classes the plan covers, and which it does not.

In short: For a database that will keep its engine, class type and Region, a reserved DB instance takes more off; the Database Savings Plan buys the freedom to change them, one year at a time.

Which one to buy: a decision tree

1. 1

   Could this usage stop, shrink or move in the coming year?

   Yes Do not commit yet

   A commitment is owed every hour of its term. Rightsize, clean up and plan the move to Graviton first, then commit to the floor that remains.

   No Go to the next question.

2. 2

   Is it Amazon Redshift, or another service no Savings Plan covers?

   Yes Buy that service's reservation

   Reserved nodes or instances are the only commitment there: size them to the nodes that run every hour, of the type you will keep.

   No Go to the next question.

3. 3

   Is it a database: RDS, Aurora, ElastiCache, DynamoDB, OpenSearch Service and the other services of the Database Savings Plans?

   Yes Compare a reservation with a Database Savings Plan

   The reservation takes more off one class type; the plan follows engine, family and Region changes, for one year, No Upfront.

   No Go to the next question.

4. 4

   Is it SageMaker AI usage?

   Yes A SageMaker AI Savings Plan

   Up to 64% off On-Demand, AWS says, across instance families, sizes, Regions and components.

   No Go to the next question.

5. 5

   Will the EC2 usage stay in one instance family and one Region for the whole term?

   Yes An EC2 Instance Savings Plan

   The deepest EC2 rate, the same as a Standard Reserved Instance's, with any size, operating system and tenancy in the family.

   No Go to the last step.

6. 6

   A Compute Savings Plan

   The same rate as a Convertible Reserved Instance, with no exchange to make: it follows EC2 across families and Regions, and covers Fargate and Lambda.

The tree ends on Savings Plans for EC2 for the reason AWS gives. A Standard Reserved Instance costs the same as an EC2 Instance Savings Plan here; what it adds is the Marketplace, with the limits listed in The traps. To practise the whole sequence on your own account, from the recommendation to the utilization budget, see exercise 6 of How to learn FinOps.

Azure and Google Cloud sell the same two kinds of commitment under other names and rules: AWS vs Azure vs Google Cloud.

FAQ

What is the difference between Savings Plans and Reserved Instances?

A Savings Plan commits to an amount of spend per hour, in USD, and applies to whatever eligible usage runs; a Reserved Instance commits to an instance configuration (type, Region, tenancy, platform) and applies only to matching instances (Reserved Instances overview).

Are Savings Plans cheaper than Reserved Instances?

Not on the rates checked here: on an m7g.large in Paris, an EC2 Instance Savings Plan and a Standard Reserved Instance cost the same to a hundredth of a cent an hour at every term and payment, and so do a Compute Savings Plan and a Convertible Reserved Instance, computed (What each commitment costs).

What is a Compute Savings Plan?

The most flexible Savings Plan: up to 66% off On-Demand on EC2 "regardless of instance family", size, Region, operating system or tenancy, and on Fargate and Lambda (Savings Plans types). On an m7g.large in Paris, a one-year No Upfront one costs 24.2% less than On-Demand, computed.

Which applies first, a Reserved Instance or a Savings Plan?

The Reserved Instance. Then EC2 Instance Savings Plans, then Compute Savings Plans, each to the usage with the highest savings percentage first (How AWS applies the discounts).

Can I cancel or sell a Savings Plan or a Reserved Instance?

Neither can be cancelled. A Savings Plan of $100 an hour or less can be returned within seven days of purchase, in the same calendar month; a Standard EC2 Reserved Instance can be sold on the Reserved Instance Marketplace under conditions; a Convertible one can be exchanged, not sold (The traps).

Do Savings Plans cover RDS?

Database Savings Plans do: up to 35% on Aurora, RDS, DynamoDB, ElastiCache and six more database services, for one year, No Upfront. Compute and EC2 Instance Savings Plans do not (Databases).

Do I need help to choose?

For a single workload, the decision tree above is enough. Across many accounts, with reservations and plans already in place, an audit of your commitments and coverage usually finds the hours paid twice or not at all.