Combining Spot and Savings Plans: the layered compute discount strategy

Quick answer

Spot instances and Savings Plans solve different problems and work best together. Savings Plans give a discount (up to about 72 percent for a 3-year EC2 Instance plan) on a committed, always-on baseline of compute, with no interruption risk. Spot gives a deeper discount (up to 90 percent) on interruptible capacity but can be reclaimed. The layered strategy commits Savings Plans to the steady baseline you always run, and covers the elastic, fault-tolerant portion with Spot, so nothing runs at full on-demand price. The mistake to avoid is committing a Savings Plan to capacity that Spot should have covered, or the reverse, running steady baseline on Spot and risking interruption to save a little more.

Teams often treat Spot and Savings Plans as competing choices, then pick one. In fact they cover different parts of a fleet, and the lowest-cost architecture uses both. Savings Plans discount the compute you know you will run continuously, and Spot discounts the compute that is elastic or interruptible. Layering them means almost none of your fleet ever pays full on-demand price.

What each discount is for

Mechanism	Discount	Interruption	Covers
Savings Plans	Up to ~72% (3yr, committed)	None	Steady, always-on baseline
Spot	Up to ~90%	2-minute warning	Elastic, fault-tolerant capacity
On-demand	None (baseline)	None	Unpredictable spikes, gaps

Savings Plans are a spend commitment: you agree to a dollars-per-hour amount for 1 or 3 years and get a discount on usage up to that amount, with no risk of interruption. Spot is spare capacity at a deep discount that AWS can reclaim. The two do not overlap, they complement, one for the predictable floor and one for the variable top.

Layer one: commit the baseline

Every workload has some capacity it runs around the clock. That baseline is ideal Savings Plan territory, because it is predictable and always on, so a 1 or 3 year commitment is safe and the discount is guaranteed. Size the commitment to the floor of your usage, the amount you are confident you will run continuously, using the coverage discipline in the coverage and utilization guide. Do not over-commit past the baseline, or you pay for a commitment you do not use.

Layer two: Spot for the elastic and interruptible

Above the baseline sits the elastic capacity: the scale-out under load, the batch jobs, the workers, the stateless services that can tolerate a task or instance disappearing. That capacity should run on Spot, which is cheaper than even a Savings Plan and needs no commitment. Diversify across instance types and Availability Zones so interruptions are absorbed, the approach in the Spot diversification guide. Spot covers the part of the fleet that a Savings Plan should not, because you do not want to commit to capacity you may not always need.

Layer three: on-demand fills the gaps

A thin layer of on-demand handles what neither covers: sudden spikes beyond your Spot capacity, and short-lived needs not worth committing to. On-demand is the most expensive per hour, so it should be the smallest layer, the buffer rather than the base. The goal is that the bulk of the fleet runs on Savings Plan or Spot rates and only the unpredictable edge touches full price.

The mistakes to avoid

Two errors undo the strategy. First, committing a Savings Plan to capacity that Spot should cover: you lock in spend for elastic or batch workloads that would have been far cheaper on Spot with no commitment. Second, running your steady baseline on Spot to squeeze the last few percent: you risk interruption of always-on workloads to save marginally over a Savings Plan that carries no risk. Match each layer to the mechanism built for it, the commitment laddering principle applied to Spot as well.

Building the layered fleet

Measure your baseline (always-on floor), your elastic and interruptible capacity, and your unpredictable spikes. Commit Savings Plans to the baseline, run the elastic portion on diversified Spot, and leave a small on-demand buffer. Reassess as the baseline grows, since a larger steady floor justifies a larger commitment. Price each layer against the resource catalog so the blended rate of the combined strategy is a concrete number before you deploy.

FAQ

Should I use Spot or Savings Plans?

Both, layered. Savings Plans discount the steady, always-on baseline of compute you know you will run, with no interruption risk, for up to about 72 percent off on a 3-year commitment. Spot discounts the elastic, interruptible portion for up to 90 percent off but can be reclaimed. Using both means committing Savings Plans to the baseline and running the variable capacity on Spot, so almost nothing runs at full on-demand price.

How do I combine Spot and Savings Plans?

Commit Savings Plans to your always-on baseline, the capacity you run continuously and are confident you will keep running. Run the elastic and fault-tolerant capacity above that baseline on diversified Spot instances, which need no commitment and cost less than even a Savings Plan. Leave a thin on-demand layer for unpredictable spikes. This layered approach matches each discount mechanism to the part of the fleet it fits.

What is the mistake to avoid when combining Spot and Savings Plans?

Two mistakes: committing a Savings Plan to capacity that Spot should have covered, which locks in spend for elastic or batch work that would have been far cheaper on Spot with no commitment; and running the steady baseline on Spot to save marginally, which risks interruption of always-on workloads over a Savings Plan that carries no interruption risk. Match each layer to the mechanism built for it.

How much of my fleet should be on Savings Plans versus Spot?

Size Savings Plans to your baseline, the floor of capacity you run around the clock and are confident you will keep running. Put the elastic and interruptible capacity above that floor on Spot. The exact split depends on how much of your usage is steady versus variable, but the principle is that the predictable base gets committed discounts and the variable top gets Spot, with only a small on-demand buffer at full price.

How does C3X help with a layered compute discount strategy?

C3X prices your compute from Terraform against a live catalog, so you can see the cost of the baseline, the elastic capacity, and the spike buffer before you deploy. That helps you size Savings Plan commitments to the true baseline and identify which capacity should run on Spot instead, so you build a layered fleet where the blended rate is a known number rather than discovering over-commitment on the bill.

What to do next

Layer Savings Plans and Spot so nothing runs at full price. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.