Reserved Instances vs Savings Plans - Which AWS Commitment to Buy

Savings Plans and Reserved Instances both trade a one or three year commitment for a lower rate than on-demand, but Savings Plans apply the discount flexibly across instance families, sizes, and regions, while Reserved Instances lock the discount to a specific configuration. For most teams, a Compute Savings Plan is the better default because it keeps the discount even when your fleet changes. Reserved Instances still win in two cases: RDS, ElastiCache, Redshift, and OpenSearch, which Savings Plans do not cover, and when you want to resell an unused commitment on the Reserved Instance Marketplace.

Below are the questions AWS teams actually search when they are about to commit real money, answered in the order that helps you decide.

What is the difference between Reserved Instances and Savings Plans?

A Reserved Instance is a billing discount tied to a specific instance family, region, and often size, in exchange for a one or three year commitment. A Savings Plan is a commitment to a steady dollars-per-hour of compute spend, and AWS applies the discount automatically to whatever eligible usage matches, regardless of family or region. The practical difference is flexibility: if you move from one instance type to another, a Compute Savings Plan follows you, while a Standard Reserved Instance can end up discounting capacity you no longer run.

Both deliver similar headline discounts, up to around 72 percent versus on-demand at the three year, all-upfront end. The choice is rarely about the percentage. It is about how much your architecture will change over the commitment term and whether the services you want to cover are eligible.

When should you use a Savings Plan?

Use a Savings Plan when your compute footprint is steady in dollars but likely to shift in shape, which describes most growing teams. A Compute Savings Plan covers EC2, Fargate, and Lambda across any region and family, so you commit to a baseline spend and stop worrying about which instance type runs underneath. That flexibility is why AWS itself now steers most customers to Compute Savings Plans as the default commitment.

There is also an EC2 Instance Savings Plan, which offers a slightly deeper discount than the Compute plan but locks you to one instance family in one region. It sits between a Compute Savings Plan and a Reserved Instance: more discount than Compute, less flexibility. Reach for it only when you are confident a specific family in a specific region is here to stay for the whole term.

When are Reserved Instances still the better choice?

Reserved Instances are still the right tool for the services Savings Plans do not touch. If you want committed-use discounts on RDS, ElastiCache, Redshift, or OpenSearch, Reserved Instances (or reserved nodes) are the only option, since Savings Plans cover compute only. For a database-heavy workload, that alone decides it.

The other case is optionality. Standard Reserved Instances can be listed on the AWS Reserved Instance Marketplace and sold if your needs change, which gives you an exit a Savings Plan does not have. Convertible Reserved Instances let you exchange for a different configuration mid-term. If you value the ability to unwind or reshape a commitment, Reserved Instances offer levers a Savings Plan cannot.

How much can you save with Savings Plans or Reserved Instances?

Both can cut the covered spend by up to roughly 72 percent against on-demand at the deepest commitment, a three year term paid all upfront. Shorter terms and no-upfront payment reduce the discount, typically landing in the 20 to 40 percent range for a one year, no-upfront commitment, which is where most teams start because it limits risk. The real number depends on the term, the payment option, and how much of your usage the commitment actually covers.

The trap is coverage without utilization. A commitment only saves money on usage that runs, so a Savings Plan sized to a peak you rarely hit, or a Reserved Instance for a family you stopped using, quietly wastes the very money it was meant to save. This is why commitment coverage and utilization belong on the same dashboard as the rest of your spend, which is what AWS cost optimization in Costanalyst surfaces: where a commitment would cut on-demand spend, and where an existing one is going unused.

Should you rightsize before buying a commitment?

Yes, and the order matters more than people expect. Rightsize first, then commit. If you buy a one year Savings Plan or Reserved Instance against your current oversized fleet, you lock in a discount on capacity you should have shrunk, and you spend the next year paying a reduced rate for waste. Validate real demand, cut the idle and oversized resources, and only then size the commitment to the leaner baseline.

A clean sequence is: remove idle resources, rightsize on real p95 utilization, establish the stable baseline that remains, and cover that baseline with a Compute Savings Plan. Do it in that order and every dollar you commit is a dollar you were genuinely going to spend. Do it backwards and the commitment cements the waste in place for the length of the term.

Can you combine Savings Plans and Reserved Instances?

Yes, and many mature AWS accounts run both. AWS applies Reserved Instance discounts first, then Savings Plans to the remaining eligible usage, so they layer rather than conflict. A common pattern is Reserved Instances for the database tier that Savings Plans cannot cover, plus a Compute Savings Plan for the flexible EC2, Fargate, and Lambda baseline. The two together can push discount coverage higher than either alone.

The risk in combining them is double-counting. If you size a Savings Plan without accounting for the usage your Reserved Instances already cover, you can over-commit and end up with an underutilized plan. Model the two together against one view of usage, not in separate spreadsheets, so the combined commitment matches actual eligible spend.

How do commitments show up in your accounting?

An all-upfront or partial-upfront commitment is a prepaid expense: you pay now for capacity you consume over the term, so finance records it as a prepaid asset and amortizes it across the months of the commitment rather than expensing it all in month one. A no-upfront commitment is closer to a recurring charge. Either way, the reporting should match the economic reality rather than the cash timing, which matters when you turn the ledger into board-ready financial statements at quarter close.

This is also why engineering and finance need one shared view of commitments. Engineering decides what to run; finance carries the commitment on the books for up to three years. When both look at the same coverage, utilization, and amortization picture, the commitment is a deliberate financial decision rather than a surprise line item someone has to explain later.

The bottom line

Default to a Compute Savings Plan for flexible EC2, Fargate, and Lambda spend, because it keeps the discount as your fleet evolves. Use Reserved Instances for the database services Savings Plans cannot cover and when you want the option to resell or exchange. Rightsize before you commit, size the commitment to the baseline that actually remains, and watch utilization so the discount lands on usage that runs. If you want to see where a commitment would cut spend and where an existing one is wasted, the best cloud cost management tools put coverage, utilization, and the rest of your bill in one place.