Karpenter Spot Instance Cost Savings Kubernetes: The Only Guide You Need
I'll tell you something that still gets me sideways looks at conferences.
In early 2025, I watched a team at a SaaS company burn $380,000 on Kubernetes in three months. They were running 90% on-demand instances. Their cluster autoscaler was doing its job — technically. But their monthly AWS bill looked like someone was mining Bitcoin on company time.
I sat down with their VP of Engineering. "You know Karpenter can cut this by 60% with spot instances, right?"
He didn't.
Six weeks later, they were spending $127,000. Same workloads. Same performance. Karpenter spot instance cost savings Kubernetes — that's not marketing fluff. That's real money.
I'm Nishaant Dixit. I run SIVARO, where we build data infrastructure and production AI systems. We've been running Kubernetes in production since 2019. We've seen the hype cycles. We've survived the exodus. And we've squeezed every dollar out of cloud compute that physics allows.
This guide is everything I wish someone had handed me before we started.
Why Spot Instances Still Scare People (And Why They Shouldn't)
Most engineers I talk to have the same reaction when I mention spot instances.
"Won't my workloads just get killed randomly?"
That's the old fear. It's valid — but mostly outdated.
AWS spot instances have a 2-minute termination notice. Kubernetes handles pod evictions gracefully if you configure it right. The real problem isn't reliability — it's predictability. You need to know your workloads can survive interruptions.
Here's what we've learned from running 200+ clusters across multiple accounts:
- Spot instances are 60-90% cheaper than on-demand
- AWS rarely reclaims more than 5% of spot capacity on any given day
- Most terminations happen during specific windows (us-east-1 between 2-4 PM EST is notorious)
- Stateless workloads are almost always fine
The companies failing with spot? They treat spot like on-demand. That's the mistake.
What is Karpenter, Really?
Karpenter is an open-source node provisioning tool for Kubernetes. It launched in 2021. It's now maintained by AWS.
But let's be honest — that description is useless. Here's what Karpenter actually does:
It watches your pods. When a pod can't schedule, Karpenter looks at your requirements (CPU, memory, GPU, topology) and launches exactly the instance you need. Instantly. Not "in a few minutes" — in seconds.
The Cluster Autoscaler (the old way) works like this: "I need more capacity. Let me see what instance types my ASG allows. Let me add one node." It's slow. It's rigid. It wastes money because you pre-define instance families.
Karpenter works like this: "You need 4 vCPUs and 16GB RAM. Here's an m7i. Or a c7a. Or a r7g. Whichever is cheapest right now."
It's not incremental improvement. It's a different philosophy.
Karpenter Spot Instance Cost Savings Kubernetes: The Math
Let me give you concrete numbers.
We run a customer's ML inference pipeline. 200 pods continuously. Each pod needs 2 vCPUs, 8GB RAM. No GPUs.
Full on-demand (c7i.large at $0.085/hr):
- 100 nodes × $0.085 × 730 hours = $6,205/month
Spot (same instance type, ~70% discount):
- $1,862/month
Karpenter with spot and instance diversity (mixes m7i, c7a, r7g spots):
- $912/month (because Karpenter aggressively finds the cheapest combination)
That's an 85% reduction from on-demand. And we got better performance because we weren't locked into one instance type.
But here's the part nobody talks about: the savings compound.
When you use Karpenter spot instance cost savings Kubernetes, you don't just save on compute. You save on:
- Reserved instance overhead (you buy fewer RIs)
- Node management overhead (fewer node groups to maintain)
- Scaling inefficiency (Karpenter reacts in seconds, not minutes)
Configuring Karpenter for Maximum Spot Savings
Most people configure Karpenter wrong. They copy-paste a config they found on GitHub and wonder why their costs didn't drop.
Here's our production configuration:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "m7i.large"
- "m7i.xlarge"
- "c7a.large"
- "r7g.large"
- "c6i.large"
- "m6a.large"
nodeClassRef:
name: default
limits:
cpu: 1000
memory: 4000Gi
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
Notice what I'm not doing:
- I'm not specifying every instance family (Karpenter does that automatically)
- I'm not setting budgets or fallbacks (trust the defaults)
- I'm not using taints I don't need
The three things that matter:
-
consolidationPolicy: WhenUnderutilized— This is the magic. When a node is underused, Karpenter moves the pods and terminates the node. This is where most savings come from. -
Instance diversity — I give Karpenter a broad set of instance types. It'll pick the cheapest valid option at launch time. If spot prices spike for one type, it switches to another.
-
No hard node limits per node pool — Let Karpenter use as many instance types as possible. Don't restrict yourself to "things I recognize."
Handling Spot Interruptions Without Panic
I said earlier the fear is outdated. But you still need to handle interruptions properly.
Here's our pod disruption budget:
yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: app-pdb
spec:
minAvailable: 80%
selector:
matchLabels:
app: my-app
And here's the critical piece — our termination handler:
yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: karpenter-handler
spec:
selector:
matchLabels:
name: karpenter-handler
template:
spec:
containers:
- name: handler
image: aws-node-termination-handler:latest
env:
- name: "GRACE_PERIOD"
value: "90s"
The key insight: Don't try to make spot work for everything.
Stateful workloads with persistent volumes? Don't run those on spot. Use on-demand or use EBS-backed spot with proper backup. We've seen teams lose data because they put stateful sets on spot without thinking through the pattern.
But stateless apps? Batch jobs? CI/CD runners? Web servers? Spot is perfect.
Why People Are Leaving Kubernetes (And Why Spot Instances Aren't the Reason)
You've probably seen the articles. Why Companies Are Leaving Kubernetes. I Deleted Kubernetes from 70% of Our Services in 2026 — Saved $416K. We're Leaving Kubernetes.
I've read them all. Most of them have a point — but they're blaming the wrong thing.
Companies aren't leaving Kubernetes because Kubernetes is bad. They're leaving because they used Kubernetes wrong. They ran it with 10-node clusters. They used the default Cluster Autoscaler. They paid for on-demand instances they didn't need. They overprovisioned everything.
Kubernetes isn't dead, you just misused it — that article nails it. The problem isn't the tool. It's the usage pattern.
Spot instances don't fix bad architecture. But they do fix the "Kubernetes is too expensive" complaint. Because if your Kubernetes cluster costs are high and you're not using spot, you're leaving 60-70% on the table.
Common Mistakes with Karpenter Spot Instances
Mistake 1: Not using consolidation
Without consolidation, you're just using Karpenter as a faster Cluster Autoscaler. You lose the biggest benefit: automatic right-sizing. We've seen clusters where consolidation alone cut node count by 40%.
Mistake 2: Setting unrealistic spot budgets
AWS spot pricing fluctuates. If you set interruptionPolicy: Budget with a tight budget, Karpenter will just skip spot and launch on-demand. Then you wonder why costs didn't drop. Let spot pricing be volatile. That's the trade-off.
Mistake 3: Not testing termination behavior
I can't count how many teams I've seen deploy Karpenter, pat themselves on the back for 60% savings, then three weeks later get hit with a spot reclamation and lose pods. Test it. Terminate instances manually. Watch what happens.
Advanced: Using Karpenter with Spot for GPU Workloads
This is where things get interesting — and more expensive.
GPU instances on spot? Yes, it works. But the dynamics are different.
AWS reclaims GPU spots more aggressively. The discount is smaller (40-50% instead of 70%). And you need to handle the case where spot GPU availability drops to zero.
Here's what we do:
yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: gpu-spot
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot"]
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "g5.xlarge"
- "g5.2xlarge"
- "p3.2xlarge"
nodeClassRef:
name: gpu
disruption:
consolidationPolicy: WhenUnderutilized
limits:
cpu: 500
memory: 2000Gi
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: gpu-ondemand-fallback
spec:
template:
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "node.kubernetes.io/instance-type"
operator: In
values:
- "g5.xlarge"
- "g5.2xlarge"
nodeClassRef:
name: gpu
disruption:
consolidationPolicy: WhenUnderutilized
weight: 10 # Lower weight so Karpenter tries spot first
The two-pool approach means: Karpenter tries spot first (because it's weighted higher). If no spot capacity, it falls back to on-demand. You never get stuck.
But be honest with yourself about the savings. GPU spot saves money but not as dramatically as CPU spot. Budget accordingly.
Monitoring Karpenter Spot Savings
I'm a "measure everything" person. If you can't see your savings, you can't optimize them.
Here's what we track:
- Spot usage rate: What % of nodes are spot? Target > 90%
- Consolidation events: How often is Karpenter consolidating? High = good
- Interruption rate: How often are spot instances reclaimed? Should be < 5%
- Cost per vCPU hour: This is the real metric. Track it over time.
We use a simple dashboard scrape from the Karpenter metrics endpoint:
karpenter_nodes_total{capacity_type="spot"}
karpenter_consolidation_actions_total
karpenter_interruption_actions_total
If your spot usage rate is below 70%, you're leaving money on the table. Fix it.
When NOT to Use Karpenter Spot Instances
I've been doing this long enough to know when a tool is wrong for the job.
Don't use Karpenter spot instances if:
- Your workloads can't tolerate rescheduling (stateful databases, real-time streaming pipelines)
- You have regulatory requirements that mandate on-demand (certain fintech workloads, some healthcare)
- You're running fewer than 5 nodes (the overhead of managing spot interruptions isn't worth it)
- Your team can't handle 2-minute termination windows (some teams just can't — that's fine, use on-demand)
The Why Companies Are Leaving Kubernetes article mentions complexity as a reason. They're right — if your team can't handle the operational load, Karpenter won't fix that. Spot instances add complexity. Don't add them unless you can handle it.
FAQ
Q: Does Karpenter work with EKS only, or can I use it with self-managed Kubernetes?
A: Karpenter works best with EKS. You can run it on self-managed clusters, but you lose some integration. We've tested both. EKS is cleaner.
Q: How much time does it take to set up Karpenter?
A: First time? 2-4 hours. After you've done it once, about 30 minutes per cluster. The learning curve is real but shallow.
Q: Can I mix spot and on-demand in the same node pool?
A: Yes. Use the karpenter.sh/capacity-type requirement with both spot and on-demand values. Karpenter prioritizes spot but falls back to on-demand.
Q: What happens if all spot capacity is reclaimed simultaneously?
A: This almost never happens. But if it does, Karpenter will launch on-demand instances to replace them. Your workloads might experience brief disruption, but they'll recover.
Q: Is Karpenter free?
A: Yes. It's open-source. You pay for the EC2 instances it launches — nothing for Karpenter itself.
Q: Does Karpenter work with Fargate?
A: No. Karpenter manages EC2 nodes. If you want Fargate, use EKS with Fargate profiles. Different tool for a different job.
Q: How does Karpenter compare to Cluster Autoscaler for spot?
A: Cluster Autoscaler works with spot, but it's slower and less efficient. Karpenter launches instances in 15-30 seconds. Cluster Autoscaler takes 3-5 minutes. Karpenter also consolidates automatically. Cluster Autoscaler doesn't.
Q: Will AWS eventually build spot instance management into EKS natively?
A: They're moving in that direction. EKS auto mode (announced late 2025) includes some of this. But as of July 2026, Karpenter is still the best option for cost optimization.
The Bottom Line
Karpenter spot instance cost savings Kubernetes isn't a theory. It's a practice. We've done it. Our customers have done it. The numbers work.
Here's what I want you to take away:
- Configure Karpenter with
consolidationPolicy: WhenUnderutilized - Let it use as many instance types as possible
- Handle interruptions with proper PDBs and termination handlers
- Don't run stateful workloads on spot
- Measure your savings obsessively
Companies are leaving Kubernetes because they didn't optimize costs. Don't be one of them. Start with Karpenter and spot instances. You'll save 60-80% on compute. Your team will thank you. Your CFO will thank you.
And if someone tells you "we tried spot and it didn't work" — ask them if they used Karpenter. Because I bet they didn't.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.