Reserved Instance or Savings Plan? Pick the right commitment for the right workload

Every AWS account over $20K per month eventually gets the same call: finance wants the cloud bill flat, engineering wants the workload to keep running, and someone has to decide between Reserved Instances, Savings Plans, or just paying on-demand and hoping. The internet is full of side-by-side tables that compare the two products on paper. That is not the question. The question is which workload pattern fits which commitment, and almost every account that runs a real workload ends up using both.

Here is how we decide on the audits we run. The math, the workload patterns, and the three questions we ask before recommending a commitment.

The product difference, in one paragraph

Reserved Instances lock a specific instance family, OS, and tenancy in a specific region for 1 or 3 years. Standard RIs save up to ~72% and lock the family. Convertible RIs save up to ~66% and let you exchange the family during the term. Compute Savings Plans commit you to a dollar amount of compute spend per hour, save up to ~66%, and apply across EC2, Fargate, and Lambda regardless of family or region. EC2 Instance Savings Plans sit between the two, locking family and region but not size, with discounts up to ~72%.

That is the spec sheet. The interesting part is which one fits which workload, which is rarely the spec sheet.

The three questions

Before recommending a commitment we ask three questions about the workload.

1. Is the family stable for the full term?

If the workload runs on m5 today and will still run on m5 in 36 months, a Standard RI on m5 in that region is the highest-discount commitment you can buy. Database fleets, license-bound workloads (SQL Server, Oracle), and stable internal services usually fit this profile.

If the family will probably change (Graviton migration, m6i moving to m7i, hardware refresh) the Standard RI gets stranded. You either pay for an unused commitment or convert it via Convertible RI rules, which require manually re-shaping each commit. Compute Savings Plans skip this problem by abstracting the commitment to dollars per hour. The migration changes the family, the spend stays roughly flat, and the SP keeps applying.

2. Does workload mix shift across families?

A platform team running 14 different services on 6 instance families has a portfolio problem. RIs require predicting the right mix for each family for 1 to 3 years. Get any one wrong and you have stranded capacity. Compute Savings Plans don't care which family runs at any given hour as long as the total compute spend per hour stays above the commitment level. For variable workload portfolios this is the cleaner instrument by a wide margin.

3. Does capacity reservation matter?

Standard RIs include a capacity reservation by default in the scope of the RI. Savings Plans do not. If you are running in a capacity-constrained Availability Zone (large GPU SKUs, m7i in certain regions during peak) the RI guarantees AWS will have an instance for you. The SP only guarantees a price.

This rarely matters until it does. Most workloads run in regions and on families with effectively unlimited capacity. The exceptions are GPU workloads (p4, p5, g6e in any region), a handful of memory-optimized SKUs in over-subscribed regions, and hardware-bound workloads tied to a specific generation.

The math, with a worked example

A team runs $40K per month on EC2 across two patterns: $20K on a stable RDS-adjacent fleet (m5.4xlarge, 50 instances, predictable), and $20K spread across 6 different families for variable application services. They want to commit for 3 years.

Path A: 3-year Standard RI Partial Upfront on the stable fleet ($20K), 3-year Compute Savings Plan No Upfront on $15K of the variable fleet (75% coverage on the variable side).

Numbers, using 2026 typical defaults:

• Stable fleet, 3-year Standard RI Partial Upfront: roughly 52% off. $20K eligible monthly spend goes to $9.6K. Savings of $10.4K per month, $374K over 36 months. Upfront fee: ~$172K. Net savings after upfront: ~$202K.
• Variable fleet, 3-year Compute SP No Upfront: roughly 36% off on $15K eligible. $5.4K saved per month, $194K over 36 months. $5K per month stays on-demand at the variable usage rates.
• Combined: ~$15.8K saved per month, ~$568K saved over the 3-year window, ~$172K upfront. Effective discount on the committed portion: ~45%.

Path B: skip the RI, put everything on a 3-year Compute Savings Plan All Upfront for $35K per month (87.5% coverage of the $40K baseline).

• $35K eligible at roughly 54% off (3-year all-upfront SP). $18.9K saved per month, $681K over 36 months. Upfront fee: ~$582K. Net savings after upfront: ~$99K. Plus $5K per month on-demand on the uncovered slice.

Path B looks like a bigger discount on paper. The cash story is brutal. Path A's mixed approach gives the team a better net position over 36 months at less than a third of the upfront and with the workload mix flexibility intact.

We use this exact reasoning on audits. If you want to plug your own numbers in, we built two free calculators that do the math side by side: Savings Plan ROI calculator and Reserved Instance break-even calculator.

Common mistakes we see on audit

Stacking RIs and Savings Plans on the same hours

Both products discount the same hours, but you can only spend a given hour once. AWS applies RIs first, then Savings Plans absorb the remainder, then any leftover capacity bills at on-demand. Teams sometimes buy a Savings Plan to "cover the whole bill" while existing RIs still cover the stable fleet. The Savings Plan now sits idle on hours the RI already discounted, and the team paid for a commit they don't use.

Picking 3-year terms before the workload is real

We see this on companies that just migrated to AWS. The CFO presses for commits early, the engineering team picks 3-year Standard RIs because the calculator showed the biggest number, and 14 months later the workload moved to a different family or the company pivoted. Default to 1-year on workloads younger than 12 months, then re-evaluate.

Buying Convertible RIs instead of Compute SPs

Convertible RIs gave you family flexibility before Compute SPs existed. Compute SPs do the same job better in almost every case: same family flexibility, lower discount cap, but no manual re-shape required when the workload changes. Convertible RIs still have a place when capacity reservation matters and the workload might cross families. Otherwise prefer the SP.

Forgetting to track expiry

RIs expire silently. The instance keeps running, the bill goes up, and nobody notices until finance pings the next month. Set an alert on the day a 1-year RI lapses, watch the daily on-demand line for the affected family, and decide on renewal within the first week. We catch this on roughly half the accounts we audit.

The actual recommendation we give

Run a quick portfolio audit. Identify the stable fleet (databases, license-bound workloads, services older than 12 months running on the same family). Cover that with Standard RIs at whatever term matches the workload's expected life, in the payment option your finance team prefers.

Cover the variable portion with a Compute Savings Plan sized for the lower bound of monthly spend. Aim for 70 to 80% coverage on the variable side. Anything higher leaves no headroom for traffic dips and your SP starts paying for hours you don't actually use.

Re-run the audit every quarter. Workloads drift, instance families get refreshed, and the right mix six months ago might be wrong now. The point of the commitment is to be rough-right for the full term, not perfect on day one.

If you want a second pair of eyes on your specific portfolio, Cloud Horizon runs a 14-day read-only audit of your AWS environment and reports back the exact RI/SP coverage gaps, stranded commitments, and renewal risks we find. Start the free audit if that would help.