How Much AWS RI and Savings Plans to Buy — A Strategy That Avoids 100% Commitment

Introduction

Any serious attempt to reduce AWS spend eventually runs into the same decision: how much Reserved Instances (RI) and Savings Plans (SP) should you buy? Looking only at discount rates makes 100% commitment tempting, and in practice that fails most of the time.

The short version: the right question is not “what percentage do I buy” but “how far down is the floor that will not move.” This article derives that principle from AWS’s own mechanics, then works through metric definitions, product selection, purchase cadence, and per-scenario ranges.

Why 100% coverage is the wrong target

The reasons are mechanical, not psychological.

Savings Plans commitments are hourly and do not roll over. Anything you fail to consume in an hour vanishes as pure sunk cost.
Cost Explorer recommendations are computed from historical usage (7, 30, or 60 days) and contain no forecast. Right after a migration or a scale-down, they reflect the old pattern and push you into over-commitment.
Savings Plans cannot be cancelled and have no resale market. The only escape is the return window: hourly commitment of $100/hr or less, within 7 days of purchase, in the same calendar month.
Usage itself moves. Weekend and overnight troughs, Graviton migrations, EC2 to Fargate or Lambda moves, and rightsizing all leave commitments unconsumed.

Interestingly, the official Well-Architected Cost Optimization Pillar is skeptical of fixed coverage targets altogether: do not set a target coverage in your accounts, due to the variability of discount that is possible. What it recommends instead is monitoring potential savings via the Cost Explorer Savings Plans recommendation tool and buying in small increments until estimated savings fall below your required discount rate.

Third-party FinOps vendors, meanwhile, converge on a range of 70-85% of the stable baseline. These two positions do not conflict. They are two phrasings of the same rule: commit only to the floor.

Define the metrics correctly

The most common source of confused arguments is the denominator.

Coverage: the share of eligible on-demand usage covered by commitments. The denominator is eligible on-demand-equivalent spend, not your total AWS bill.
Utilization: the share of purchased commitment actually consumed. Nearly everyone should target 100%; dropping below 80% signals over-commitment.
Effective Savings Rate (ESR): the FinOps Foundation’s headline KPI for rate optimization, defined as ESR = utilization × coverage × discount rate.

The useful framing is that coverage and utilization are input metrics while ESR is the output metric, roughly the ROI. Coverage of 100% with poor utilization produces a mediocre ESR.

The denominator matters in practice. “80% coverage” is not 80% of your AWS bill. S3, EBS, data transfer, and NAT Gateway are not eligible for EC2 RI or Compute Savings Plans, so in an organization weighted toward storage and network, 80% compute coverage moves the total bill far less than it sounds. Track eligible-compute coverage and contribution-to-total-cost as separate numbers.

Eligibility by service

Cost item	Directly coverable by RI/SP	How to handle it
EC2 instance hours	Yes	The core target of RI / EC2 Instance SP / Compute SP
Fargate and Lambda	Compute SP only	Eligible if there is a base load under the variance
EC2 under EKS, ECS, EMR	Yes (the underlying EC2 only)	Cover the minimum resident node floor
EKS service fee	No	Nodes are eligible; the service fee is not
RDS, Aurora, DynamoDB, ElastiCache, OpenSearch	Yes (Database SP or per-service reservations)	Design the stable DB floor separately
EBS	No	Rightsize, move to gp3, delete unused volumes
S3	No	Storage class, lifecycle, Intelligent-Tiering
Data transfer and NAT Gateway	No	Architecture changes, less cross-AZ traffic, CloudFront

Choosing the product

The main options as of 2026:

Product	Max discount	Flexibility	Scope	Key constraints
EC2 Instance SP	Up to 72%	Medium (size, OS, tenancy can change)	EC2 only	Family and region locked
Standard RI	Up to 72%	Low (attributes fixed)	EC2	Not exchangeable, but sellable on the RI Marketplace
Convertible RI	Up to 66%	High (family, OS, tenancy exchangeable)	EC2	Exchange only for equal-or-greater value; not sellable
Compute SP	Up to 66%	Highest (any family/region + Fargate, Lambda)	EC2 / Fargate / Lambda	No capacity reservation, not cancellable
Database SP	Up to 35% (serverless)	High (across engines and regions)	RDS / Aurora / DynamoDB and more	1-year, No Upfront only; cannot overlap RI on the same workload
DB Reserved Instance	Up to 69% (RDS)	Low	RDS / ElastiCache / OpenSearch and more	Fixed configuration, no resale market

The design principle is simple: buy flexibility first, layer deep discounts on later. Make Compute Savings Plans your first layer, then replace only the floor that has been stable for 6-12 months on a single family and region with EC2 Instance SP or Standard RI as a second layer.

Equally important: treat capacity assurance and discounting as separate problems. Savings Plans provide no capacity reservation. Production and failover capacity that must launch in a specific AZ should be secured with Zonal RI or On-Demand Capacity Reservations, with discounts layered on top. Buying a large Zonal RI purely for the discount leaves you brittle against AZ skew and configuration change.

Application order is Zonal RI, then Regional RI, then EC2 Instance SP, then Compute SP. That order makes a tiered strategy work: discount the stable layer deeply with RI or EC2 Instance SP, and catch the variable layer with Compute SP.

Database Savings Plans, announced in late 2025, is the first cross-engine discount covering serverless databases, but its discount is shallower than RI. Use RI for large, stable databases and Database SP for serverless or migration-bound workloads.

Term and payment option

The working rule is: never buy a 3-year term for a workload you have not observed for at least 12 months. The extra discount from a 3-year term is roughly 20 points, which a usage decline of more than 15% over those 36 months erases. If monthly volatility exceeds 25-30%, choose 1 year.

For payment, All Upfront gives the deepest discount if you have the cash and a stable 12-month track record. No Upfront suits high growth, active change, and first purchases. Database SP is No Upfront only.

The FinOps Foundation’s 60/40 strategy (60% of the stable baseload on 3-year terms, 40% on 1-year) is a reasonable hedge, but at lower maturity it is safer to start conservatively at 70% one-year and 30% three-year, then move to 60/40 once you have 12 months of data.

Buy in ladders

Not trying to reach your target coverage in one purchase is the structural defense against over-commitment. AWS’s rolling Savings Plans approach splits the total commitment into several smaller equal commitments purchased on a staggered schedule, for example quarterly. Expiration dates spread out, so each one becomes a decision point to renew, increase, or let lapse. It is the same idea as a CD ladder in personal finance.

A workable cadence:

Weekly review for the first 90 days after a new purchase, then monthly for stable workloads
Quarterly review and annual rebalance for 1-year products such as Database SP
Alerts at 30, 60, and 90 days before expiration

Always run Savings Plans Purchase Analyzer before buying. It lets you model custom amounts and target coverage while comparing cost, coverage, utilization, and savings. It is mandatory for commitments above $100/hr.

One frequent accident: the Compute SP and EC2 Instance SP recommendations are generated from the same usage data and are not meant to be summed and purchased together. Decide which one anchors your strategy, then go to the Analyzer.

Ranges by scenario

These are not official AWS figures. They are practical ranges biased toward avoiding over-commitment. When in doubt, enter at the low end and raise monthly.

Workload	Suggested coverage	Suggested mix	Notes
Steady production (single region and family, little change)	70-90%	Mostly EC2 Instance SP / Standard RI, topped up with Compute SP	Thick floor, worth chasing the deep discount
Steady production with Graviton or Fargate moves likely	60-80%	Mostly Compute SP, Convertible RI if needed	Change risk outranks discount
Production with predictable growth	Start at 50-70% of current	Compute SP first, add RI once stable	Add 5-15 points per quarter
Clear seasonality	35-60%	Compute SP on the off-season floor only	Buy the trough, not the peak
Bursty, Auto Scaling driven	15-35%	Only ASG min and the resident EKS node floor	Let on-demand chase the peaks
dev/test with overnight shutdown	0-20%	Only 24x7 CI runners and bastions	Commitments burn while instances are stopped
Short-lived environments, POCs, org changes	0-10%	On-demand as a rule	Wait for stability
Stable database floor	50-80%	Database SP or per-service reservations	Same floor-only principle
S3 / EBS / network	0%	Lifecycle, storage class, architecture	Not eligible for RI/SP in the first place

Adjust for business constraints too. If preserving cash is the priority, shift 10-15 points toward the low end. If your architecture changes every quarter, shift 10-20 points down. If a reorg or M&A is on the horizon, sit at the low end for now.

What committing to the floor looks like numerically

As an illustrative assumption: a permanent floor of $1,000/hr, a weekday peak adder of $500/hr for 220 hours a month, and a Compute SP effective rate at 70% of on-demand.

Case	Monthly cost	vs on-demand
All on-demand	$840,000	baseline
Compute SP on 70% of the floor	$686,700	-18.3%
Compute SP on 100% of the floor	$621,000	-26.1%
Compute SP on 120% of the floor	$679,200	-19.1%

Efficiency holds all the way to 100% of the floor and collapses the moment commitments chase the variable peak. That is the arithmetic behind “secure the floor rather than chase 100% coverage.”

The dev/test case is starker. With on-demand at $1/hr per instance, a Compute SP effective rate of $0.70/hr, and only 12 weekday hours of runtime (260 hours a month), all on-demand costs $260, a 24x7-equivalent full commitment costs $511, and even a “buy half” 50% commitment lands around $386. Savings Plans do not discount the hours you run; they consume a commitment every hour.

Decision flow and financial evaluation

flowchart TD
    A[Classify the cost] --> B{Eligible for RI/SP?}
    B -- No --> C[Manage S3/EBS/transfer/NAT separately]
    B -- Yes --> D{Need AZ capacity assurance?}
    D -- Yes --> E[Consider Zonal RI or ODCR]
    D -- No --> F{Family and region stable 12+ months?}
    F -- Yes --> G[EC2 Instance SP or Standard RI]
    F -- No --> H{Generation change or Fargate move likely?}
    H -- Yes --> I[Compute SP or Convertible RI]
    H -- No --> J[Compute SP as the base, RI on the stable floor only]
    E --> K[Leave the rest on-demand]
    G --> K
    I --> K
    J --> K

To find the floor, pull 90 days of hourly on-demand spend (the lowest quarter if you have seasonality) and take the P10 as the level you will never drop below. Committing at the mean means usage falls short roughly half the time.

Financially, look past the discount rate at TCO, NPV, payback, and the break-even duty cycle. The break-even duty cycle (commitment rate ÷ on-demand rate) is what bites intermittent workloads: if the commitment costs 70% of on-demand, a full commitment only wins when that unit is consumed more than 70% of the time. Approximating from AWS’s published averages (Standard RI averages 40% off for 1 year and 60% off for 3 years; Convertible RI averages 31% and 54%), a 1-year Standard RI needs above 60% duty cycle and a 3-year Standard RI above 40%.

For NPV, model three cases: base, -20% demand, and +20%. Because AWS recommendations carry no forecast, you have to price in demand decline and post-rightsizing shrinkage yourself, or your optimization quietly becomes a fixed cost.

Exits when you over-commit

Know the exit before you buy.

Standard RI (EC2): sellable on the RI Marketplace (12% fee, not in the first or last 30 days, US bank account required)
Convertible RI: exchangeable within the same region for equal-or-greater value, keeping the expiration date
Savings Plans: no resale, no cancellation. Only the return window at $100/hr or less, within 7 days, same calendar month
RDS / ElastiCache / OpenSearch / Redshift RIs: no resale market

A design that leans entirely on Savings Plans is fragile from this angle. Their flexibility and low operational overhead make them the right first choice, but pairing them with RIs that have real exits is worth considering.

Practical checklist

Optimize first. Delete idle resources, rightsize with Compute Optimizer, and modernize generations (Gen7+, Graviton, Valkey) before committing. Discounting an oversized fleet just locks in the waste.
Split the denominator. Separate EC2 / Fargate / Lambda / eligible DB from S3 / EBS / transfer / NAT.
Get tagging in order. Enable cost allocation tags and standardize environment, application, owner, and cost center.
Compute the floor yourself. Take the P10 of 90 days of hourly data and apply a 70-75% buffer to Cost Explorer recommendations rather than trusting them outright.
Assign by tier. RI / EC2 Instance SP for the most stable layer, Compute SP for the variable layer, Spot for interruptible work, on-demand for peaks.
Buy in stages. Add in small increments each quarter and spread expirations.
Set up monitoring. Alert on utilization, coverage, and expiration (30/60/90 days) in the payer account. Note that AWS Budgets notifications can lag by up to 48 hours.

For operating thresholds, 95-98% SP utilization on steady production works well, as does stopping purchases and suspecting over-commitment after three consecutive days below 85%, or after unused commitment persists for two months.

Caveats

Figures like 72%, 66%, and 35% are maximums under specific conditions (3-year, All Upfront, specific regions). Real discounts vary widely by instance type, OS, and region, and licensed operating systems such as Windows or SQL Server, along with small instances, can yield only a few percent. Verify your own rates in Purchase Analyzer before buying.
Most percentages here come from third-party FinOps practice and from ranges reconstructed from AWS’s mechanics. They are not official AWS fixed values.
Database SP is new and heavily constrained: Gen7+ only, ElastiCache on the Valkey engine only, 1-year and No Upfront only, no overlap with RI on the same workload, and storage and backups excluded.
Figures and product specs reflect 2025-2026. AWS typically revises pricing and products at re:Invent (late November to December), so re-check the official pages right before purchasing.

Conclusion

The instinct that you do not have to commit 100% matches best practice. Given hourly, non-rolling commitments and history-based recommendations, the correct order is visibility, then rightsizing, then small purchases, then observation, then more purchases.

That’s all from organizing AWS RI and Savings Plans around the principle of committing only to the floor, from the Gemba.

References

Reserved Instances differ by service in naming, discount rate, and purchase unit. Check the official page for the service you are actually buying for.