What Is EKS Auto Mode? Managed Karpenter Node Autoscaling

AWS launched EKS Auto Mode at re:Invent 2024 (GA: December 1, 2024), a cluster configuration mode that runs Karpenter as a fully managed, off-cluster service, automating node provisioning, AMI patching, node replacement, load balancing, networking, and storage with a single enable call. The trade-off is approximately a 12% surcharge on EC2 On-Demand price per managed node, plus restrictions on AMI choice (Bottlerocket only) and host access. Node provisioning takes 45 to 90 seconds under typical conditions with Karpenter, compared to 3 to 4 minutes with Cluster Autoscaler.

Key takeaways - EKS Auto Mode runs Karpenter https://cast.ai/blog/karpenter-vs-cluster-autoscaler/ as a fully managed, off-cluster service. You never deploy, upgrade, or restart the Karpenter controller. - Auto Mode automates node provisioning, AMI patching, node replacement, load balancing, networking, and storage with a single enable call. - The trade-off is approximately a 12% surcharge on EC2 On-Demand price per managed node, plus restrictions on AMI choice and host access. - Self-managed Karpenter gives full control over AMIs, Karpenter versions, and node access. It requires significantly more engineering overhead. - Both options leave workload-level overprovisioning unsolved. Cast AI’s rightsizing layer closes that gap on top of either compute model. - Node provisioning takes 45 to 90 seconds under typical conditions with Karpenter, compared to 3 to 4 minutes with Cluster Autoscaler. What EKS Auto Mode is EKS Auto Mode is a cluster configuration mode that AWS launched at re:Invent 2024 GA: December 1, 2024 . It extends AWS’s management of Kubernetes infrastructure to include compute autoscaling, pod networking, load balancing, block storage, cluster DNS, and GPU support. Previously, teams wired these components together manually through separate installs and configurations. Auto Mode replaces that entire assembly with a single API call or CLI flag. The autoscaling engine inside Auto Mode is Karpenter https://cast.ai/blog/karpenter-vs-cluster-autoscaler/ . Karpenter monitors unschedulable pods and provisions the best-fitting EC2 instance from the full AWS catalog in 45 to 90 seconds under typical conditions actual time varies by instance type, region, and capacity pool availability . In Auto Mode, Karpenter runs entirely off-cluster, managed by AWS. It does not appear as pods in your account, and you never interact with a Helm chart for it. NodePools and NodeClasses in Auto Mode Auto Mode ships with two built-in NodePools. The general-purpose NodePool selects from a broad set of On-Demand instance families, including C, M, R, T, and I families, across both x86 AMD and arm64 Graviton architectures on Linux, based on the best vCPU/memory fit for pending pods. The system NodePool carries a NoSchedule taint reserved for EKS-managed internal add-ons; its ARM support covers those add-ons only. User workloads should not be scheduled on system NodePool nodes. Both built-in NodePools use Bottlerocket AMIs, which is the only AMI option available in Auto Mode. For ARM user workloads, add a custom NodePool targeting arm64 rather than relying on the system NodePool. Custom NodePools use the same karpenter.sh/v1 API as open-source Karpenter, so standard Karpenter documentation applies. However, NodeClasses differ between the two approaches: Auto Mode uses eks.amazonaws.com/v1 NodeClass rather than the self-managed karpenter.k8s.aws/v1 EC2NodeClass . Existing EC2NodeClass configs do not migrate directly and need rewriting. What it automates Compute and node lifecycle Node provisioning: Selects the optimal instance type, size, architecture, capacity type, and AZ dynamically from pending pod requirements. AMI lifecycle: Manages Bottlerocket AMI selection and applies weekly CVE and security updates. Node replacement: Automatically rotates nodes after a maximum of 21 days, respecting Pod Disruption Budgets PDBs and NodePool disruption budgets. Scale-out and scale-in: Provisions nodes when pods are unschedulable. Consolidates or removes nodes when underutilized. Spot interruption handling: Responds to EC2 Spot interruption notices automatically, without manual intervention. EC2 health events: Handles scheduled maintenance and instance health events on your behalf. Networking, storage, and load balancing Networking: AWS VPC CNI for pod networking, eBPF-based kube-proxy replacement for service routing, and pod network policies, all managed off-cluster. Storage: EBS CSI Driver for block storage provisioning from PersistentVolumeClaims. Load balancing: AWS Load Balancer Controller provisions ALBs from Ingress resources and NLBs from Service resources. DNS: A CoreDNS equivalent runs off-cluster and is fully managed by AWS. GPU and accelerators: NVIDIA, Trainium, and Inferentia device plugins are managed automatically. ARC Zonal Shift: Stops provisioning nodes in impaired Availability Zones automatically. All of these components run off-cluster and are invisible as pods in your account. Therefore, Auto Mode is the first approach where a full production baseline autoscaler, load balancer, storage driver, DNS, and networking arrives pre-assembled. You bring the workloads. Auto Mode vs self-managed Karpenter The fundamental difference is operational ownership. Both options use Karpenter’s scheduling logic and the same karpenter.sh/v1 NodePool API. In Auto Mode, AWS owns the controller. In self-managed Karpenter, your team owns it. | Dimension | EKS Auto Mode | Self-managed Karpenter | |---|---|---| Control | AWS manages the Karpenter controller, node lifecycle, AMIs, and patching | You own controller deployment, upgrades, IAM config, and failure response | Additional fee | ~12% surcharge on EC2 On-Demand price per node, billed per second | None beyond EC2 costs plus small Karpenter controller compute overhead | Flexibility | Bottlerocket AMIs only; no SSH/SSM; AWS controls the Karpenter version | Custom AMIs, SSH/SSM access, Windows, full EC2NodeClass configuration, version control | Cost tuning | Savings Plans cover EC2 portion only; Auto Mode management fee is not discounted | Savings Plans cover all EC2 nodes; no per-node surcharge to work around | Key limitations before you choose Auto Mode No custom AMIs: Only Amazon-provided Bottlerocket images are supported. Amazon Linux 2, custom OS hardening, and Windows are not available. No host access: SSH and SSM are disabled by design. Host-level agents run as DaemonSets instead. Different NodeClass API: The eks.amazonaws.com/v1 NodeClass replaces karpenter.k8s.aws/v1 EC2NodeClass . Existing configurations need rewriting, not porting. AWS controls the Karpenter version: You cannot pin a version or enable experimental feature flags. Load balancer migration requires blue-green: Existing load balancers managed by a self-managed AWS LBC cannot move directly to Auto Mode. For a broader look at how Karpenter compares to the older Cluster Autoscaler approach, see Karpenter vs Cluster Autoscaler: Which to Use in 2026 https://cast.ai/blog/karpenter-vs-cluster-autoscaler/ . Cost trade-offs Auto Mode adds a management fee on top of standard EC2 costs. The fee runs approximately 12% of the EC2 On-Demand price per managed instance, billed per second with a one-minute minimum. Two concrete examples: m5.large: EC2 $0.096/hr + Auto Mode fee $0.0115/hr = $0.1075/hr per node m5a.xlarge: EC2 $0.172/hr + Auto Mode fee $0.02064/hr = $0.19264/hr per node Compute Savings Plans and Reserved Instances discount only the EC2 portion. The Auto Mode surcharge is not discounted. At scale, this adds up fast: a fleet of 100 m5.large On-Demand nodes accumulates roughly $830 per month in Auto Mode fees alone, before any instance-level discounts. For large deployments, AWS notes that pricing may differ for clusters with more than 150 Auto Mode managed nodes. Contact your AWS account team if you approach that threshold. Also note that AWS reduced Auto Mode management fees for GPU instances by up to 60% effective July 2026. If you run GPU workloads, check the current AWS EKS pricing page for the latest accelerated instance fees before budgeting. When the fee is worth it The 12% surcharge buys eliminated Karpenter ops: no Helm install, no high-availability configuration, no upgrade planning, and no controller failure response. For small platform teams, a mid-level engineer’s time spent on Karpenter maintenance typically costs far more than the per-node surcharge. Additionally, automated AMI rotation and immutable node design reduce security incident risk, which carries its own cost and effort. When the fee is not worth it Large fleets are one case where the surcharge compounds significantly at scale. Spot-heavy workloads are another: the management fee applies to Spot instances too, which erodes part of the Spot discount advantage. Teams already proficient at Karpenter operations may find the engineering cost of self-managed Karpenter well below the perpetual 12% fee. For broader strategies on reducing EKS costs https://cast.ai/blog/eks-cost-optimization/ beyond autoscaler choice, the Cast AI EKS cost optimization guide covers utilization monitoring, Spot adoption, and rightsizing in detail. When to choose which Choose EKS Auto Mode when: - You run a small to medium platform team and want Karpenter’s scheduling efficiency without owning the controller lifecycle. - You are starting a new EKS cluster and need the fastest path to a production-ready baseline. - Automatic AMI rotation and immutable nodes match your security posture without requiring extra tooling. - Your workloads do not require custom AMIs, Windows nodes, or SSH/SSM debugging access. - You currently run Cluster Autoscaler with fixed node groups and want to modernize without taking on full Karpenter operations. Choose self-managed Karpenter when: - Compliance or operational requirements demand custom AMIs, Windows support, or SSH/SSM node access. - You run large fleets where the 12% per-node surcharge is significant relative to your engineering capacity to self-manage. - Your platform team already operates Karpenter effectively and values control over versions and feature flags. - You are migrating from an existing self-managed Karpenter setup. There is no technical need to change a working configuration. - Spot workloads dominate your fleet and the Auto Mode surcharge would materially erode savings. Getting started with Auto Mode Before enabling Auto Mode, confirm one prerequisite: your cluster must run EKS version 1.29 or later. Next, create a Cluster IAM Role and a Node IAM Role with the required AWS managed policies attached. AWS recommends naming these AmazonEKSAutoClusterRole and AmazonEKSAutoNodeRole for consistency, though the names are not enforced. When you use eksctl, it creates these roles automatically with the correct policies. For manual setup via the AWS console or API, attach the following managed policies to the cluster role: AmazonEKSComputePolicy, AmazonEKSBlockStoragePolicyV2, AmazonEKSLoadBalancingPolicy, AmazonEKSNetworkingPolicy, and AmazonEKSClusterPolicy. Then follow the AWS Auto Mode IAM documentation https://docs.aws.amazon.com/eks/latest/userguide/auto-mode-iam.html for the node role. Enabling Auto Mode on a new cluster takes a single eksctl command or a minimal ClusterConfig YAML. Here is the YAML approach requires a recent eksctl version; check the eksctl releases page for the minimum version that supports autoModeConfig : eksctl create cluster apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: us-east-1 autoModeConfig: enabled: true nodePools: "general-purpose", "system" After the cluster is up, verify that Auto Mode is active: Verify Auto Mode is active kubectl get nodepool kubectl get nodeclaim -A kubectl describe nodepool general-purpose If kubectl get nodeclaim -A returns a permission error, check your RBAC configuration. NodeClaim is a Karpenter CRD. You need cluster-admin or an equivalent role with get and list permissions on nodeclaims.karpenter.sh to view it. What to monitor after enabling Auto Mode After enabling Auto Mode, use these approaches to monitor node activity: kubectl get events -A --field-selector reportingComponent=karpenter --sort-by=.lastTimestamp shows node provisioning, consolidation, and disruption events. kubectl get nodeclaim -A shows active Auto Mode node claims and their current status.- AWS CloudWatch Container Insights integrates natively with Auto Mode. Enable it to get node-level CPU, memory, and network metrics. - Cost and Usage Reports: use the aws:ec2:eks-auto-mode cost tag to isolate Auto Mode management fees from regular EC2 costs. One meaningful gap to know about: the off-cluster Karpenter controller in Auto Mode does not expose Prometheus metrics directly. If your team relies on Karpenter Prometheus metrics for alerting, this requires a different observability approach compared to self-managed Karpenter. Migrating from self-managed Karpenter to Auto Mode Auto Mode supports running alongside existing managed node groups, so a phased migration is possible. Follow this sequence to reduce risk: Step 1: Disable the self-managed Karpenter controller. Scale its Deployment to 0 replicas so it stops making scheduling decisions before Auto Mode takes over. Step 1.5: Handle existing Karpenter-provisioned nodes. After scaling the controller to 0, existing nodes it provisioned continue running normally. Auto Mode will not adopt them automatically. As workloads rotate or pods reschedule, Auto Mode provisions replacement nodes. To force faster adoption, taint old Karpenter-provisioned nodes with kubectl taint node <name karpenter.sh/disruption:NoSchedule= and drain them. Auto Mode then provisions replacements as pods become unschedulable. Step 2: Rewrite NodePool specs to use the Auto Mode NodeClass API. Migrate from karpenter.k8s.aws/v1 EC2NodeClass to eks.amazonaws.com/v1 NodeClass . Direct porting does not work; specs need rewriting from scratch. Step 3: Migrate load balancers using a blue-green approach. ALBs and NLBs managed by a self-managed AWS Load Balancer Controller cannot transfer directly. Provision new load balancers under Auto Mode, shift traffic, then decommission the old ones. Step 4: Run both in parallel during validation. Keep the self-managed controller scaled to 0 but do not remove it yet. Validate Auto Mode behavior across your workload types, then remove the self-managed controller once confidence is high. More detail on Kubernetes autoscaling strategies is available in the Cast AI autoscaling guide https://cast.ai/blog/guide-to-kubernetes-autoscaling-for-cloud-cost-optimization/ , which covers horizontal and vertical scaling mechanics in detail. The layer Auto Mode and Karpenter do not cover Both EKS Auto Mode and self-managed Karpenter solve node-level autoscaling. Neither solves the problem one layer below: inaccurate workload resource requests. Karpenter provisions nodes based on what workloads request, not what they consume. Consider a deployment that requests 2 CPU but typically uses 0.3 CPU. Karpenter packs nodes around 2 CPU per pod, because that is what the spec says. Cast AI’s rightsizing observes that 0.3 CPU is the real baseline and adjusts requests accordingly. On a cluster where 69% of nodes are CPU-overprovisioned, correcting requests can reduce node count by 30 to 50 percent without changing the autoscaler at all. According to the Cast AI 2026 State of Kubernetes Optimization Report based on 23,000+ clusters , average CPU utilization sits at just 8%. Teams consistently request far more than workloads consume. Karpenter optimizes around those inflated numbers rather than actual usage, so the bins never pack as tightly as they could. Cast AI works on top of EKS Auto Mode and self-managed Karpenter https://cast.ai/karpenter-optimization/ to close this gap through continuous rightsizing: observing actual CPU and memory consumption, then automatically tuning workload resource requests and limits to match real consumption. Accurate requests give Karpenter better data to pack nodes more densely, which means fewer nodes and lower bills without changing your autoscaler choice. Cast AI does not replace Auto Mode or Karpenter. Instead, it makes whichever autoscaler you choose more effective. Frequently Asked Questions What is EKS Auto Mode? EKS Auto Mode is an AWS cluster configuration mode, launched in December 2024, that manages compute autoscaling, pod networking, load balancing, block storage, and DNS for EKS clusters. It uses Karpenter as its autoscaling engine, running it as a fully managed off-cluster service so teams never deploy or upgrade the controller. Teams enable Auto Mode with a single API call or eksctl command and receive a production-ready cluster baseline without manually assembling Kubernetes infrastructure components. Requires EKS version 1.29 or later. Does EKS Auto Mode use Karpenter? Yes. EKS Auto Mode uses Karpenter as its node autoscaling engine. Karpenter runs off-cluster, fully managed by AWS, so you do not deploy, upgrade, or restart it. The NodePool API karpenter.sh/v1 is identical to open-source Karpenter, meaning standard Karpenter documentation applies. The NodeClass API differs: Auto Mode uses eks.amazonaws.com/v1 NodeClass instead of karpenter.k8s.aws/v1 EC2NodeClass. What is the difference between EKS Auto Mode and self-managed Karpenter? The primary difference is operational ownership. Auto Mode lets AWS run and maintain the Karpenter controller, AMIs, and node lifecycle. Self-managed Karpenter requires your team to deploy, configure, upgrade, and operate the controller. Auto Mode adds approximately a 12% per-node management fee on top of EC2 costs; self-managed Karpenter carries no such surcharge. Auto Mode also restricts AMI choice to Bottlerocket, disables SSH/SSM, and pins the Karpenter version to whatever AWS releases. Self-managed Karpenter supports custom AMIs, Windows, SSH/SSM, and full version control. For more context, see Karpenter vs Cluster Autoscaler https://cast.ai/blog/karpenter-vs-cluster-autoscaler/ . How much does EKS Auto Mode cost? EKS Auto Mode pricing has three components: the standard EKS cluster fee $0.10/hr for standard support, $0.60/hr for extended support , standard EC2 instance costs for your node types, and an Auto Mode management fee of approximately 12% of the EC2 On-Demand price per managed instance. For example, an m5.large node adds roughly $0.0115/hr on top of its $0.096/hr EC2 cost. Compute Savings Plans discount only the EC2 portion; the Auto Mode fee is not discounted by any reservation or savings plan. For clusters exceeding 150 managed nodes, pricing may differ; contact your AWS account team. When should I use EKS Auto Mode? EKS Auto Mode fits teams that want Karpenter’s node scheduling efficiency without managing the Karpenter controller themselves. It works well for small to medium platform teams, greenfield EKS clusters, and teams currently running Cluster Autoscaler with fixed node groups who want to modernize quickly. Avoid Auto Mode if you need custom AMIs, Windows nodes, SSH/SSM access, control over Karpenter versions, or if your fleet size makes the 12% per-node surcharge outweigh the operational savings. Your cluster must run EKS version 1.29 or later to be eligible.