RIs, Savings Plans, Spot, and on-demand — the decision matrix per workload shape

A FinOps review on a $50k/month AWS bill (compute alone) finds 100% on-demand. The platform team has not committed because the workload roadmap moves quickly and nobody wants to lock in capacity that turns out to be the wrong instance family in six months. The savings on the table are real — the on-demand line is 30% above what the same compute would cost under any reasonable commitment. The question is not whether to commit; it is which commitment matches which workload, and how much of the fleet to leave on on-demand for flexibility. The decision matrix below has four columns — RI, Savings Plans (Compute and EC2 Instance variants), Spot, on-demand — and a small set of workload shapes that map cleanly to each one.

What’s happening

The four pricing models and their structural differences:

The high-level distinction between Compute Savings Plans and EC2 Instance Savings Plans: Compute is broader (covers Fargate and Lambda too, instance family flexible) but the discount rate is lower. EC2 Instance is narrower (one family in one region) and the discount rate is higher. For a workload running 24/7 on m6i in us-east-1, EC2 Instance is the better deal; for a workload that flips between EC2 and Fargate as the architecture evolves, Compute is the safer commitment.

The two cases where Reserved Instances still win in 2026: RDS reservations (Savings Plans do not cover RDS) and workloads where Convertible RI’s exchange feature provides specific flexibility not available in Savings Plans. For everything else, Savings Plans have largely replaced RIs because the family flexibility makes them less risky.

Spot is its own category. Spot instances are EC2 capacity AWS sells at deep discount but can reclaim with a 2-minute warning. The fit is workloads that can absorb interruption — batch processing, CI build runners, dev/test, stateless web workers behind an autoscaling group with capacity-optimized strategy. The fit is not databases, stateful caches, or single-instance services. The unfortunate pattern is teams that read about the 90% discount, put production on Spot without designing for interruption, and lose state when a Spot reclaim hits.

How to verify

The Cost Explorer recommendations and current coverage:

# current coverage
aws ce get-savings-plans-coverage \
  --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
  --granularity MONTHLY \
  --query 'SavingsPlansCoverages[].[TimePeriod.Start,Coverage.CoveragePercentage]' \
  --output table

# recommendations
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 \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[].[InstanceFamily,EstimatedSavingsPercentage,UpfrontCost,HourlyCommitmentToPurchase]' \
  --output table

The 60-day lookback is the calibration window AWS uses to project the commitment. If the lookback window includes an unusual period (a campaign spike, a month with a stale environment that has since been deleted), the recommendation will be off. Re-run the recommendation after the workload has stabilized for at least 30 days.

For the Spot eligibility check, list the workloads:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[?InstanceLifecycle==`null`].[InstanceId,InstanceType,Tags[?Key==`workload-type`].Value|[0]]' \
  --output table

Anything tagged batch, ci, dev, stateless-worker is a candidate for Spot. Anything tagged database, stateful, singleton is not.

The fix

The decision matrix per workload shape, with the matching commitment:

Steady-state production (24/7, predictable):

• The 80% baseline that runs continuously belongs on Savings Plans.
• If the workload is locked to one instance family for the foreseeable future, EC2 Instance Savings Plans for the deeper discount.
• If the architecture might shift between EC2 and Fargate, Compute Savings Plans for the flexibility.
• Term: 1 year. Three-year terms get a deeper discount but lock in capacity through architecture cycles that often invalidate the commitment. The marginal discount on year 3 is rarely worth the lock-in.
• Payment: no-upfront in most cases. The upfront payment options give a few extra percent but tie up cash. Take the operational discount, keep the cash flow.

Bursty production (predictable baseline + variable peak):

• Cover the baseline (the p10 of fleet size, or whatever the always-on floor is) with Savings Plans.
• Leave the bursty top layer on on-demand.
• The mistake is committing to the average. Commitment above the always-on floor wastes the discount during the trough; commitment below the always-on floor leaves savings on the table during the peak.

Interruption-tolerant batch (CI, ETL, training, stateless workers):

• Spot, with mixed-instance ASG and capacity-optimized allocation strategy.
• The capacity-optimized strategy biases towards instance types with the lowest interruption rate at request time. The price-capacity-optimized variant adds a price weight.
• Always have on-demand fallback: an ASG with OnDemandPercentageAboveBaseCapacity set so the workload survives a Spot stockout. A typical mix is 30% on-demand baseline + 70% Spot for the variable top.

Unpredictable, short-lived (proof-of-concept, irregular workloads):

• On-demand. Commitment requires predictability. A workload that might be deleted in three months should not be on a 12-month commitment.
• The 30% premium for on-demand is the cost of optionality, and optionality is worth real money when the workload roadmap is uncertain.

Databases and stateful caches:

• RDS Reserved Instances for the database tier (Savings Plans do not cover RDS).
• ElastiCache and Redshift have their own RI options.
• Never Spot.

The break-even math is straightforward once the workload is classified. A 1-year Savings Plan at the no-upfront option breaks even at month 6 — if the workload runs continuously for at least six months, the commitment pays off relative to on-demand. After six months, every additional month is pure savings.

For 3-year terms, the break-even pushes out to roughly the 12-month mark when you factor in the time-value of money plus the higher likelihood that the workload changes shape over three years. The 3-year commitment is right only when the workload is stable enough that the team can confidently project usage three years out (a long-running platform service, a regulated workload that cannot move clouds, an established product line). For most SaaS, 1-year is the right call.

The Compute vs EC2 Instance choice within Savings Plans:

• If 80% of the fleet runs on one family in one region for the foreseeable future: EC2 Instance, take the deeper discount.
• If the fleet uses three or four families across two regions: Compute, take the flexibility.
• If the workload mixes EC2 and Fargate: Compute, because EC2 Instance does not cover Fargate.
• If the workload is purely Lambda: Compute Savings Plans cover Lambda (the only commitment option that does).

The lock-in trade-off is real. A team that commits 100% to Savings Plans is leaving no room for the workload to shrink — if the fleet drops by 30% after a refactor, the unused commitment still bills. The 80% rule is the practical compromise: commit to the rock-bottom 80% of usage, leave the variable top on on-demand. Re-evaluate every six months.

Three rules across every commitment-strategy engagement:

Classify before you commit. A spreadsheet listing every workload, its shape (steady/bursty/batch/unpredictable), its commitment-target, and its current pricing model. The commitment is mechanical once the matrix is filled.

Commit to the baseline, not the average. The always-on floor is the safe commitment. Anything above is on-demand or Spot, depending on interruption tolerance.

1-year terms by default. The 3-year discount is real but the lock-in compounds across architecture cycles. Three-year commitments belong only to workloads with proven multi-year stability.

The initial classification on a $50k/month bill is a focused two days. The first round of commitments typically captures 25-30% off the bill within the first month. The ongoing rhythm is a quarterly review tied to the cost-audit cadence in the broader Stack Harbor playbook.

Stack Harbor runs IAM cleanup, CloudWatch baseline, AWS Backup, and the cost-control rhythm as part of Managed AWS and ongoing Managed Cloud Ops. If the bill is 100% on-demand on a steady workload, start with an infrastructure consult.