TL;DR: Cluster Autoscaler scales pre-defined node groups (ASGs, MIGs, VMSSs) up and down and is the more portable, more conservative choice. Karpenter bypasses node groups entirely, calls the cloud provider API directly to launch exactly-sized nodes per pending pod, and is faster and cheaper on AWS — but it trades portability and some operational maturity for that speed. The right choice depends less on which tool is "better" and more on whether your infrastructure model can tolerate a controller that provisions nodes outside of your existing autoscaling groups.
Kubernetes node provisioning looks like a solved problem until you're running it at meaningful scale, and then the choice of how nodes get added and removed starts to matter a lot — for cost, for pod scheduling latency, and for how much operational surface area you're signing up to maintain. The two dominant options for AWS/EKS (and increasingly GCP/Azure) are Cluster Autoscaler, the long-standing Kubernetes SIG project, and Karpenter, AWS's newer node provisioning controller that has become the default in EKS Auto Mode.
They solve the same problem — add nodes when pods can't schedule, remove nodes when they're not needed — with fundamentally different architectures. This piece compares them at the architecture level: how each decides what to provision, how fast they act, what happens during spot interruptions, and where each one's failure modes show up.
Two different provisioning models
Cluster Autoscaler operates one level removed from actual nodes. It watches for unschedulable pods, then decides to increase or decrease the desired capacity of an existing node group — an AWS Auto Scaling Group, a GCP Managed Instance Group, or an Azure VMSS. The node group itself, not Cluster Autoscaler, is responsible for actually launching the EC2 instance, and the node group has a fixed instance type (or a small fixed set) declared ahead of time. Cluster Autoscaler's decision space is therefore constrained to whatever node groups you've pre-provisioned: if a pending pod needs a shape no registered group matches well, Cluster Autoscaler picks the smallest group that fits without exceeding it — which is frequently not a tight fit.
Karpenter skips the node-group abstraction entirely. It watches for unschedulable pods directly, computes the combined CPU, memory, and architecture requirements of everything pending, and calls the cloud provider API (EC2 RunInstances, effectively) to launch a node sized to match — selecting from the full range of instance types allowed by its NodePool configuration rather than a fixed pre-declared list. There's no ASG in between. This is the core architectural difference everything else follows from: Cluster Autoscaler scales a resource you already defined, Karpenter defines the resource on the fly.
# Karpenter NodePool — no fixed instance type, just constraints
apiVersion: karpenter.sh/v1
kind: NodePool
spec:
template:
spec:
requirements:
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["c", "m", "r"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
nodeClassRef:
name: default
disruption:
consolidationPolicy: WhenEmptyOrUnderutilizedProvisioning speed: this is where the gap is largest
Because Cluster Autoscaler goes through a node group, a scale-up event involves the autoscaler requesting a capacity increase, the ASG launching an instance, that instance booting, the kubelet registering, and the CNI plugin initializing — a chain with real latency at each step. Reported figures put a cold node's full readiness sequence (boot, kubelet registration, CNI init, image pull) at 3–4 minutes for something like an m5.xlarge on AWS, and testing on a 20-node simultaneous scale-out on EKS has shown node registration completing in roughly 7 minutes on average, since Cluster Autoscaler evaluates pending pods in a single loop iteration and then waits for the batch.
Karpenter, calling the EC2 API directly and skipping the ASG layer, has been benchmarked bringing nodes online in roughly 45–90 seconds. That's not a marginal difference — it's the gap between "a burst of traffic causes visibly degraded scheduling for several minutes" and "the burst is mostly absorbed before anyone notices."
For workloads with spiky, unpredictable demand (CI runners, batch jobs, autoscaling web tiers under traffic spikes), this latency difference is often the deciding factor by itself, independent of cost.
Cost efficiency: bin-packing vs. group-level sizing
Cluster Autoscaler's node-group model creates structural over-provisioning: because a group's instance type is fixed, a pod that needs 1.2 vCPU and 2GB of memory still consumes a full node slot sized for whatever the group's instance type provides, and any headroom on that node either goes unused or is filled opportunistically — it isn't actively optimized for.
Karpenter actively bin-packs: it evaluates the exact combined resource requirements of pending pods and picks the smallest instance type (from its allowed set) that satisfies them, which by design tends to minimize wasted capacity at launch time. It goes further with consolidation — a background process, controlled by disruption.consolidationPolicy, that continuously looks for opportunities to either delete now-empty nodes or replace an underutilized node with a smaller, cheaper one, respecting Pod Disruption Budgets. The default WhenEmptyOrUnderutilized policy means Karpenter is actively working to shrink your footprint even after the initial scale-up, not just reacting to new pending pods.
The practical effect reported across several benchmarks: switching from Cluster Autoscaler's node-group sizing to Karpenter with consolidation enabled reduces idle capacity noticeably (utilization commonly cited above 80% post-consolidation) without manual bin-packing tuning.
Spot instance handling
Both tools support spot instances, but the interruption-handling story differs. Karpenter has native, built-in handling for EC2 Spot interruption notices: when AWS signals an impending reclaim (the two-minute interruption warning), Karpenter watches for that event directly, cordons and drains the affected node proactively, and — critically — its NodePool starts provisioning a replacement as soon as the interruption warning is seen, rather than waiting for the pod to actually fail and get rescheduled. Since Karpenter 0.34+, spot-to-spot consolidation is also available (behind a feature gate), letting Karpenter replace one spot instance with a cheaper spot instance of an equivalent or better fit, not just consolidate onto on-demand.
Cluster Autoscaler doesn't have this built in — spot interruption handling on ASGs typically relies on a separate tool (e.g., AWS Node Termination Handler) watching the same interruption notices and draining the node, with Cluster Autoscaler then reacting to the resulting node group capacity change rather than orchestrating the interruption response itself. This works, but it's an additional moving part rather than a single controller's responsibility.
Where Cluster Autoscaler still wins
Karpenter's architecture is AWS-first (with newer GCP and Azure providers still maturing), and calling cloud APIs directly rather than going through an ASG means giving up whatever governance, quota, or compliance controls your organization has built around ASG-managed capacity. Cluster Autoscaler, by contrast, supports more than 30 infrastructure back ends — including on-premises platforms like vSphere and OpenStack — making it the far more portable option for organizations running multi-cloud or hybrid infrastructure, or anywhere Karpenter simply doesn't have a mature provider.
It's also the more conservative, better-understood option operationally: if your organization has existing tooling, alerting, and runbooks built around ASG-based scaling, replacing that with a controller that provisions instances directly is a bigger architectural shift than it might first appear — audit logging, cost allocation tags, and any custom launch-template logic built into your ASGs need to be re-derived as Karpenter NodeClass configuration instead — the same kind of provenance discipline teams apply when signing container images in CI/CD applies here: know exactly what's provisioning your compute and why.
Decision framework
| Situation | Recommendation |
|---|---|
| Single-cloud AWS/EKS, cost and scale-up latency matter | Karpenter (or EKS Auto Mode, which runs it for you) |
| Multi-cloud, hybrid, or on-prem (vSphere, OpenStack) | Cluster Autoscaler |
| Heavy reliance on existing ASG-based governance/tooling | Cluster Autoscaler, or a phased Karpenter migration |
| Spiky/bursty workloads (CI, batch, traffic spikes) | Karpenter — the 45–90s vs. 3–7min scale-up gap compounds |
| Team wants minimal new operational surface area | Cluster Autoscaler (mature, well-documented failure modes) |
| Spot-heavy cost optimization strategy | Karpenter — native interruption handling and spot-to-spot consolidation |
Several teams run both, in a controlled way: Cluster Autoscaler managing a baseline node group for governance-sensitive workloads, with Karpenter added alongside for burstable or cost-sensitive workloads on AWS — though this adds its own coordination overhead and isn't the simplest path for teams starting fresh.
Kubernetes autoscaler architecture is one of the recurring decisions we help engineering teams work through when we're brought in on cloud infrastructure and platform work — the right answer is usually a function of cloud footprint and existing tooling more than raw benchmark numbers.
Sources
- Karpenter vs Cluster Autoscaler: Which to Use in 2026 — CAST AI
- Karpenter vs Cluster Autoscaler — ScaleOps
- Demystifying Karpenter's Advanced Features: Consolidation, Drift, and Spot Handling
- Using Amazon EC2 Spot Instances with Karpenter — AWS
- Karpenter Disruption docs
- Cluster-Autoscaler — AWS EKS Best Practices Guides
- Kubernetes Cluster Autoscaler: Best Practices, Limitations & Alternatives — ScaleOps
- Why Autoscaler Choice Becomes a Crisis at 10,000 Nodes