Glossary
Savings Plans and Reserved Instances
Also: RI · Commitments · Reserved Capacity
Two ways to pay considerably less than on-demand pricing in exchange for a usage commitment over one or three years.
The mechanism is the same everywhere: a discount in exchange for commitment. You promise AWS to pay for a certain amount over one or three years and receive between roughly 20 and 70 per cent off, depending on term and upfront payment. Used or not, you pay.
The terminology regularly gets muddled. Savings Plans exist only for compute, so EC2, Fargate and Lambda. On RDS commitments are called Reserved Instances, on DynamoDB Reserved Capacity, on ElastiCache and OpenSearch Reserved Nodes. Anyone saying "we have Savings Plans" often means compute only and has left the databases uncovered.
Compute Savings Plans are more flexible than EC2 Instance Savings Plans: they apply across instance types, regions and even across EC2, Fargate and Lambda, at a slightly lower discount. In an environment that is still moving, that flexibility is worth more than the last few percentage points.
The most important rule is the sequence: commitments come last. Committing to an uncleaned infrastructure locks in the waste and makes every later optimization economically pointless, because a downsized database saves nothing once the old size is already paid for.
The second rule concerns the level. Sensible is 70 to 80 per cent of the proven baseline, never 100 per cent. The rest stays flexible. An oversized commitment is the one cost measure that cannot be undone.
And the third concerns the term. Three years bring a noticeably larger discount and are a bet that nothing substantial changes in the architecture. After a rebuild, before a migration or in a growing product, one year is the more honest assumption.
How you notice it
- Commitments exist, but nobody cleaned up beforehand.
- The databases run without reservations while compute has a Savings Plan.
- Coverage is close to 100 per cent of usage.
- The term is three years although the architecture is currently changing.
Not to be confused with
- Spot instances
- A discount for interruptibility rather than for commitment. No contract, but capacity can be reclaimed with two minutes notice. For batch workloads often the cheaper choice.
- Rightsizing
- Changes how much capacity is needed. Commitments only change the price for it. Both, in that order, never the other way round.
- Reserved Instances
- The older mechanism, and still the only one for RDS, ElastiCache and similar services. Less flexible than Savings Plans, but without alternative there.
When it fits
- The baseline is stable and proven over at least three months.
- Clean-up, data volumes and rightsizing are done.
- The architecture of the affected components is not up for debate.
When it does not
- As the first step of a cost reduction. That is the most common and most expensive mistake.
- On load peaks. You commit the baseline, not the maximum.
- Before or during a migration, as long as the target architecture is unsettled.
- For three years in a product that is still changing significantly.
How to approach it
- Determine the baselineRead the permanently occupied capacity over at least three months from the Cost and Usage Report, after the clean-up. Not the average counts but the level that is never undercut.
- Commit to 70 to 80 per cent of itThe remainder stays at full price and therefore flexible. That reserve is the price for not being punished by a later architectural change.
- Cover all services, not just computeReserved Instances for the databases, Reserved Capacity for DynamoDB, a Compute Savings Plan for compute. Buying only the last one leaves the larger part on the table.
- Choose one year when in doubtThe extra discount of the three-year term is a bet on stability. After a rebuild that bet is rarely justified.
- Measure success amortizedAfter the purchase the affected line drops to a fraction in the unblended view. Only the amortized view shows the real running cost.
Frequently asked
Savings Plan or Reserved Instance?
For compute almost always the Compute Savings Plan: it applies across instance types, regions and across EC2, Fargate and Lambda. For RDS, ElastiCache, OpenSearch and DynamoDB there are no Savings Plans, so Reserved Instances or Reserved Capacity are the only route.
One year or three years?
Three years bring a noticeably larger discount and are a bet that nothing substantial changes in the architecture. In an environment being rebuilt or migrated, one year is the more honest assumption. In a platform that has been stable for years, three years are defensible.
What happens if we do not use the committed amount?
It is charged anyway. That is exactly why the ceiling of 70 to 80 per cent of the proven baseline applies. Unused commitments are the only case in which a cost measure increases cost.
Can a commitment be undone?
No. Reserved Instances can be modified within narrow limits or sold on the marketplace, Savings Plans cannot. That is why they belong at the end of the sequence and not at the beginning.