Karpenter vs. Cluster Autoscaler vs. EKS Auto Mode: 2026 Costs and Latency Trade-offs

Node autoscaling is often described as a choice between lower cost and less operations work. On Amazon EKS, that decision also affects how quickly unschedulable pods get capacity, how much instance flexibility you have, and how safely nodes can be drained.

This guide compares Cluster Autoscaler, self-managed Karpenter, and EKS Auto Mode. It focuses on behavior and a reusable cost model rather than presenting a universal benchmark: provisioning time and savings depend on image pulls, startup taints, subnet IP capacity, EC2 capacity, pod constraints, and workload startup time.

First, separate pod scaling from node scaling

The Horizontal Pod Autoscaler (HPA) changes a workload’s replica count. A node autoscaler provides nodes when those replicas cannot be scheduled. HPA does not create compute capacity by itself, and a node autoscaler does not know whether adding replicas will meet an application latency objective.

A typical scale-out chain is:

1. Metrics cause HPA to increase the desired replica count.
2. The scheduler tries to place the new pods. Pods that do not fit become unschedulable.
3. Karpenter or Cluster Autoscaler observes unschedulable pods and requests nodes that satisfy their scheduling constraints.
4. EC2 capacity launches, the node joins and initializes, required DaemonSets and networking become ready, images are pulled, and the application passes readiness checks.

The time users feel includes every step. An autoscaler benchmark that measures only the controller’s decision or EC2 launch is not an end-to-end application latency benchmark.

How the three options differ

Option	How it chooses capacity	Who operates the autoscaler and nodes	Typical fit
Cluster Autoscaler	Adjusts the size of configured node groups when pods cannot schedule; node-group shapes constrain its choices	You operate the autoscaler, node groups, AMIs, and upgrades	Existing ASG-based platforms, predictable instance groups, or teams with established node-group automation
Self-managed Karpenter	Selects instance types and capacity to satisfy pending pods from NodePool constraints; can consolidate underused nodes	You operate the controller, IAM, NodePools, EC2NodeClasses, and node lifecycle policies	Workloads that benefit from instance flexibility and teams able to own the controller and disruption policy
EKS Auto Mode	AWS manages compute provisioning and node lifecycle through EKS Auto Mode	AWS operates the managed capabilities; you still set workload constraints and capacity policy	Teams prioritizing less infrastructure maintenance and accepting an additional per-node management charge

Auto Mode is a managed EKS operating mode, not a free performance tier. AWS says its management fee is added to EC2 cost for Auto Mode-managed nodes; standard EC2 purchase options remain available, and the Auto Mode charge is independent of those purchase options. Self-managed nodes can coexist with Auto Mode-managed nodes in a cluster. See AWS’s Auto Mode best practices and pricing page.

Model the actual cost, not just the instance rate

For each candidate design, estimate the same workload over the same time period and include:

• EC2 instance hours, including any capacity held as warm headroom.
• EKS Auto Mode management charges for Auto Mode-managed nodes, where applicable.
• EKS cluster version support fees: currently $0.10 per cluster-hour for standard support and $0.60 per cluster-hour for extended support.
• EBS, public IPv4, load balancers, data transfer, and other resources used by the worker nodes.
• Engineering and on-call time to operate node groups or Karpenter, plus the cost of incidents and upgrade work.

A useful monthly estimate is:

monthly infrastructure cost =
  sum(instance-hours × regional EC2 rate)
  + Auto Mode managed-node charges
  + EKS cluster support charge
  + storage, networking, and other AWS charges

Use the current regional rate table and your own purchase discounts. AWS notes Auto Mode charges are billed per second with a one-minute minimum, and are not reduced by EC2 Reserved Instance or Savings Plan purchase options. The exact management price depends on instance type; avoid applying one flat percentage across all fleets without checking the pricing table.

For a break-even test, compare the modeled monthly totals. If Auto Mode adds fee F and saves compute S, it is cheaper on infrastructure only when S > F. Add the value of your team’s saved operating time separately; the best choice may still be Auto Mode even when its raw AWS bill is higher.

AWS announced that, effective July 1, 2026, Auto Mode management fees for G-series instances fell 35%, while P-series and Trainium fees fell 60%. The change applies automatically in regions where Auto Mode is available. Those are reductions to the applicable management fee, not discounts to the EC2 instance price. See the AWS announcement.

Remember EKS extended support

EKS standard support lasts 14 months from an EKS Kubernetes version’s release; extended support lasts a further 12 months. The current listed charge is $0.10 per cluster-hour in standard support and $0.60 per cluster-hour in extended support. That is about $73 and $438 for a 730-hour month, respectively, before tax or other charges. Kubernetes 1.34 is scheduled to leave standard support on December 2, 2026; verify the EKS release calendar as dates can change.

The upgrade policy needs careful wording: EKS clusters created through the API have historically defaulted to EXTENDED, while clusters created in the console can default to STANDARD; check the actual cluster and IaC defaults rather than assuming one universal default. STANDARD makes the cluster eligible for automatic upgrade when standard support ends, while EXTENDED allows the cluster to remain on that version at the higher fee. See AWS’s upgrade policy documentation.

aws eks describe-cluster \
  --name prod-checkout-cluster \
  --query 'cluster.upgradePolicy.supportType'

Choose the policy as an explicit upgrade decision. Setting STANDARD avoids extended-support fees by allowing an automatic control-plane upgrade; it does not mean the cluster will stay on the current version indefinitely.

Scale-up speed and p99: where the real risk lives

There is no universal result such as “Karpenter provisions in 74 seconds” or “Cluster Autoscaler takes 132 seconds.” Such figures require a reproducible workload, region, instance types, image sizes, cache state, pod constraints, and a clear start and finish timestamp. The article draft that prompted this guide included a specific 2026 benchmark and a four-second p99 incident, but no independently verifiable benchmark or methodology could be found. Those numbers are omitted here rather than presented as general facts.

Karpenter can consider a broader set of instance types than a setup with a few fixed-size node groups, which can help it find compatible capacity. It cannot guarantee EC2 capacity in a particular Availability Zone, allocate missing subnet IPs, shorten container image downloads, or make an application ready. Cluster Autoscaler can also scale quickly when node groups, min/max bounds, and images are configured well. Benchmark your own critical path with timestamps for pod creation, FailedScheduling, NodeClaim or ASG activity, node Ready, image pull completion, and application readiness.

Consolidation is a separate, voluntary scale-down process. It may evict pods to reduce the number or cost of nodes. It does not trigger merely because the default timer reaches one minute: current Karpenter documentation lists consolidateAfter: 0s as the default, and the timer resets whenever pods are added to or removed from a node. A longer delay can reduce churn, but it does not create surge capacity or protect an application from all causes of latency.

During a traffic increase, p99 can rise if HPA adds replicas faster than new nodes become usable and the existing pods are near saturation. Drains can add pressure when replicas are evicted and rescheduled. PodDisruptionBudgets (PDBs) may block voluntary eviction; topology spread and affinity can restrict where replacements fit; and unavailable zonal capacity can leave pods pending. These are interacting failure modes to measure, not proof that a particular autoscaler caused a particular p99 spike.

A conservative Karpenter NodePool example

This example allows several instance categories, sets a consolidation quiet period, and pauses voluntary disruptions during a weekday UTC peak window. Replace the schedule and constraints with measured service needs. Karpenter requirement entries use key (not labelSelector); the valid numeric operator here is Gt.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: checkout-latency-sensitive
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["5"]
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["us-east-1a", "us-east-1b", "us-east-1c"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 10m
    budgets:
      # UTC; blocks voluntary disruption during weekday peak hours.
      - nodes: "0"
        schedule: "0 13 * * mon-fri"
        duration: 8h
      # Limits voluntary disruption outside the scheduled window.
      - nodes: "10%"

The zone list must match the cluster’s actual subnets and workload topology. A nodes: "0" disruption budget blocks voluntary disruptions within that budget’s schedule; it does not prevent scale-up, EC2 interruptions, or every forceful repair action. Keep in mind that a drain can still be blocked by a PDB, and a node’s termination grace period can ultimately cause pods to be deleted if eviction never completes. Read the Karpenter disruption guide before setting termination behavior.

A PDB describes how many matching pods may be voluntarily disrupted; it does not guarantee sufficient capacity or protect pods from every failure. For example, maxUnavailable: 10% is only meaningful if the deployment has enough healthy replicas and replacement capacity. Ensure readiness probes reflect the ability to serve traffic, keep replica counts appropriate for peak demand, and test node drains under load.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-pdb
  namespace: production
spec:
  maxUnavailable: 10%
  selector:
    matchLabels:
      app: checkout-api

Set the pod’s terminationGracePeriodSeconds and preStop behavior to match the application’s actual shutdown and load-balancer deregistration sequence. A preStop hook consumes the pod’s termination grace period; it does not delay SIGTERM until after the hook finishes. Verify the interaction with your ingress or load balancer controller and application server.

Operational guardrails that matter more than a magic timer

1. Measure the whole scale-up path. Alert on pending pods, node launch/registration time, image pull duration, readiness, and service latency. Keep a small warm capacity floor if cold-start time exceeds the service’s latency budget.
2. Keep scheduling flexible. Allow multiple compatible families, sizes, and zones where application architecture permits. Check subnet IP headroom, quotas, architecture compatibility, local storage needs, and topology constraints.
3. Set disruption policy by workload. Start with a longer consolidateAfter for services sensitive to rescheduling, then validate savings and latency from events and metrics. Use disruption budgets to shape voluntary drain timing and blast radius.
4. Design graceful shutdown deliberately. Use adequate replicas, realistic readiness and termination handling, and PDBs aligned with the service’s actual availability requirement. A PDB that is too strict can prevent maintenance from completing.
5. Separate workloads with conflicting needs. Isolate interruptible batch or Spot workloads from latency-critical services with taints, tolerations, and distinct NodePools where appropriate.
6. Review version and fee exposure. Track EKS support dates and the actual supportType alongside worker-node costs.

Which option should you choose?

• Choose Cluster Autoscaler when your node groups already work well, capacity shapes are predictable, and the team has mature ASG and AMI automation.
• Choose self-managed Karpenter when flexible instance selection and consolidation are valuable, and your platform team can own controller upgrades, IAM, NodePools, and disruption behavior.
• Choose EKS Auto Mode when reducing node infrastructure operations is worth its additional per-managed-node fee, especially after modeling current instance-specific pricing and support requirements.

No autoscaler can promise an application p99 target by itself. Pair node scaling with workload-level capacity planning, warm headroom where needed, and a measured load test that includes node initialization and traffic serving.

Before changing a production NodePool, inspect pending pods, PDB status, topology constraints, subnet capacity, and recent disruption events. You can review cluster state with kubectl get events and kubectl describe pdb, or inspect it with Berth’s read-only Kubernetes dashboard.

Want to review your cluster’s node utilization and disruption policy without granting an agent write access? Book a free Architecture Review or try Berth for free on clusters up to 10 nodes.

Related: Managed DevOps vs. Hiring In-House: The Real 2026 Cost Comparison

Sources

• Amazon EKS pricing and EKS Auto Mode best practices
• AWS announcement: Auto Mode GPU fee reductions
• EKS Kubernetes version lifecycle and cluster upgrade policy
• Karpenter NodePools and disruption
• Cast AI 2026 State of Kubernetes Optimization report announcement