AWS Savings Plans vs Reserved Instances is not a philosophy debate. It is a commitment instrument decision: what you are willing to lock, for how long, against which usage shape. We see teams buy RIs on a family they are about to abandon for Graviton, or buy Compute Savings Plans so broad that finance thinks they are "covered" while a second account's untagged SageMaker bill sits at on-demand.
This is transactional FinOps. CFOs feel it. It is not the paused generic "FinOps thought leadership" cluster. It is the 2-week audit output: a coverage number, a waste number, and a buy/no-buy.
What Each Instrument Actually Locks
AWS documents both in the Savings Plans user guide. The engineering translation:
| Instrument | Locks | Breaks when |
|---|---|---|
| Standard RI (EC2) | Instance family, size flexibility varies, region | You change family or leave the region |
| Convertible RI | More exchange flexibility, usually weaker discount | You treat it like cash and never exchange |
| Compute Savings Plan | Compute $ / hour across EC2, Fargate, Lambda | Your dollars of compute drop (migration off AWS, big reserved elsewhere) |
| EC2 Instance Savings Plan | Family + region, like a friendlier RI | You change family |
If the roadmap says "Fargate and Lambda will eat EC2," Compute Savings Plans usually win. If you run a stable fleet of one family in one region for three years, a well-sized RI or EC2 Instance SP can beat a fluffy Compute SP that looks diversified on a slide.
The Coverage Math We Trust
Cost Explorer "recommendations" assume last-period usage repeats. Production does not. We rebuild the recommendation from:
- Stable baseline — p20 of hourly compute spend over a period long enough to include a release freeze and a spike, not just the last 7 days.
- Known decrements — decommission dates, Graviton migrations already on the board, account moves.
- Known increments — a launch that is funded, not a hope.
Then we size the commitment to ~60–80% of that adjusted baseline, not 100% of last month. The remainder stays on-demand or Spot (see our Spot cost strategy for interruptible work). Over-commitment is a second bill: you pay for hours you no longer run.
def commit_usd_per_hour(hourly: list[float], planned_drop: float) -> float:
"""Size a Savings Plan to a conservative baseline, not the peak."""
adj = sorted(max(0.0, h - planned_drop) for h in hourly)
p20 = adj[max(0, int(len(adj) * 0.20) - 1)]
return round(p20 * 0.7, 4) # 70% of p20; rest on-demand
The 0.7 factor is a starting heuristic we replace with the client's risk tolerance. The point is: do not commit to the mean.
Flexibility Traps
- Account scope. A Savings Plan in the management account can cover member accounts. An RI bought in a sandbox account covers almost nothing useful. Organizations structure first — same conversation as multi-account cost allocation tagging.
- Savings Plans that "cover" idle. Coverage % looks healthy while EBS, NAT, and data transfer dominate. Compute commitments do not fix those. Do gp3, NAT, and transfer work in parallel or the CFO will think the SP "didn't work."
- Convertible RI theater. If nobody owns exchanges, convertibles are just worse Standard RIs. Assign an owner or do not buy them.
- 3-year vs 1-year. Three-year money is cheap until a platform rewrite. We default 1-year unless the fleet has been stable across a prior year and the architecture owner signs the same tenure.
How We Present the Scorecard
A buy recommendation without a kill criterion is how zombie commitments happen. Every scorecard includes:
- Current on-demand equivalent vs committed
- Estimated hourly unused commitment (the waste line)
- Architecture events in the term (Graviton, region, compute type)
- Owner of quarterly coverage review
We are an AWS-specialist engineering shop, not a billing-resale broker. The deliverable is the model and the Terraform/Org plumbing so coverage is visible per team, not a spreadsheet in finance's inbox.
A 2-week AWS cost audit produces the scorecard and the buy/no-buy → rutagon.com/contact · 907-841-8407 · contact@rutagon.com.
Hourly Shape Matters
A fleet that is 0 for 12 hours (batch) and spiked for 12 hours will look "50% coverage" while still overpaying on-demand at the peak and wasting commitment at the trough. We plot hourly. Compute Savings Plans still help if the dollar floor is real; they do not flatten a spiky shape into efficiency by themselves. Shift batch to Spot or schedule it.
Finance wants a single coverage %. We give coverage % plus wasted $/hour plus a one-page architecture calendar. If Graviton is in 90 days, we do not sell a 3-year family-locked RI on Intel.
Organization Sharing
Turn on sharing in the management account only after tags exist so you can allocate commitment benefit. Unallocated commitment is how one team's savings become another team's mystery.
AWS Savings Plans vs Reserved Instances when the hourly shape is ugly
AWS Savings Plans vs Reserved Instances is not a religion. Compute Savings Plans buy a $/hour floor across families and regions (with the flexibility you actually configured). Standard RIs buy a specific instance family in a region and punish you if you migrate to Graviton next quarter. AWS documents Savings Plans. We plot hourly On-Demand before we sell a 3-year lock.
A batch fleet that is 0 for 12 hours and spiked for 12 will show “50% coverage” while wasting commitment in the trough and paying On-Demand at the peak. Shift batch to Spot or schedule it. Coverage % without wasted $/hour is a vanity metric.
Org sharing of commitment without cost-allocation tags is how one team’s savings become another team’s mystery. Turn on sharing after tags exist. If a family-locked RI is already purchased, we do not stack a overlapping Compute SP blindly — we model double-commit.
Finance gets a one-page scorecard: coverage, waste, upcoming architecture (Graviton, Aurora, Fargate) in 90 days, and a buy/no-buy. No “always buy SP.”
Frequently Asked Questions
Should startups buy Reserved Instances at all?
Usually not until usage is stable and tagged. A Compute Savings Plan at a conservative hourly rate is the more common first instrument. RIs show up when a fleet is boring on purpose.
Do Savings Plans apply to RDS or OpenSearch?
Compute Savings Plans cover EC2, Fargate, and Lambda. RDS and other engines have their own reservation products. Mixing those in one "we bought Savings Plans" sentence is how coverage reports lie.
Can we sell unused RIs on the Marketplace to fix a bad buy?
Sometimes, with friction and pricing risk. It is a recovery tactic, not a strategy. Size correctly up front.
How often should we change the commitment?
Review coverage quarterly. Change the rate when the architecture changes, not because a single month was high. Chasing monthly peaks is how you over-commit.
Is this the same as a FinOps tool subscription?
No. Tools visualize. Someone still has to choose an hourly commitment against a roadmap. That is an engineering decision with a finance signature.