Spot or Savings Plans on Kubernetes: how to combine them without wasting commitment

"Spot or Savings Plans?" is usually treated as a choice. In practice, they are tools for different parts of the same cluster, and the costliest mistake is using both on the same workload.

What each one is

• On-Demand is the list price, with no commitment.
• Spot uses spare AWS capacity at a large discount, which AWS advertises as up to 90% off On-Demand. In return, the instance can be reclaimed with a two-minute notice.
• Savings Plans are a spend commitment per hour, for 1 or 3 years. Compute Savings Plans apply to EC2 of any family, Region and OS, plus Fargate and Lambda. EC2 Instance Savings Plans give a bigger discount and are tied to one family in one Region. The discounts AWS advertises reach about 66% and 72%, respectively.

Percentages vary by instance type, Region and term. Check the AWS price table before deciding.

The point that changes the math

Savings Plans offset On-Demand usage. A Spot instance does not consume your commitment. If you buy a plan and later move the workload to Spot, the plan covers less usage but the hourly charge continues. You pay the commitment without getting the discount, and Spot does not save what it looked like it would.

That is why the Spot cost estimator asks for the share already covered by commitments: the net gain of moving a workload to Spot is the difference between the Spot discount and what the plan already gave.

The order that works

1. Right-size first. Committing on inflated requests locks in waste for 1 to 3 years. Use rightsizing-check.
2. Find what tolerates interruption. Replicas, probes, PodDisruptionBudgets and termination time decide it. spot-readiness turns that into a plan.
3. Commit the steady base, what runs 24 by 7 and will not go to Spot, and only that. Committing to the peak is the classic mistake.
4. Put the elastic and tolerant part on Spot, with several instance families and On-Demand fallback, for example with a Karpenter NodePool.
5. Leave the rest On-Demand and review coverage every quarter.

Common mistakes

• Buying the plan before right-sizing.
• Moving workloads to Spot that were already covered by the plan, without revisiting the commitment.
• Using a single instance family on Spot, which raises interruptions and On-Demand fallback.
• Treating Spot as "free" and ignoring the engineering effort, which the estimator reflects in its realistic range.
• Committing too much because the peak month looked like the average.

A worked line of reasoning

A cluster spends $20k a month on compute. Half of it tolerates interruption and 20% already runs on Spot. Of the 30% that could still move, part is already under a plan. The gain from moving that share is smaller than the Spot discount suggests, and the calculator shows by how much without promising the exact number. The real figure depends on your workloads, and it is what a technical assessment delivers.

To add up rightsizing, Spot, off-hours shutdown and Graviton, use the savings calculator. If you want me to build the execution order for your environment, the efficiency assessment is the place to start.