AWS cost · Savings Plans
Savings Plans vs reserved instances: which one, and how much
Reserved instances used to be the only way to discount steady compute, and they came with a real cost: you locked yourself to a specific instance type, and if your fleet changed, the reservation stranded. Savings Plans fixed that. Instead of committing to an instance, you commit to a dollar amount of compute per hour, and the discount follows whatever you actually run. Same savings, far less lock-in. The question is no longer “reserve or not” - it is which of these instruments fits the workload.
A Compute Savings Plan cuts up to 66% and applies across any instance family, region, and OS, plus Fargate and Lambda. An EC2 Instance Savings Plan cuts up to 72% but locks to one family in one region. Both beat paying on-demand for steady usage. Commit to your baseline, not your peak, and let spot or on-demand cover the rest.
What are the options, and what do they save?
Three ways to discount steady compute, trading flexibility for depth of discount:
| Instrument | Discount | Flexibility |
|---|---|---|
| Compute Savings Plan | up to 66% | Any family, size, region, OS - plus Fargate and Lambda |
| EC2 Instance Savings Plan | up to 72% | Locked to one instance family in one region |
| Reserved Instance | up to ~72% | Specific instance type; can be sold on the RI marketplace |
Which one should you actually pick?
Start with how much your fleet moves. If you shift instance families, move workloads between regions, or run Fargate and Lambda, a Compute Savings Plan is the safe default - the discount follows you and never strands. If a workload is fixed on a known family and you are confident it stays there, an EC2 Instance Savings Plan gives a few points more. Reserved instances still make sense in one case: you want the option to sell the commitment on the RI marketplace if plans change.
How much should you commit?
Commit to the baseline you always run, never the peak. Over-commit and you pay for compute that is not there. AWS will look at your recent usage and recommend a commitment level - this pulls that recommendation for a 1-year, no-upfront Compute Savings Plan so you can see the suggested hourly commitment and the estimated savings before you buy anything:
# AWS's own Compute Savings Plan recommendation from recent usage
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days THIRTY_DAYSA Savings Plan discounts the steady baseline. It pairs naturally with spot for the interruptible layer and with the older reserved-instance math if you are weighing a specific box.
Want to know how much of your steady compute is still on-demand when it could be discounted? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
What is the difference between Savings Plans and reserved instances?+
Both give a discount for committing to steady usage over 1 or 3 years. A reserved instance commits you to a specific instance type. A Savings Plan commits you to a dollars-per-hour of compute spend instead, and the discount applies automatically to whatever matching usage you run - which is more flexible.
How much do Savings Plans save?+
A Compute Savings Plan saves up to 66% and applies across any instance family, size, region, and OS, plus Fargate and Lambda. An EC2 Instance Savings Plan saves up to 72% but locks you to a single instance family in one region. The extra flexibility of Compute plans costs roughly 5 to 7% in discount.
Compute Savings Plan or EC2 Instance Savings Plan?+
Choose a Compute Savings Plan if your fleet changes - you shift instance families, move between regions, or use Fargate and Lambda. Choose an EC2 Instance Savings Plan for a stable workload on a known family where you want the deepest discount and do not expect to change it.
Are Savings Plans better than reserved instances?+
For most accounts, yes - a Compute Savings Plan gives similar savings with far more flexibility and no instance-type lock-in. Reserved instances still have one edge: they can be sold on the RI marketplace if your needs change, which Savings Plans cannot. For a straightforward commitment, Savings Plans are usually simpler and safer.
What is the catch with a Savings Plan?+
Commitment. You commit to a dollars-per-hour spend for the whole term whether you use it or not. Commit too high and you pay for compute you are not running. The safe approach is to commit to your steady baseline usage, not your peak, and let on-demand or spot cover everything above it.
Should I choose 1-year or 3-year, and how much upfront?+
A 3-year term saves more but locks you in longer, so it fits usage you are confident will still be running. All Upfront gives the biggest discount, No Upfront the smallest but keeps your cash, and Partial sits between. Match the term to how sure you are, and the payment option to your cash flow.
Related cost breakdowns
Are reserved instances worth it? The real math
A steady t2.micro drops from ~$9.78/month on-demand to ~$4.42/month on a 3-year reservation - 55% off, same server. Here is when reserving pays off and when it does not.
Why your AWS bill suddenly jumped (the free tier ran out)
AWS free tier is time-limited: legacy accounts get 12 months, new ones get $200 in credits for 6 months. When it lapses, previously-free resources bill at full rate. Here is how to see it coming.
You cannot cut an AWS bill you cannot read: cost allocation tags
Untagged resources make it impossible to see which team, service, or environment is spending. Cost allocation tags are free and the enabler for every other cut. Here is how to set them up.