Skip to content

AWS Updated 2026-07-04

Afraid of overcommitting? How to size Reserved Instances and Savings Plans without betting the company

How to size AWS Reserved Instances and Savings Plans without overcommitting: measure the real baseline, ladder purchases in tranches, and leave headroom for change.

The fear of overcommitting is legitimate — a Savings Plan is a contractual spend for one or three years, and an oversized one costs you money every hour it sits unused. The answer is not to avoid commitments; it is to commit only to the floor of your usage, buy in small tranches over several quarters instead of one big purchase, and prefer the flexible instruments until your architecture stops moving. Done that way, the realistic worst case is that you saved slightly less than the maximum — not that you are stuck paying for capacity you no longer run.

What you are deciding

You are deciding how much of your compute bill to convert from on-demand rates to committed rates, using which instrument, for how long. The instruments differ mainly in what they lock: a Compute Savings Plan commits a dollars-per-hour spend and follows you across instance families, regions, Fargate, and Lambda. An EC2 Instance Savings Plan locks a family in a region for a deeper discount. Standard Reserved Instances are the most rigid and, for EC2, the only one you can resell on the Reserved Instance Marketplace; Convertible RIs can be exchanged. If you have not yet decided which instrument fits which workload, read the RI vs Savings Plans vs Spot decision guide first — this article assumes you know the instruments and are stuck on how much and when.

The risk you are managing is stranded commitment: you commit to $40/hour of compute, then a migration to containers, a Graviton port, a rightsizing pass, or a lost customer drops your steady usage to $25/hour. Anything above your new floor is paid for and wasted. Sizing is therefore a question about the durability of your baseline, not about the size of the discount.

What to check first

  • Your steady-state floor, not your average. Open Cost Explorer, filter to compute usage, hourly granularity, last 60-90 days. The number that matters is the trough — the spend that is there at 3 a.m. on a Sunday.
  • Known upcoming changes. A rightsizing pass, a Graviton migration, a datacenter exit landing on AWS, a product sunset. Any of these moves the floor within the term.
  • Existing commitments and their expiry dates. Overlapping purchases on top of forgotten active RIs is a classic self-inflicted wound.
  • Current coverage and utilization. If you already own commitments running below roughly 95% utilization, fix that before buying more.
  • Who signs off. A three-year all-upfront purchase is a treasury decision, not a DevOps ticket.

How to verify

Pull AWS’s own recommendations, but with a short lookback and the most conservative options first:

# What AWS recommends for a 1-year, no-upfront Compute Savings Plan
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 SIXTY_DAYS

# How well the commitments you already own are used
aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-07-01

# Coverage: how much eligible usage is still billed on-demand
aws ce get-savings-plans-coverage \
  --time-period Start=2026-06-01,End=2026-07-01

In the console, the same lives under Billing and Cost Management > Savings Plans > Recommendations, with utilization and coverage reports alongside. Treat the recommendation as a ceiling, not a target — it optimizes savings assuming your last 60 days repeat forever. Model your own scenarios in the AWS pricing calculator before committing, and keep the Savings Plans documentation open for the eligibility fine print.

The approach

  1. Commit to the floor only. Take the hourly trough from Cost Explorer and target 60-80% of it for your first purchase. On-demand usage above the commitment is normal and healthy — it is your flexibility budget.
  2. Ladder the purchases. Split the target into three or four tranches bought quarterly. Each tranche expires on a different date, so no single renewal decision ever covers your whole bill, and each purchase is informed by a fresh quarter of data. This is the single most effective de-risking move.
  3. Start with one-year, no-upfront Compute Savings Plans. Least discount, least regret. Move to three-year terms only for the portion of the floor that has survived unchanged through at least two of your own planning cycles.
  4. Reserve the rigid instruments for the truly static. EC2 Instance Savings Plans and Standard RIs belong on workloads whose family and region you would bet on for the full term — and note that RDS, ElastiCache, and OpenSearch have their own RI programs sized the same way.
  5. Subtract known projects before buying. If a rightsizing pass is planned, do it first — see what Compute Optimizer will and will not tell you — because committing to the pre-rightsizing baseline locks in the waste.
  6. Put renewal dates on a calendar with a 30-day lead. Expiry with no decision silently reverts you to on-demand; expiry with a rushed decision reproduces the original overcommitment fear.

Also worth knowing: AWS allows returning a Savings Plan within seven days of purchase, subject to commitment limits — a fat-finger safety net, not a planning tool.

When this is the wrong move

If your monthly compute spend is small, the absolute savings will not repay the analysis and tracking time — set a calendar reminder and revisit at a higher spend. If the workload itself might not exist in a year (a product in validation, a client contract up for renewal), stay on-demand and treat the premium as the price of optionality. And if utilization of what you already own is poor, buying more commitment is just prepaying for more waste.

Common mistakes

  • Sizing from the monthly average instead of the hourly floor, which bakes business-hours peaks into a 24/7 commitment.
  • One giant purchase on a single date, creating a single giant renewal cliff three years later.
  • Buying three-year all-upfront for the last few points of discount on a workload that has existed for six months.
  • Forgetting that Savings Plans apply automatically to the highest-discount usage first — which can make one team’s bill look worse while the account total improves.

Keeping it under control

  • Review utilization and coverage monthly; investigate any commitment under ~95% utilization the month it happens.
  • Re-run the purchase recommendation quarterly, right before each ladder tranche.
  • Keep a one-page register of every commitment: instrument, hourly amount, term, expiry, owner.
  • Gate every new purchase on a check of the project roadmap for baseline-moving work.
  • Alert on coverage dropping sharply too — it usually means usage grew and a tranche opportunity is being missed.

Commitment sizing is not a one-time bet; it is a small recurring discipline that compounds. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.