Updated February 5, 2025
· ~4 min read
Node autoscaling on Kubernetes has two primary options: Cluster Autoscaler (CA), the long-standing standard, and Karpenter, the newer, AWS-native autoscaler launched in 2021 that has become AWS's default recommendation for EKS clusters.
Cluster Autoscaler works by scaling existing node groups (Auto Scaling Groups). When the scheduler cannot place pods, CA checks each node group to determine if adding nodes to that group would unblock the pending pods, then triggers a scale-out event. This approach works but has two fundamental limitations: CA is constrained by the instance types configured in each node group, and it works through the ASG API which adds 3–5 minutes of provisioning latency.
Karpenter takes a different approach. It watches the Kubernetes scheduler's pending pod queue directly and calls the EC2 CreateFleet API to provision exactly the right instance type — without predefined node groups. This allows Karpenter to select from dozens of instance families and sizes, resulting in better bin-packing, faster provisioning (30–60 seconds), and intelligent spot diversification. The consolidation feature continuously evaluates whether the cluster can be run on fewer, better-utilized nodes.
AWS launched Karpenter as open-source in 2021, graduated it to v1.0 in 2024, and now recommends it for all new EKS clusters. For existing clusters running Cluster Autoscaler, migration to Karpenter is straightforward and almost always worth the one-time effort.
Karpenter changes node autoscaling from reactive to intelligent. Cluster Autoscaler reacts to pending pods by scaling what you pre-configured; Karpenter observes what pods need and provisions the optimal instance. This difference compounds: better bin-packing reduces the number of nodes needed for the same workload, spot diversification reduces interruption probability and cost, and active consolidation continuously right-sizes the cluster during low-traffic periods. In practice, production clusters migrating from CA to Karpenter see 20–40% EC2 cost reductions from consolidation and spot alone. The 30–60 second scale-out latency (vs 3–5 minutes for CA) is also meaningful for workloads with spiky traffic patterns — pods get scheduled faster, and users see less degradation during traffic spikes.
Cluster Autoscaler remains relevant in a narrow set of situations. On non-AWS Kubernetes clusters (GKE, AKS, on-premises), Karpenter does not apply — Cluster Autoscaler is the standard for multi-cloud and hybrid clusters. On AWS EKS, the only scenario where we have not migrated a client is when an existing cluster has very extensive custom ASG configuration (custom lifecycle hooks, complex ASG warm pool configurations) that would require significant rework to migrate, and the cluster is scheduled for decommissioning within 6 months. In all other cases, the one-time migration effort pays for itself quickly in EC2 cost savings.
Karpenter consolidation is the feature that most surprised teams migrating from Cluster Autoscaler. While CA only removes completely empty nodes, Karpenter's consolidation loop continuously evaluates whether all running pods could be rescheduled onto a smaller number of nodes — then makes it happen. During overnight hours when traffic drops, a cluster that peaked at 20 nodes during business hours might consolidate to 4 nodes by 3 AM. This is not manual scheduling or cron jobs — it is Karpenter continuously optimizing the node fleet based on actual pod scheduling constraints. The economics: a team running 50 microservices on EKS might have 6 nodes minimum with CA (to avoid scale-down delays); with Karpenter WhenUnderutilized consolidation, overnight traffic may consolidate to 3–4 nodes. At $0.10/node-hour on t3.xlarge, the overnight savings alone pay for the migration effort within weeks.
Question 1 of 4
Are you starting a new EKS cluster?
For new EKS clusters: always use Karpenter. There is no meaningful scenario where Cluster Autoscaler is the better choice for a new deployment. For existing clusters: migrate to Karpenter. The migration is well-documented, can be done incrementally (running both simultaneously during migration), and the cost and performance benefits are consistently significant. The only scenario where Cluster Autoscaler might be retained is an existing cluster with extensive custom CA configuration or webhook integrations where the migration cost is high and the cluster will be decommissioned soon.
Production EKS Platform
A production-ready Kubernetes platform on EKS with Karpenter, GitOps, service mesh, full observability stack, and security hardening: built to run real workloads.
We work with startups and growing companies on AWS architecture decisions. Tell us about your situation and we will recommend the right approach.
As of February 5, 2025. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.