Savings Plans vs Reserved Instances: which one, and when

Savings Plans and Reserved Instances both work the same way at heart: you promise AWS a level of usage for one or three years, and AWS gives you a discount for the certainty. The discount is real and substantial. The commitment is also real, and you cannot undo it.

Most of the confusion comes from a single question nobody answers clearly up front, so here it is:

Savings Plans do not cover your databases. They cover EC2, Fargate and Lambda. RDS, ElastiCache, OpenSearch and Redshift need Reserved Instances or Reserved Nodes, bought separately.

If you take nothing else from this page, take that. It's the reason teams buy a Compute Savings Plan, feel finished, and then wonder why half the bill is still at on-demand rates.

The three instruments, briefly

Compute Savings Plans. You commit to a dollar amount of compute spend per hour. In exchange you get a discount on EC2 regardless of instance family, size, region, operating system or tenancy — and it covers Fargate and Lambda too. Maximum flexibility, slightly lower discount rate.

EC2 Instance Savings Plans. Same hourly-dollar commitment, but locked to a specific instance family in a specific region. You can move between sizes and operating systems inside that family. Higher discount, much less flexibility.

Reserved Instances. The older mechanism, and still the only option for RDS, ElastiCache, OpenSearch and Redshift. You reserve a specific configuration. Standard RIs give the deepest discount and can't be changed. Convertible RIs give a smaller discount but can be exchanged for a different configuration later.

Discount rates vary by service, term, region and payment option, and AWS changes them. Treat any specific percentage you read anywhere — including AWS's own headline numbers, which assume the most aggressive three-year all-upfront case — as an upper bound, and check the actual rate in the console for your own usage before committing.

Which one to buy

For most small and mid-sized teams the answer is genuinely simple.

Start with a one-year, no-upfront Compute Savings Plan. Here's the reasoning:

• One year, not three. A three-year term is a bet that your architecture will look roughly the same in 2029. For an established enterprise that's often true. For a company that might migrate to containers, adopt Graviton, get acquired, or pivot, it usually isn't. The extra discount on a three-year term is not worth being locked to instance spend you've outgrown.
• No upfront, not all upfront. Paying everything up front buys you a modest additional discount in exchange for a large cash outlay. If you're a startup, your cash is worth more than that spread. Take the no-upfront option and keep the money.
• Compute, not EC2 Instance. The flexibility to change instance families is worth the lower rate, because the single most valuable optimization available to you — moving to Graviton — changes instance family. An EC2 Instance Savings Plan locked to m5 actively penalises you for improving your architecture.

Then, separately, buy Reserved Instances for your databases once those are right-sized. RDS and ElastiCache reservations are usually the second-biggest commitment win and they're routinely forgotten.

Size it to the floor, never to the peak

This is where real money gets lost.

A Savings Plan commits you to spending a certain amount per hour, whether or not you use it. If you commit to $10/hour and your actual compute usage drops to $6/hour, you pay for $10. The unused portion is simply gone.

So the correct method is:

1. Look at your hourly compute spend over the last 60 to 90 days. Ninety is better.
2. Find the minimum — the quietest hour of the quietest weekend.
3. Commit to somewhere at or slightly below that floor.

You are not trying to cover all of your usage. You're trying to cover the part that is definitely, boringly always there. Everything above the floor stays on demand, at full price, and that's correct — on-demand spend you weren't obliged to make is much cheaper than a commitment you can't fill.

If you want more coverage later, buy a second, smaller plan. Commitments stack. There is no penalty for laddering into them gradually, and it's a far better failure mode than over-committing on day one.

Coverage and utilization are not the same thing

These two metrics appear next to each other in Cost Explorer and get confused constantly.

• Utilization is how much of what you committed to is actually being used. This should be at or very near 100%. Anything less means you're paying for a commitment you aren't consuming — pure waste.
• Coverage is what share of your eligible usage is covered by commitments. This should not be 100%. Somewhere in the region of 60–80% is a healthy target for a growing company, because it leaves headroom for your architecture to change.

Chasing 100% coverage is how teams end up with 70% utilization, which costs more than having bought nothing.

Do this last, not first

Commitments are the final step of a cost programme, not the first, and the ordering matters more than anything else on this page.

If you buy a Savings Plan before right-sizing, you commit to your current wasteful usage. The over-provisioned instances, the staging environment that runs all night, the cache cluster that's two sizes too big — you lock all of it in, at a discount, for one to three years. The invoice goes down, which feels like progress, and the underlying waste becomes permanent and paid-for.

Work through the cost optimization checklist first. Delete what's idle, switch off what doesn't need to run, right-size what's left. Then measure your floor and commit to it. The commitment will be smaller and it will be correct.

The things that catch people out

• Savings Plans apply automatically, in AWS's chosen order. They're applied to whichever eligible usage yields the biggest discount first. You don't control allocation, and across an Organization they apply account-by-account in a way that can surprise a team expecting their own account to benefit from their own purchase.
• Regional RIs versus zonal RIs. Zonal RIs reserve capacity in a specific Availability Zone but lose regional flexibility. Unless you specifically need the capacity reservation, regional is almost always the right choice.
• RDS reservations are per instance class and per engine. Switching from MySQL to Postgres, or resizing the instance, can strand a reservation.
• Commitments expire quietly. A one-year plan ends on its anniversary and your bill jumps. Put the expiry date in a shared calendar the day you buy it — this catches out more teams than it should.
• Review coverage monthly. Usage drifts, architectures change, and a commitment sized for last year's stack slowly stops fitting.

A reasonable default

If you want a single starting position for a company spending somewhere in the low tens of thousands a month on AWS, and you've already done the right-sizing work:

| Decision | Default | | --- | --- | | Term | 1 year | | Payment | No upfront | | Type | Compute Savings Plan | | Size | At or just under your 90-day hourly floor | | Coverage target | 60–80%, not 100% | | Databases | Separate RDS / ElastiCache reservations | | Review | Monthly, with expiry dates in a calendar |

That combination gives up a few percentage points of theoretical discount in exchange for not being locked into a decision you'll regret. For a company whose architecture is still moving, that's a good trade.

Deeper discounts are available and they're worth taking — later, once your usage is genuinely stable and you can predict next year's baseline with a straight face.