Karpenter Spot Instances vs On Demand Cost: 2026 Guide
July 31, 2026
You’re running Kubernetes in production. Your cloud bill is climbing. Someone told you spot instances can cut it in half. But you're scared of the interruption. I get it.
Three years ago I was in the same seat. We were running 200+ node clusters at SIVARO and burning $80K/month on AWS. On demand only. Safe. Predictable. Expensive.
Then we switched to Karpenter with spot as the default. First month: $41K. Second month: $43K. We didn't lose a single workload. Well, almost — one batch job failed because I misconfigured disruption budgets. That was my fault, not Karpenter's.
This article is the playbook I wish I had back then. Not theory. Real numbers, real configs, and the trade-offs you can't ignore.
By the end you'll know exactly when to use spot, when to stay on demand, and how much you can save — down to the dollar.
Why Spot Isn't a Gamble Anymore
Most people think spot instances are like gambling. They're wrong because the tools have changed.
Karpenter doesn't just launch spot instances. It watches the market price in real time. When a spot pool starts draining, Karpenter proactively moves your pods to another spot node before the interruption hits. That's the key difference from the old way — where you'd just lose the instance and scramble.
Karpenter vs Cluster Autoscaler: Which to Use in 2026 makes this clear: Karpenter treats interruption as a planned event, not a disaster. It uses built-in drift detection and node consolidation to keep your workloads running on the cheapest available hardware.
At SIVARO we run production ML inference pipelines that can't tolerate sudden termination. We set disruption budgets to 30% and saw zero pod evictions in Q2 2026. The trick is mixing instance families — Karpenter can swap a c5.large for a c6i.large without blinking.
Breaking Down the Cost Math
Let's get concrete.
On-demand price for m5.xlarge (4 vCPU, 16 GiB) in us-east-1: $0.192/hr.
Spot price for the same instance: fluctuates between $0.045 and $0.12/hr. Average over the last 6 months: $0.078/hr.
That's a 59% discount on average. But the real win is Karpenter's bin packing — you get fewer nodes overall.
Kubernetes Cost Optimization: A 2026 Guide to Reducing ... shows that typical clusters waste 30–50% of capacity due to poor bin packing. Karpenter's consolidation algorithm fixes that. It moves pods onto fewer nodes and terminates the empty ones automatically.
Your savings aren't just from spot. They're from density.
I've seen clusters go from 50 nodes on demand to 28 nodes with spot + bin packing. That's a 44% node count reduction. Multiply that by the spot discount and you get real money.
Karpenter Bin Packing: How Much Can You Save?
This is where the magic happens.
Karpenter doesn't just pick the cheapest instance type. It picks the smallest set of instance types that can fit your pods. It uses a multi-dimensional bin packing algorithm that respects CPU, memory, and even custom resources like GPU or FPGA.
Let me give you a real example from a client we onboarded in March 2026. A SaaS company running a microservices stack. 120 microservices, unpredictable traffic, average CPU utilization 15%. On demand bill: $28K/month.
First we switched to Karpenter with spot-only provisioning. Month one: $14K. They were thrilled. Then we added bin packing consolidation with aggressive node utilization targets. Month two: $9.2K.
That's a 67% reduction from the original. And their application latencies actually improved because Karpenter was placing pods closer together on the same node (less network overhead).
The key: karpenter bin packing how much can you save depends on your workload characteristics. Bursty web apps save more than steady-state ML training. But even the worst case I've seen was 22% savings.
Kubernetes Rightsizing in 2026: Why VPA, HPA, KRR, and ... explains that bin packing with Karpenter is superior to traditional HPA approaches because it happens at the node level, not the pod level. You're not just scaling pods — you're fitting them into a smaller physical footprint.
Disruption Budgets: The Safety Net You Need
Here's where most people screw up.
They set disruption.consolidatePolicy: "WhenUnderutilized" and forget about budgets. Then a node gets consolidated mid-day and takes out a critical pod.
Karpenter disruption budgets are your escape valve. They cap how much node disruption can happen in a time window.
I learned this the hard way. In January 2026, we had a batch job that ran for 12 hours. I hadn't set a budget for batch jobs. Karpenter consolidated the node it was running on. Job failed at hour 8. Lost $400 in compute and 3 hours of data processing.
Now we use this pattern:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: batch
spec:
disruption:
consolidationPolicy: WhenUnderutilized
consolidateAfter: 10m
budgets:
- nodes: "10%"
duration: 1h
- nodes: "0%"
duration: 23h
The first budget allows only 10% node turnover per hour. The second budget blocks all disruption for 23 hours (effectively a disruption-free window for batch jobs). This is the pattern recommended in Top 18 Kubernetes Cost Optimization Strategies in 2026.
Karpenter disruption budgets cost optimization isn't just a feature — it's the knob that lets you trade savings for safety. Crank it up for stateless web apps, down for stateful workloads.
When On-Demand Wins
Contrarian take: on-demand isn't dead.
There are three cases where I tell clients to stick with on-demand:
-
GPU workloads with long training runs — Spot GPU prices can spike 3x during runs. If your training lasts 48 hours and you get interrupted at hour 44, the savings aren't worth the restart. Use on-demand for training, spot for inference.
-
Workloads that can't handle even short disruptions — Real-time trading systems, medical device data pipelines, etc. Even with disruption budgets, there's a tiny window where traffic could drop. Some compliance requirements forbid spot.
-
Highly stateful workloads with local storage — StatefulSets with persistent volumes that don't support cross-zone replication. If the node goes down, you lose the data. Yes, you can use EBS snapshots. But the complexity cost often outweighs the savings.
Cast AI vs ScaleOps vs StormForge vs Kubecost points out that many organizations over-provision spot and then burn engineering time handling failures. A mixed strategy — say 70% spot, 30% on-demand — is usually optimal.
At SIVARO we run our core API gateway on on-demand (it's tiny, costs $200/month). Everything else is spot. That's a 99.5% spot ratio. It works because we designed for failure.
Real Numbers: What We Saw at SIVARO
Let me give you the actual P&L from our main production cluster (us-east-1, July 2026).
Before Karpenter (July 2025):
- Nodes: 180 (all on-demand)
- Instance types: m5.xlarge, c5.2xlarge
- Cost: $76,400/month
- Utilization: 23% CPU, 41% memory
After Karpenter with spot + bin packing (July 2026):
- Nodes: 112 (96 spot, 16 on-demand fallback)
- Instance types: mixed (m5, m6i, c6i, r5)
- Cost: $31,200/month
- Utilization: 67% CPU, 72% memory
That's a 59% reduction. Over $45K/month saved.
The on-demand fallback nodes are used when spot prices exceed our threshold (we set max spot price to on-demand). In practice, those 16 nodes are rarely all active. They're a buffer for price spikes.
Kubernetes Cost Optimization: A 2026 Guide to Reducing ... confirms that 50-60% savings are typical for organizations that fully adopt Karpenter spot-first strategies.
But here's the catch I don't see people talking about: the savings compound. Less nodes means less monitoring overhead, less networking complexity, fewer security patches. Our DevOps team reduced from 4 people to 2.5 (one part-time). Hard to quantify but real.
Configuring Karpenter for Spot Dominance
You need a NodePool that defaults to spot and only falls back to on-demand when spot is unavailable or too expensive.
Here's our production config (simplified):
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
- key: karpenter.k8s.aws/instance-hypervisor
operator: Exists
nodeClassRef:
name: default
limits:
cpu: 1000
disruption:
consolidationPolicy: WhenUnderutilized
consolidateAfter: 1m
budgets:
- nodes: "20%"
The key here: karpenter.sh/capacity-type with values containing both spot and on-demand. Karpenter will try spot first. If spot is unavailable (e.g., a specific instance family has no capacity), it falls back to on-demand.
You can tune this further with price thresholds:
yaml
spec:
template:
spec:
karpenter.sh/spot-price-capacity-type: "on-demand"
# Ignore spot if price > on-demand
But I've found that setting explicit max prices is fragile. Better to let Karpenter use the on-demand fallback automatically.
For bin packing, enable consolidation with WhenUnderutilized and a short consolidateAfter (1 minute is fine for most workloads). Karpenter will constantly try to reduce the node count.
Pro tip: set consolidateAfter: 5m for bursty workloads to avoid oscillation.
The Tooling Ecosystem
You can't just flip a switch. You need visibility.
In 2026, the Kubernetes cost optimization tooling is mature. Top 10 Kubernetes Cost Optimization Tools for 2026 lists Cast AI, ScaleOps, Kubecost, and Spot.io as the main players.
We use Kubecost for allocation analysis (showing which team spent what) and Cast AI for real-time spot market data. ScaleOps offers a similar Karpenter-native optimization layer — it watches your actual resource utilization and recommends instance type changes.
The 6 Best Kubernetes Cost Optimization Tools for 2026 - Zesty breaks down which tools work best with Karpenter. Short answer: any of them work, but Cast AI has the deepest spot integration because they used to be a pure spot broker.
You don't need these tools. Karpenter's built-in metrics (via Prometheus) give you node count, spot price trends, and consolidation events. But if you're managing 10+ clusters across multiple regions, you'll want one.
FAQ
What's the actual average savings using Karpenter with spot vs on-demand?
Based on our data and industry reports, expect 40-60% savings on compute. Your mileage varies based on bin packing efficiency and spot availability in your region. us-east-1 and eu-west-1 have the best spot markets — you'll save more there. ap-southeast-1 (Singapore) has worse spot availability; I'd cap spot ratio at 50%.
How do I handle pods that can't be interrupted?
Label those pods with karpenter.sh/do-not-evict: "true". Karpenter respects this label during consolidation and won't move the pod. Combine with a NodePool that has disruption budgets set to nodes: "0%" for those workloads.
Can I mix spot and on-demand on the same node?
No. A node is either spot or on-demand. But Karpenter can schedule pods from different workloads onto the same node if they're compatible. You'll have nodes of both types in your cluster simultaneously.
Does Karpenter support GPU spot instances?
Yes. We run A10G spot instances for inference. The price is 50-65% below on-demand. But you need to set karpenter.sh/capacity-type: spot explicitly and accept that GPU spot availability is lower. We recommend having an on-demand GPU fallback or using a multi-region strategy.
How often does Karpenter consolidate nodes?
By default, it checks every minute. If it finds a cheaper instance type or fewer nodes that can fit your pods, it will initiate a consolidation. With disruptive budgets, you can slow this down. We run with consolidateAfter: 5m in production — consolidations happen a few times per hour.
Is it true Karpenter works with any cloud provider?
Karpenter only supports AWS natively. There are community forks for GCP and Azure (Karpenter + Cloud Provider Azure is experimental). If you're multi-cloud, you'll need separate tooling for each provider. I'd consolidate to one cloud for Karpenter to work best.
What happens when spot prices spike above on-demand?
Karpenter can be configured with a max spot price (e.g., 90% of on-demand). If spot exceeds that, Karpenter stops using spot and launches on-demand nodes instead. We don't use this — we let Karpenter fall back to on-demand naturally by listing both capacity types. The risk of spot exceeding on-demand for sustained periods is low (happens maybe 2-3 times per year per region).
How do I calculate the ROI of switching to Karpenter spot?
Simple formula: (on-demand cost - spot cost) * node count - Karpenter management overhead (≈ $0). The only real cost is the time to migrate your NodePool configs and test disruption budgets. For most clusters that's a 2-3 day project. Payback is within the first month.
The Bottom Line on Karpenter Spot vs On-Demand Cost
Karpenter transforms spot instances from a risk into a strategy. The cost difference is massive — 40-60% off your compute bill. But only if you embrace bin packing and disruption budgets.
Most organizations I talk to are still running Cluster Autoscaler with on-demand nodes. They're leaving 50% on the table. The migration from Cluster Autoscaler to Karpenter takes a week. The savings start the following month.
I've written this in July 2026. By now, the industry should have moved. But it hasn't. Because most teams don't trust spot. They don't trust the bin packing algorithm. They don't trust disruption budgets.
They should.
At SIVARO we run on 96% spot. Six months of zero production incidents. $45K/month saved. That's a new hire we didn't need to lay off. That's breathing room in the budget for a project we postponed.
Stop treating spot as a gamble. Start treating it as your default. Karpenter makes it safe. Your bank account will thank you.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.