AWS Savings Plans and Reserved Instances: the complete guide

How AWS commitments work

Every AWS commitment is the same bargain: you promise to pay for a certain amount of usage for one or three years, and AWS charges that usage at a lower rate. What differs is what you commit to. A Savings Plan commits to an amount of spend per hour, measured at the discounted rate, and follows your usage across the resources the plan covers. A reserved instance (or reserved node, or reserved capacity) commits to a specific thing: an instance class in a region, an engine, a number of read units.

Three mechanics matter more than any discount percentage:

• Commitments are evaluated every hour and do not roll over. If you commit to $10 an hour of compute and use $8 in a quiet hour, you pay $10 and the $2 is gone. Usage above the commitment in a busy hour is billed at on-demand rates. A quiet 3 am can never subsidize a busy 10 am.
• Savings Plans apply to the usage with the highest discount first (Savings Plans FAQ). AWS spends your commitment where it saves the most, which is good for the bill and confusing for chargeback: the team that bought the plan is not necessarily the team whose usage consumed it.
• Benefits are shared across the organization by default. A plan or reservation bought in any account applies first to that account's matching usage and then to any other account in the organization, unless sharing is turned off for an account or restricted with the group sharing feature described below. The old buffet analogy holds: the payer account pays for the buffet, every linked account eats from it, and anything beyond the buffet is charged at the counter.

The four Savings Plan families

AWS documents the families in Savings Plans types; the Database family was announced in December 2025 with its own pricing page.

Family	Covers	Flexibility	Maximum discount	Terms and payment
Compute Savings Plans	EC2 (any family, size, region, OS, tenancy), Fargate, Lambda	Highest: follows a workload from one family or region to another, and from EC2 to containers or serverless	Up to 66%	1 or 3 years; all, partial or no upfront
EC2 Instance Savings Plans	One EC2 instance family in one region (any size, OS, tenancy)	Within the family and region only	Up to 72%	1 or 3 years; all, partial or no upfront
SageMaker Savings Plans	SageMaker instance usage (notebooks, training, inference)	Across families, sizes and regions within SageMaker	Up to 64%	1 or 3 years; all, partial or no upfront
Database Savings Plans (December 2025)	Aurora, RDS (all engines), DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS: instances, serverless and throughput, generation 7 and newer	Across engines, instance families, regions and from provisioned to serverless	Up to 35% serverless, 20% provisioned instances, 18% on-demand throughput, 12% provisioned capacity	1 year only, no upfront only

The rule of thumb: the more flexible the plan, the smaller the discount. A Compute Savings Plan is the right default for a baseline that will change shape; an EC2 Instance Savings Plan pays a few more points for a family you know you will keep. Savings Plans never cover storage, data transfer, licences billed separately, or (for Database Savings Plans) anything on generation 6 and older. The Database Savings Plans deep dive covers the eligible engines, the discount tiers and the console purchase flow in detail.

Reserved instances, nodes and capacity

Reservations predate Savings Plans and still win in three situations: when you want a capacity reservation as well as a discount, when a service has no Savings Plan (OpenSearch, Redshift), and when you want to pay up front for a database, since Database Savings Plans are no-upfront only.

• EC2 Standard reserved instances (documentation): up to 72 percent off, tied to a family in a region (regional) or an Availability Zone (zonal, which also reserves capacity). Size-flexible within the family for Linux shared tenancy. Can be modified (AZ, scope, size split) and can be sold on the Reserved Instance Marketplace after 30 days, for a 12 percent fee. Cannot be exchanged for a different family.
• EC2 Convertible reserved instances: up to 66 percent off, exchangeable for a reservation of equal or greater value with a different family, OS or tenancy. Cannot be sold.
• RDS reserved instances (documentation): engine, instance class and region specific, one or three years, all, partial or no upfront. Size-flexible within the family for MySQL, MariaDB, PostgreSQL, Oracle BYOL and Aurora. No marketplace, no exchange. Cannot be combined with a Database Savings Plan on the same usage: the reservation applies first, the plan covers what is left.
• ElastiCache reserved nodes, OpenSearch reserved instances, Redshift reserved nodes: the same shape as RDS reservations, per service. Redshift reservations are the deepest of the set, up to 75 percent for three years.
• DynamoDB reserved capacity (pricing): applies to provisioned-capacity tables only, per region, one or three years, paid as an upfront fee plus a discounted hourly rate; up to 54 percent for one year and 77 percent for three. You pay for the reserved units whether the tables use them or not. Since December 2025 the alternative is a Database Savings Plan, which is shallower (12 percent on provisioned capacity, 18 percent on on-demand throughput) but covers on-demand tables and moves with you. The DynamoDB reserved capacity article covers the purchase and Cost Explorer's recommendations for it.

Savings Plans or reserved instances: how to choose

Situation	Buy	Why
Stable compute baseline that changes shape (new families, Graviton migration, some containers)	Compute Savings Plan	The discount follows the workload; nothing to manage when architecture changes
Stable usage of one EC2 family in one region for years	EC2 Instance Savings Plan, or Standard RI if you may need to resell	A few more points of discount for a commitment you are sure of
You need guaranteed capacity in one Availability Zone	Zonal Standard RI (or On-Demand Capacity Reservation plus a Savings Plan)	Savings Plans never reserve capacity
Databases that will be upgraded, migrated between engines or moved to serverless within the year	Database Savings Plan	Cross-engine, cross-region, provisioned-to-serverless; one year, no upfront
A database you will keep exactly as it is for three years and can pay for up front	RDS reserved instance	Deeper discount and up-front payment options the Savings Plan does not offer
Provisioned DynamoDB tables with steady throughput	DynamoDB reserved capacity	Far deeper than the 12 percent Database Savings Plan rate
OpenSearch, Redshift	Reserved instances / nodes	No Savings Plan exists for these services
Bursty or interruptible capacity above the baseline	Nothing: Spot for interruptible work, on-demand for the rest	A commitment you cannot fill every hour is a liability with a payment schedule

For any specific instance, the AWS instance pricing calculator shows on-demand, every reserved and Savings Plan option and spot side by side at the hours you run it, with the break-even.

Utilization and coverage: the two numbers, and the trap

Utilization is how much of the commitment you used: a $10 an hour plan with $9 of eligible usage is 90 percent utilized. Coverage is how much of your eligible spend a commitment covered: if $70 of a $100 hour of compute was discounted by plans, coverage is 70 percent.

The trap is optimizing coverage. We regularly see accounts at 95 percent coverage and 70 percent utilization, which means 30 percent of the commitment is paid for and unused every hour. Coverage is a vanity metric unless utilization backs it up. Targets that hold up in practice: utilization at 95 to 100 percent on the baseline commitment (anything sustained below 90 percent warrants an audit), and coverage wherever it lands once every commitment is fully used, typically 70 to 85 percent of eligible spend, with the rest deliberately left on on-demand and Spot. The utilization deep dive walks through the hourly mechanics and the four-step audit.

Sizing a commitment you will not regret

1. Pull 13 weeks of hourly eligible spend from Cost Explorer (or the Cost and Usage Report). Not monthly totals: the commitment is applied per hour, so the decision needs the hourly distribution.
2. Commit to the floor, not the average. The 10th percentile of hourly spend is the safe first commitment: it is used in nine hours out of ten. Deliberately leaving 30 to 40 percent on on-demand "as a buffer" is the other common mistake; that is not caution, it is unclaimed discount.
3. Buy in tranches. Several smaller plans with staggered start dates instead of one large one. Expiries then spread across the year, each renewal is a small decision, and a right-sizing programme reduces the next tranche instead of stranding a big one.
4. Start short and no-upfront where history is short. A first Database Savings Plan, a new region, a workload six months old: one year, no upfront. Graduate to three-year, all-upfront on the part of the baseline that has been flat for a year; that is where the last 10 to 15 points of discount live.
5. Use AWS's own tools, then argue with them. Cost Explorer's Savings Plans recommendations size a plan from recent usage; the Purchase Analyzer lets you change the lookback, growth assumption and payment option and see the effect. Both assume the future looks like the past; you know about the migration next quarter and they do not.
6. Align purchases with the right-sizing cycle. Right-size first, commit second. A commitment sized on over-provisioned instances locks the waste in for a year.

Break-even and payment options

A commitment beats on-demand only if the instance runs enough hours. The break-even is the number of hours a month at which the commitment's effective hourly cost (upfront amortized plus any hourly fee) equals the on-demand cost for the same hours. For a typical one-year no-upfront EC2 Instance Savings Plan the break-even sits around 450 to 500 hours a month; a three-year all-upfront reservation needs the instance running essentially all month for three years. Business-hours workloads, at roughly 200 hours a month, rarely earn back any commitment, which is why they belong on schedules, not plans.

Payment options trade cash for discount. All upfront gives the deepest rate, partial upfront a few points less, no upfront the least, but the gap is smaller than most people expect (usually 3 to 7 points) and the no-upfront option keeps the money and the flexibility. Amortization matters for reporting: AWS Budgets and Cost Explorer can show net amortized cost, which spreads an upfront payment evenly across the term, so a team's monthly cost reflects the commitment it uses rather than a spike in the month of purchase. The Budgets article covers the net unblended and net amortized metrics added in April 2025.

Sharing commitments across an organization

By default a commitment bought anywhere in an AWS Organization benefits the whole organization, applied to the highest-discount usage first. That maximizes the discount and breaks accountability: the platform team buys a plan, a data team's cluster consumes it, and the chargeback report shows the wrong team saving money.

Since late 2025, Reserved Instance and Savings Plans group sharing lets you define groups with Cost Categories and choose how benefits flow:

• Prioritized sharing: benefits apply first inside the buying group; whatever is left over spills to the rest of the organization.
• Restricted sharing: benefits stay inside the group. No spillover, even if it goes unused.

Each account belongs to one group; existing commitments are not changed (see discount sharing in the Billing user guide), only where their benefit lands; the setting is in Billing preferences (configured in us-east-1, applied globally) and takes effect for the current month. Prioritized is the right default: it keeps the accountability and only sacrifices the spillover when a group over-buys. Restricted exists for compliance boundaries and grant-funded accounts. The group sharing deep dive covers the setup and the FinOps implications. If you do not use group sharing, the honest alternative for chargeback is to allocate the amortized commitment cost to teams by the usage that consumed it, which is what allocation tools do from the Cost and Usage Report.

Monitoring, alerts and review cadence

• Weekly: utilization. Cost Explorer's Savings Plans utilization and reservation utilization reports, or a utilization budget in AWS Budgets that emails when the 7-day utilization drops below 90 percent. This is the alert that catches a right-sizing or a migration that stranded a commitment.
• Monthly: coverage and expiries. Coverage by account and by group; the expiry calendar for the next 90 days. AWS emails before expiry, and you can queue a Savings Plan purchase for a future date so a renewal is not a manual step on a weekend.
• Quarterly: the purchase decision. Re-run the 13-week analysis, compare with the roadmap, buy the next tranche. Right-size first.

Getting out of a bad commitment

• Savings Plans can be returned within 7 days of purchase, in the same calendar month, if the hourly commitment is $100 or less, up to 10 returns per management account per year, with a full refund of any upfront payment. Beyond that there is no secondary market for Savings Plans; check the sizing before you buy at scale.
• Standard EC2 reserved instances can be sold on the Reserved Instance Marketplace (active for at least 30 days, 12 percent fee) or modified within the family. Convertible reservations can be exchanged for a different configuration of equal or greater value. Database reservations can be neither sold nor exchanged.
• Redirect the benefit instead. Turn on prioritized group sharing, or simply leave org-wide sharing on, so a commitment stranded by one team is consumed by another before it expires.

How TruCost.Cloud tracks commitments

The Commitments module reconciles Savings Plan and reserved instance utilization and coverage to Cost Explorer to the cent, per account and per business unit under your allocation rules, shows the expiry calendar, and sizes the next purchase from hourly usage rather than monthly totals. Amortized commitment cost is allocated to the teams whose usage consumed it, so chargeback reflects reality even without group sharing. See Commitments on the platform page.

Common questions

What is the difference between a Savings Plan and a reserved instance?

A Savings Plan commits to an hourly spend and follows your usage across the resources it covers (families, sizes, regions, and for Compute plans, Fargate and Lambda). A reserved instance commits to a specific instance class in a region or Availability Zone. Reservations can be a few points cheaper and can reserve capacity; Savings Plans need no management when the architecture changes.

What happens if I do not use my full Savings Plan commitment?

You pay the full hourly commitment anyway. Commitments are evaluated every hour and unused amounts do not roll over. That is why utilization, not coverage, is the number to watch.

Can I return or cancel a Savings Plan?

Only within 7 days of purchase, in the same calendar month, if the hourly commitment is $100 or less, and at most 10 returns per management account per year. There is no marketplace for Savings Plans. Standard EC2 reserved instances can be sold on the Reserved Instance Marketplace instead.

What are Database Savings Plans?

Launched in December 2025, they cover Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream and DMS with one commitment, across engines and regions, for generation 7 and newer. Discounts are up to 35 percent on serverless, 20 percent on provisioned instances, 18 percent on on-demand throughput and 12 percent on provisioned capacity. Only a one-year, no-upfront term is offered.

Can I use RDS reserved instances and a Database Savings Plan together?

Not on the same usage. A reservation applies first to the instance it matches; a Database Savings Plan then covers eligible usage that has no reservation. Many organizations keep reservations on their most stable databases and use the plan for everything in flux.

What utilization should I aim for?

95 to 100 percent on the baseline commitment. Sustained utilization below 90 percent means part of the commitment is paid for and unused every hour and warrants an audit. Coverage then lands wherever full utilization puts it, typically 70 to 85 percent of eligible spend.

How do Savings Plans apply across accounts in an organization?

By default a plan bought in any account applies first to that account and then to any account in the organization, on the highest-discount usage first. Reserved Instance and Savings Plans group sharing, added in late 2025, lets you keep benefits inside a Cost Category group (prioritized, with spillover, or restricted, without).

How many hours does an instance need to run for a commitment to pay off?

It depends on the option. A one-year no-upfront EC2 Instance Savings Plan typically breaks even around 450 to 500 hours a month; a three-year all-upfront reservation needs near-continuous use. The instance pricing calculator shows the break-even for any type at your hours.