To use Spot safely with Karpenter, allow both Spot and On-Demand in the NodePool so Karpenter prefers Spot and falls back when needed, widen instance type diversity to draw from many Spot pools, rely on Karpenter's interruption handling, and pin stateful or critical workloads to On-Demand. Spot is typically 60 to 90 percent cheaper than On-Demand, and AWS gives a two minute interruption warning, which is enough for Karpenter to drain and replace a node if pods shut down gracefully. Instance diversity is the main lever for stability.
Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.
This article sits in our complete guide to Kubernetes cost optimization, the cluster pillar it links up to, and connects to the broader cloud cost optimization playbook. Spot pairs directly with packing, so read it alongside our companion guide on how to tune Karpenter consolidation for maximum savings. Running Spot is a Cut step move that delivers the largest single compute discount on EKS.
Instance type diversity. Spot interruptions happen when AWS reclaims capacity from a specific Spot pool, so the more pools you let Karpenter choose from, the smaller the impact of any single reclamation. Allow a broad set of instance families and sizes in the NodePool, and Karpenter draws from many independent pools and prefers those with the most available capacity. A diverse Spot configuration is both cheaper and far more stable than a narrow one pinned to a couple of instance types.
Why run Spot with Karpenter?
Running Spot with Karpenter gives you the deepest EC2 discount with almost no manual effort, because Karpenter natively provisions Spot capacity and falls back to On-Demand when Spot is unavailable. EC2 Spot is typically 60 to 90 percent cheaper than On-Demand depending on the pool and region, per the EC2 Spot pricing documentation, and Karpenter handles the placement, diversification, and interruption response that used to require careful Auto Scaling Group design. For a fault tolerant workload, a large Spot share is the single biggest compute lever on EKS. Confirm current Spot prices in that documentation before modeling, because they change continuously.
How do I run Spot safely, step by step?
Run it safely by allowing both capacity types, diversifying instances, handling interruptions, and protecting the workloads that cannot move. Five steps:
- Allow Spot and On-Demand. Set the NodePool capacity-type requirement to include both spot and on-demand. Result: Karpenter prefers Spot and falls back to On-Demand when Spot is short.
- Widen instance type diversity. Allow many instance families and sizes. Result: deeper Spot pools, lower interruption risk, cheaper fit.
- Enable interruption handling. Let Karpenter watch the interruption notice and rebalance recommendation. Result: nodes are drained and replaced before reclamation.
- Protect stateful and critical workloads. Pin databases and singletons to On-Demand with node selectors and set PodDisruptionBudgets on important services. Result: no surprise outages.
- Verify Spot share and savings. Track Spot share, interruption frequency, and savings, then adjust. Result: the largest safe Spot share you can run.
How does Karpenter handle Spot interruptions?
Karpenter handles Spot interruptions by watching the EC2 interruption notice and rebalance recommendation, then cordoning and draining the affected node and provisioning a replacement before the instance is reclaimed. AWS gives a two minute warning when it reclaims a Spot instance, and that window is enough for Karpenter to reschedule pods onto new capacity, provided your pods respect graceful shutdown and terminationGracePeriodSeconds. For stateless services with multiple replicas this is seamless. The interruption handling is what makes a high Spot share practical: the node going away becomes a routine reschedule rather than an incident.
Want the largest safe Spot share running on your clusters?
Our Kubernetes cost audit configures Karpenter Spot with the right diversity and interruption handling, pins the workloads that must stay On-Demand, and verifies the savings hold. On the performance model, you pay only from realized savings. No savings, no fee.
Book a Kubernetes cost audit →Which workloads should stay on On-Demand?
Keep stateful singletons, databases that cannot tolerate a node loss, long running jobs without checkpointing, and anything that cannot drain within the two minute window on On-Demand. Pin them with node selectors that require the on-demand capacity type so Karpenter never places them on Spot. Everything else, stateless services with several replicas, batch jobs, queue consumers, and CI runners, is a strong Spot candidate, especially behind a PodDisruptionBudget that bounds how many replicas can be drained at once. The pattern is a mostly Spot cluster with a small, deliberate On-Demand island for the workloads that need it. The broader EKS efficiency sequence lives in our Kubernetes guide.
The Kubernetes Cost Optimization Handbook includes the Spot diversity template and the On-Demand pinning patterns referenced above. It is the downloadable companion to this guide.
Frequently asked questions
How much do Spot instances save with Karpenter?
EC2 Spot instances are typically discounted steeply against On-Demand, often in the range of 60 to 90 percent depending on instance type and region, and Karpenter can place a large share of fault tolerant capacity on Spot automatically. The exact discount varies by Spot pool and changes over time, so confirm current Spot prices in the AWS documentation before modeling.
How does Karpenter handle Spot interruptions?
Karpenter watches the EC2 Spot interruption notice and the rebalance recommendation, and when a node is flagged for reclamation it cordons and drains that node and provisions a replacement so pods are rescheduled before the instance is taken. AWS gives a two minute warning on Spot interruption, which is enough time for Karpenter to move workloads if your pods shut down gracefully.
What workloads should not run on Spot?
Avoid Spot for stateful singletons, databases that cannot tolerate a node loss, long running jobs without checkpointing, and any service that cannot drain within the two minute interruption window. Pin those to On-Demand with node selectors. Stateless services, batch jobs, and anything with multiple replicas behind a PodDisruptionBudget are good Spot candidates.
How do I reduce Spot interruption risk?
Reduce interruption risk by allowing a wide diversity of instance types and sizes in the NodePool so Karpenter draws from many independent Spot pools. The more pools you can run on, the less likely a single pool's reclamation affects you, and Karpenter automatically prefers pools with more available capacity. Diversity is the single biggest lever for Spot stability.
The short version
Allow Spot and On-Demand together, diversify instance types widely, rely on Karpenter's interruption handling, and pin the workloads that cannot move to On-Demand. That gives you the largest safe Spot share and the deepest compute discount on EKS. When you want it configured and verified on your clusters, that is what our rightsizing and waste elimination service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.