Karpenter vs Cluster Autoscaler: Which Saves More Money?
Cluster Autoscaler and Karpenter both answer the same page: pods are Pending, add a node. The difference is everything else — which node, how fast, and what happens to the fleet when demand falls. That last part is where the money is, and it is why this comparison is really a cost comparison: one of these tools passively tolerates an oversized fleet, and the other actively shrinks it. Here is how they differ in practice, what the savings actually come from, and the cases where the classic autoscaler is still the right choice.
How each one thinks
Cluster Autoscaler operates on node groups — pre-defined sets of identical instances (ASGs on AWS, VMSS on Azure, MIGs on GCP). When pods are unschedulable, it simulates whether growing one of your existing groups would help, and increments that group's desired count. When a node has been underutilized for a while and its pods fit elsewhere, it may remove it. The key constraint: it can only ever produce the node shapes you defined up front. If your groups are m5.2xlarge, a pod needing one CPU gets a slice of an m5.2xlarge — and the other seven cores wait for friends.
Karpenter skips node groups entirely. It reads the actual resource requests, affinities and tolerations of pending pods and provisions instances directly — choosing from hundreds of instance types the cheapest combination that fits, launching in tens of seconds rather than waiting on an ASG. NodePools set the boundaries (architectures, capacity types, size ranges); within them, Karpenter decides per scheduling event. The fleet becomes heterogeneous by design: big nodes when bin-packing favors them, small ones for the stragglers, Spot wherever you allow it.
Consolidation: where the savings actually come from
Provisioning speed is nice; consolidation is the feature that cuts bills. With
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1mKarpenter continuously asks two questions: can this node's pods fit on the remaining fleet (delete it), and could this node be replaced by a cheaper one that still fits its pods (replace it)? That second move — replace with cheaper — has no equivalent in Cluster Autoscaler at all, which only removes nodes that fall below a utilization threshold and never reshapes the fleet. In practice this is the mechanism that converts right-sizing work into actual node reductions: shrink your requests and within minutes Karpenter drains the slack away. Shrink requests under Cluster Autoscaler and you often just get emptier nodes.
Consolidation is disruption by design, so make it safe before making it aggressive: set PodDisruptionBudgets on everything replicated, use consolidateAfter to stop churn during deploy storms, and annotate genuinely immovable pods with karpenter.sh/do-not-disrupt.
Spot handling
Both can run Spot node groups, but the ergonomics differ sharply. With Cluster Autoscaler you build Spot node groups yourself, choose their instance-type mix, and typically add the AWS Node Termination Handler to catch interruptions. Karpenter treats Spot as a first-class capacity type: allow ["spot", "on-demand"] in a NodePool and it diversifies across pools, falls back to on-demand when Spot is scarce, and handles the two-minute interruption notice natively — cordoning, draining and pre-provisioning replacement capacity. Spot at 60–90% off on-demand is one of the biggest levers in Kubernetes cost work, and Karpenter lowers its operational price to nearly zero.
Side-by-side
| Dimension | Cluster Autoscaler | Karpenter |
|---|---|---|
| Provisioning model | Grows/shrinks pre-defined node groups | Provisions instances directly per pending pods |
| Instance selection | Fixed shapes you defined up front | Cheapest fit from the full catalog, per event |
| Scale-up speed | Minutes (ASG/VMSS round-trip) | Tens of seconds |
| Consolidation | Removes underutilized nodes only | Deletes and replaces-with-cheaper, continuously |
| Spot support | DIY node groups + termination handler | Native: diversification, fallback, interruption handling |
| Cloud support | Every major cloud and many others | AWS (mature); Azure via AKS node autoprovisioning |
| Cost impact | Prevents gross over-provisioning | Actively minimizes fleet cost; 20–40% typical vs static groups |
When Cluster Autoscaler is still the right call
- You are not on AWS. On GKE, node auto-provisioning plus the built-in autoscaler covers most of the same ground; on other clouds and on-prem, Cluster Autoscaler's breadth of providers is unmatched. (AKS users increasingly get Karpenter's behavior via node autoprovisioning.)
- Compliance pins your instance shapes. If every node must be an identical, pre-approved image and size, Karpenter's flexibility is a feature you cannot use.
- Highly static workloads. A fleet that never changes shape has little for consolidation to do; the migration effort may not pay back.
- Extreme churn sensitivity. Consolidation moves pods. Well-set PDBs make that safe, but a platform full of fragile singletons will feel it — fix the workloads first.
Migrating without drama
- Set PodDisruptionBudgets and honest resource requests first — Karpenter amplifies whatever your requests say, including the lies.
- Install Karpenter alongside Cluster Autoscaler with a conservative NodePool (on-demand only, consolidation off).
- Shift one workload class over (taint the old groups or use nodeSelectors), watch for a week.
- Enable consolidation, then Spot for the fault-tolerant tiers.
- Shrink the legacy node groups to a minimal on-demand floor — or zero — and retire Cluster Autoscaler.
Autoscaling is one lever of several
Karpenter converts slack into savings — but the size of the slack is set by your resource requests, your Spot mix, and your idle environments. Estimate the whole opportunity in sixty seconds, or get it measured for free.
Frequently asked questions
Does Karpenter replace Cluster Autoscaler?
On AWS, effectively yes — Karpenter does everything Cluster Autoscaler does (add nodes for pending pods, remove empty ones) plus instance selection from the full EC2 catalog, aggressive bin-packing and active consolidation. AWS positions it as the recommended approach for EKS. Off AWS the picture differs: Karpenter providers for Azure (AKS node autoprovisioning) exist, but GKE teams and most non-AWS clusters still run Cluster Autoscaler or their platform equivalent.
Does Karpenter actually save money?
Yes, in two ways Cluster Autoscaler structurally cannot: it selects the cheapest instance types (including Spot pools) that fit each batch of pending pods instead of one fixed node shape, and its consolidation continuously replaces underutilized nodes with fewer or cheaper ones. Teams migrating from static node groups commonly report 20–40% lower compute cost — most of it from consolidation converting slack into removed nodes.
Can Karpenter and Cluster Autoscaler run together?
Yes, and it is the standard migration path: keep Cluster Autoscaler managing your existing node groups while Karpenter handles new capacity, then shrink the node groups as confidence grows. Make sure they do not manage the same nodes — Karpenter provisions its own instances outside the autoscaling groups Cluster Autoscaler watches, so a clean split is natural.
Karpenter is step two of a bigger playbook: right-sizing comes first (consolidation can only reclaim what your requests admit is spare), and the rest of the levers — Spot strategy, Graviton, Savings Plans, storage and data-transfer hygiene — are covered in how to cut your EKS bill and the complete Kubernetes cost optimization playbook.
Related: Kubernetes cost
- Kubernetes Cost Optimization: The Complete Playbook
- Kubernetes Cost Optimization Checklist: 24 Checks That Cut Your Bill
- How to Cut Your EKS Bill: An AWS-Specific Playbook
- EKS vs AKS vs GKE: Which Should You Choose in 2026?
- Managed Kubernetes vs In-House: The Real Cost Comparison
- Cloud Cost Waste Calculator — estimate your overspend in 60 seconds
- Free DevOps audit — get your real waste number, measured
Need this done, not just read about?
Deplyra builds, ships and runs exactly this in production — as code, with GitOps, handed over documented.
Start a project →