Kubernetes Node Autoscaling Cheapest Strategy: Karpenter

Stop 3AM Pages

Free K8s Audit

Most teams get Kubernetes node autoscaling wrong in the same boring way. They pick a node pool, set a static size, and let Cluster Autoscaler babysit an ASG like it's 2019. Then the bill shows up.

I've run this experiment across SIVARO's own infra and for four clients between Q4 2025 and now. The pattern is consistent: if your goal is the kubernetes node autoscaling cheapest strategy, Karpenter wins — but only if you configure consolidation, spot, and instance flexibility correctly. Miss any of those three, and you've just added complexity without saving money.

Here's what this article covers: what Karpenter actually does, why it undercuts the old model, how to configure it for minimum cost, and where it still burns you. No sales pitch. Just the numbers we've measured and the tradeoffs that bit us.

What Karpenter Actually Does (And Why It's Not "Cluster Autoscaler 2.0")

Karpenter is a node lifecycle controller. That's the whole thing.

It watches for pods that can't schedule, looks at their resource requests, node selectors, taints, and topology constraints, and then calls the cloud provider API directly to provision a node that fits. No node groups. No ASG intermediary. No predefined instance types.

Cluster Autoscaler works differently. It waits for an ASG to scale. You've already told AWS what instance types live in that group and how big it can get. CA just nudges the number up or down. That's the constraint. You're stuck with whatever shapes you pre-approved.

Karpenter inverts it. You tell it what your workloads need, and it picks the cheapest instance that satisfies those needs from the entire catalog available in that region and AZ.

One of my engineers said it best last year: "Cluster Autoscaler is a thermostat. Karpenter is a procurement agent."

The operational consequence is bigger than it sounds. With CA, a team usually ends up with 4-6 node groups: general purpose, memory optimized, GPU, spot, on-demand fallback. Each one is a separate ASG, separate config, separate thing to break. With Karpenter you have one NodePool and one EC2NodeClass per environment, usually.

The Real Cost Math: Why Consolidation Is the Whole Game

Here's the part most articles bury. The cheapest instance isn't the win. The win is that Karpenter repacks your cluster continuously.

Karpenter consolidates. It looks at running nodes, simulates whether their pods could fit on other nodes, and if the answer is yes, it cordons the expensive/empty node, drains it, and terminates it. This runs every few seconds. Cluster Autoscaler does something similar but slower and with less freedom because it's constrained to the node groups you defined.

I ran a controlled test in March 2026 on a 40-node EKS cluster running a mixed workload (API services, batch jobs, a couple of stateful sets). Same workloads, same traffic pattern, two weeks each.

Metric	Cluster Autoscaler	Karpenter (consolidation on)
Avg node count	38	29
Monthly EC2 cost	$11,840	$6,210
Pod evictions/day	14	21
Pending pod latency p99	42s	18s

That's a 47% drop. Not magic — most of it came from Karpenter's willingness to run a single big node instead of three medium ones, and from aggressive scale-down of underused nodes.

But note the eviction column. Karpenter consolidated harder, which means more pods got shuffled. If your workloads can't tolerate that, you feel it.

Karpenter vs Karpenter Cloud Provider Cost: Don't Confuse the Two

Naming here is genuinely confusing, so let me clear it up.

There's the open source Karpenter project. There's also a managed offering from each cloud: EKS Auto Mode with Karpenter on AWS, AKS Node Auto Provisioning with Karpenter on Azure (GA'd in 2025), and GKE has its own thing that isn't Karpenter but solves the same problem.

The karpenter vs karpenter cloud provider cost comparison isn't about features — it's about what you pay on top of EC2.

Open source Karpenter: you pay for the EC2 nodes, the control plane, and the tiny compute your Karpenter controller pods use (roughly $30-60/month per cluster on a couple of small instances). That's it.

Managed Karpenter (like EKS Auto Mode): AWS charges a per-cluster hourly fee. As of writing, it's in the neighborhood of $0.10/hour per cluster, so ~$73/month. That's before nodes. You're paying for the convenience of not running the controller, not for the autoscaling itself.

Azure's AKS Node Auto Provisioning is currently free with the cluster — no extra Karpenter charge.

Which should you pick? My honest answer: for a single cluster, open source Karpenter. You install it in 20 minutes and save the fee. For 20+ clusters across an org where nobody wants to own the controller lifecycle, the managed version pays for itself in reduced toil cost. We run open source in ours and managed in one client's 60-cluster fleet for this exact reason.

One more thing worth flagging: the biggest cost difference isn't the Karpenter fee at all. It's spot adoption. Managed Karpenter has better defaults for spot interruption handling via the native AWS integration. If you're scared of spot and therefore stay on-demand, you're paying 60-70% more than you need to regardless of which Karpenter you run.

Configuring for Minimum Cost: The Actual YAML

Let me stop talking and show you what we actually deploy. This is stripped of our internal naming, but the structure is real.

yaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      labels:
        intent: general
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["5"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: 720h
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m
    budgets:
      - nodes: "10%"
  limits:
    cpu: "1000"
    memory: 2000Gi

The key lines:

capacity-type: ["spot", "on-demand"] — Karpenter prefers spot when the pod tolerates it, falls back to on-demand when it doesn't (or when spot capacity is unavailable). Don't just list spot. You want the fallback.
instance-category: ["c", "m", "r"] — compute, general, memory. Wide enough to give Karpenter options, narrow enough to exclude weird shapes (burstable t instances crush latency for production services).
consolidationPolicy: WhenEmptyOrUnderutilized — this is the money-maker. WhenEmpty only removes empty nodes and is too conservative. WhenEmptyOrUnderutilized will move pods to kill a half-empty node.
consolidateAfter: 1m — aggressive but not reckless. We used 30s initially and hit churn. 5m was too slow. One minute is the sweet spot for us.
budgets — caps how much Karpenter can disrupt at once. Start at 10%, go to 20% only if your workloads are stateless.

The EC2NodeClass is short but has one critical field:

yaml
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  role: KarpenterNodeRole-prod
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: prod-cluster
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: prod-cluster
  instanceStorePolicy: RAID0
  metadataOptions:
    httpTokens: required
    httpPutResponseHopLimit: 2

Nothing fancy. instanceStorePolicy: RAID0 matters if you're doing batch work — it gives you free local NVMe that isn't billed. Only applies to instance families that have instance store.

Spot, ARM, and the Multiplier Effect

Running instance diversification alone isn't enough. If you only allow m7i.large, you'll get capacity failures during spot rebalancing and default to on-demand. Two changes move the needle most:

Enable ARM64. Graviton is 20-40% cheaper per hour than equivalent x86 in most regions. In our test, moving 70% of stateless services to ARM cut compute cost another 22% on top of consolidation. The blocker is always the same: a handful of images that don't have multi-arch builds. Fix those, and you unlock it.

Let Karpenter pick from a wide family list. We allow c, m, r categories plus g (Graviton) via the arch selector, generation 6+. That's hundreds of instance types. Karpenter picks the cheapest one that fits each pending pod's resource requests. The wider the buffet, the more likely a spot node is available.

A client of ours — a fintech in Bengaluru — did exactly this in January 2026 and cut their EKS compute bill from ~$22K to ~$9.4K monthly over six weeks. Same workloads, same SLOs. The only change was Karpenter config plus a Graviton migration for two services that were x86-only.

Kubernetes Node Autoscaling Cost Comparison 2026: Karpenter vs the Alternatives

Here's my honest kubernetes node autoscaling cost comparison 2026 picture, drawn from our own clusters and clients:

Karpenter with spot + consolidation + ARM: baseline. ~47% lower than Cluster Autoscaler in our tests.
Karpenter on-demand only: still ~25% cheaper than CA due to right-sizing and consolidation, but you leave the spot savings on the table.
Cluster Autoscaler with mixed node groups: ~10-15% cheaper than static provisioning, but you fight limits, and drift is constant.
GKE Autopilot: comparable to well-tuned Karpenter on cost, but you don't control the bin-packing. Some workloads end up more expensive because GKE's pods are opinionated. Good default if you're OK with the abstraction.
Static nodes with HPA only: most expensive by a wide margin. Don't.

And the thing nobody likes to say: the biggest cost contributor is still your workload choice. If a service needs 2 vCPU and 8 GiB to serve 100 RPS, no autoscaler saves you. Karpenter gives you the cheapest shape, not the cheapest code.

The Tradeoffs That Bite

Karpenter isn't free of pain. I want to be honest about where it's hurt us.

Churn. Aggressive consolidation moves pods. If a service has initialization that takes 90 seconds, move it 20 times a day and you'll feel it. We gate those services with a do-not-disrupt annotation so Karpenter skips their nodes.

Pod disruption budgets matter more. If your PDB is misconfigured (or missing), consolidation will drain a node down to zero replicas of an app. We hit that once with a background queue worker. Never again.

Debugging is a different shape. Cluster Autoscaler has a well-worn path for "why isn't my cluster scaling?" Karpenter uses events on NodeClaim objects and it takes a week to build the muscle memory. Once you have it, it's better — you can see the exact instance type Karpenter picked and why.

Cost attribution. Because nodes have no stable group, FinOps folks who rely on autoscaling-group tags get grumpy. Use karpenter.sh/nodepool in your cost allocation instead. There's a whole workflow here — I might write about it next.

Spot interruptions. They happen. Karpenter's graceful handling helps, but you still need apps that tolerate SIGTERM like adults. If your app doesn't, don't use spot.

Where to Start, If You're Starting Today

If I were standing up a new EKS cluster on September 17, 2026, here's the order:

Install Karpenter with one NodePool. Don't split by team or workload class yet.
Turn on consolidation with consolidateAfter: 1m and a 10% budget.
Migrate stateless services to ARM. Stop when you hit the first one that can't.
Move compatible workloads to spot with the pod-level capacity-type preference.
Add finops attribution via pod labels before your finance team asks.
Tune. Wait a month. Look at the actual instance mix Karpenter chose before you second-guess it.

Step 6 is the one most teams skip. They tune once, walk away, and miss the drift. Karpenter's decisions change as your workloads and spot markets change. It's a system you operate, not a config you set.

FAQ

Is Karpenter always cheaper than Cluster Autoscaler?
No. On a small stable cluster with steady loads, the difference can be a wash and the extra complexity isn't worth it. Karpenter shines when workloads vary and you have headroom to consolidate. Below ~15 nodes, Cluster Autoscaler is often fine.

Do I need spot to save money with Karpenter?
You don't need it, but you leave big savings. In our tests, spot was worth another 30-40% on top of consolidation. If your apps handle interruption, use it. If not, don't fake it.

What's WhenEmptyOrUnderutilized actually do differently?
WhenEmpty only terminates nodes with zero pods. WhenEmptyOrUnderutilized will move pods off a node if they fit elsewhere, then terminate it. That's where the biggest savings live.

Should I use open source Karpenter or the managed AWS version?
Open source for 1-5 clusters. Managed (EKS Auto Mode) past that if you don't want to own the controller. The feature gap has narrowed a lot through 2026. The per-cluster fee is small.

How does Karpenter handle Windows nodes?
It supports them via a separate NodePool and EC2NodeClass. It works, but Windows AMIs are heavier and consolidation is less aggressive. Don't expect the same savings you see on Linux.

Can Karpenter run alongside Cluster Autoscaler?
You can, but don't. Pick one. Running both creates contention and confusing scale events. Migration is a one-way door — do it in a maintenance window.

What metric should I watch after switching?
Two: average node utilization (should rise) and pod eviction rate (should stay within your error budget). If utilization goes up and evictions go up too, tighten your disruption budget.

Does the kubernetes node autoscaling cheapest strategy karpenter approach work on Azure and GCP?
Azure has Karpenter via AKS Node Auto Provisioning — works well. GCP doesn't have Karpenter; GKE Autopilot and the newer node auto-provisioning features occupy the same space. The strategy is portable; the tool isn't always.

Conclusion

The kubernetes node autoscaling cheapest strategy karpenter comes down to three configuration decisions: enable spot with on-demand fallback, allow a wide instance menu including ARM, and turn on WhenEmptyOrUnderutilized consolidation with a sane disruption budget. Do those and you're looking at roughly 40-50% off your compute bill compared to a conservative Cluster Autoscaler setup. Skip them and you've just moved complexity around without moving money.

I've been wrong about this twice. First, I thought Karpenter was overhyped — turned out I was reading old benchmarks. Then I thought consolidation was too risky for production — turned out my PDBs were bad, not the tool. The autoscaler didn't need to be smarter. My cluster did.

Run the experiment on one cluster for a month. Look at the NodeClaim events. Look at the bill. The number will make the decision for you.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.

Part of our Kubernetes series — see every guide in this cluster. Fighting this in production? Explore MVP to Production.