AWS Reserved Instances vs Savings Plans vs Spot: When Each Fits

Default to Compute Savings Plans for steady compute (up to 66% off, applies across EC2, Fargate and Lambda), Spot for interruptible work (up to 90% off, two-minute reclaim notice), and Reserved Instances only where no Savings Plan fits. AWS itself recommends Savings Plans over RIs, and Database Savings Plans now cover RDS, Aurora and ElastiCache.

They sound similar; they are not. Picking the wrong one costs money and locks you in. The shape of each commitment matters more than the headline percentage:

• Reserved Instance = commit to what (instance type, Region, tenancy, platform).
• Savings Plan = commit to how much (dollars per hour).
• Spot = commit to nothing, accept interruption.

The mechanisms, side by side

Neither RIs nor Savings Plans can be cancelled after purchase, and a Savings Plan's terms cannot be changed afterwards. RIs at least have an exit: they can be modified, Convertible RIs exchanged, and some sold on the Reserved Instance Marketplace.

When RIs still make sense

Rarely. The EC2 docs open with "We recommend Savings Plans over Reserved Instances," and the arrival of Database Savings Plans removed the old argument that RIs were the only discount for RDS and ElastiCache. What is left:

• Services no Savings Plan covers. Check the eligible-services list before buying; Redshift, for example, is not on the Database Savings Plans list.
• Databases where the deeper RI discount beats 35%. Database Savings Plans trade discount depth for engine and Region flexibility. For a frozen, single-engine fleet that will not change for three years, the RI rate may be lower. Model both.
• Frozen EC2 workloads. An old service that will never change instance type gets similar pricing from an EC2 Instance Savings Plan with less paperwork, so even here RIs are a tie at best.

When Savings Plans fit, which is most of the time

Compute Savings Plans are the default because they follow workloads: move from c5 to m5, from Ireland to London, or from EC2 to Fargate, and the commitment still applies. EKS control-plane charges are not covered, but the EC2 nodes under EKS, ECS and EMR are.

Size the commitment below your steady state, not at it. A common rule of thumb is roughly 70% of trailing compute spend, measured after rightsizing, which leaves room for growth that changes shape, Spot (which a Savings Plan does not discount), and temporary spikes. Let Cost Explorer do the first pass:

$ 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.SavingsPlansPurchaseRecommendationSummary.[HourlyCommitmentToPurchase,EstimatedSavingsPercentage]'

Treat the output as a ceiling: it assumes the last 60 days repeat. We default to one-year, no-upfront terms. Three-year terms discount more, but three years is a long time to predict your compute shape, and the payment option moves the rate less than the term does.

When Spot is the answer

Spot fits work that tolerates losing a machine with two minutes' warning:

• Stateless queue workers. If a worker dies mid-task, the message returns to the queue.
• Batch and training jobs with checkpointing. Interruption means restarting from the last checkpoint.
• Stateless web tiers behind a load balancer, over-provisioned so one interruption does not drop you below capacity.
• CI runners. An interrupted build reruns.

It does not fit stateful databases, caches without replicas, single-replica services, or anything with a tight cold-start budget. For the mechanics in depth, see the Spot instances guide.

The Spot architecture that makes it boring

Diversify across pools. Spot capacity is per instance type per Availability Zone. If everything is m5.xlarge in us-east-1a, one capacity event takes it all. Accept a range of types and sizes across zones. Karpenter does this by requirement rather than by list, as covered in Karpenter provisioning patterns.

Handle the two-minute notice. AWS publishes interruption notices as an EC2 Spot Instance Interruption Warning EventBridge event and in instance metadata, and recommends polling every 5 seconds. On raw EC2, a watcher like this drains the node:

#!/usr/bin/env bash
# /usr/local/bin/spot-watch.sh
while sleep 5; do
  TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
  CODE=$(curl -s -o /tmp/spot-action -w '%{http_code}' \
    -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/spot/instance-action)
  if [ "$CODE" = "200" ]; then
    echo "interruption scheduled: $(cat /tmp/spot-action)"
    systemctl stop my-worker   # finish or requeue in-flight work
    break
  fi
done

The endpoint returns 404 until an interruption is scheduled, then JSON like {"action": "terminate", "time": "..."}.

Act on rebalance recommendations. The EC2 Instance Rebalance Recommendation event (metadata path events/recommendations/rebalance) flags elevated interruption risk and can arrive before the two-minute notice, though not always. Auto Scaling Capacity Rebalancing uses it to launch replacements early.

The errors you will see

• InsufficientInstanceCapacity: "There is not enough capacity to fulfill your request." Add instance types and zones to the request instead of retrying the same pool.
• MaxSpotInstanceCountExceeded: you hit the Spot limit for that type. Request a quota increase.
• SpotMaxPriceTooLow: your maximum price is below the current Spot price, so the request stays open. Raise or remove the maximum price.
• ReservedInstancesLimitExceeded: your quota does not allow the RI purchase. Usually a sign you should be buying a Savings Plan instead.

Mistakes teams make

Committing during a spike. Buying a Savings Plan sized to a quarter that was heavily over-provisioned leaves you paying for unused commitment after rightsizing. Model against the post-optimization baseline; rightsizing Kubernetes requests usually comes first.

Three-year all-upfront RIs on today's instance family. Migrate to a newer generation in year two and the RIs sit idle. Marketplace resale recovers only part of the cost.

Treating Spot as too risky. Teams that keep Spot on dev clusters only leave the largest discount unused. Diversification plus graceful shutdown makes it routine.

Forgetting the Region dimension. Compute Savings Plans apply across Regions, but at each Region's rate, so moving workloads changes how far the commitment stretches.

Where this breaks

This split assumes steady compute plus interruptible overflow. A workload that is genuinely spiky and short-lived (a few weeks of migration traffic) should stay on On-Demand; any commitment overshoots. Regulated workloads that need Dedicated tenancy pay a per-Region dedicated fee that Savings Plans do not discount. And GPU capacity is often too scarce for Spot to be dependable; use capacity reservations instead.

Questions people ask

Are Savings Plans better than Reserved Instances?

For most EC2, Fargate and Lambda usage, yes. AWS's own EC2 documentation recommends Savings Plans over Reserved Instances, and EC2 Instance Savings Plans reach the same up-to-72% discount without locking instance size or OS. RIs keep two edges: some can be sold on the Reserved Instance Marketplace, and for services outside every Savings Plan type they are still the only commitment discount.

Can I combine Savings Plans and Spot?

Yes, and you should. Spot usage is billed at the Spot price rather than discounted by a Savings Plan, so the two cover different slices of your fleet. Size the Savings Plan to the always-on baseline, run interruptible capacity on Spot, and let On-Demand absorb whatever is left. Check aws ce get-savings-plans-utilization monthly; utilization well below 100% means you over-committed.

How much notice does AWS give before reclaiming a Spot instance?

Two minutes, delivered as an EventBridge event and through the spot/instance-action instance metadata path, on a best-effort basis. If the interruption behavior is hibernate, there is no two-minute warning because hibernation starts immediately. Rebalance recommendations can arrive earlier and signal elevated risk, which gives Auto Scaling and Karpenter time to launch replacements first.

What to read next

• Karpenter node provisioning patterns at scale, a common Spot diversification mechanism
• Kubernetes resource requests: right-sizing across the cluster, the rightsizing prerequisite
• Cross-cloud identity federation patterns, an adjacent cloud architecture pattern
• Internal developer platforms: Backstage in practice, for surfacing cost back to teams

The biggest savings come from rightsizing, not discounts: a discount on a wrong-sized instance loses to fixing the size. Measure, rightsize, commit to the floor with Savings Plans, and push everything interruptible to Spot.

Sources

• AWS Savings Plans User Guide: Savings Plans types
• Amazon EC2 User Guide: Reserved Instances overview
• Amazon EC2 User Guide: Spot Instance interruption notices
• Amazon EC2 Spot Instances pricing