EKS Auto Mode is an AWS cluster configuration mode (GA December 2024) that runs Karpenter as a fully managed off-cluster service, automating node provisioning, AMI patching, load balancing, networking, and storage with a single API call. It requires EKS 1.29+. The key trade-off is a ~12% surcharge on EC2 On-Demand price per managed node — a fleet of 100 m5.large nodes accumulates ~$830/month in fees alone. Auto Mode restricts AMIs to Bottlerocket only, disables SSH/SSM, and pins the Karpenter version. Self-managed Karpenter offers full control over AMIs, versions, and node access but requires significant engineering overhead. The post covers cost comparisons, migration steps from self-managed Karpenter, monitoring approaches, and notes that neither option solves workload-level overprovisioning (average CPU utilization sits at just 8% across 23,000+ clusters).
Table of contents
Key takeawaysWhat EKS Auto Mode isWhat it automatesAuto Mode vs self-managed KarpenterCost trade-offsWhen to choose whichThe layer Auto Mode and Karpenter do not coverFrequently Asked QuestionsQuestions this post answers
How much does EKS Auto Mode cost per node compared to self-managed Karpenter?
EKS Auto Mode adds approximately 12% of the EC2 On-Demand price per managed node on top of standard EC2 costs, billed per second with a one-minute minimum. An m5.large node costs $0.096/hr for EC2 plus $0.0115/hr in Auto Mode fees. A fleet of 100 m5.large On-Demand nodes accumulates roughly $830/month in Auto Mode fees alone. Compute Savings Plans discount only the EC2 portion; the surcharge is not discounted. Teams sizing up EKS Auto Mode for larger fleets track these cost comparisons on daily.dev before committing.
What are the limitations of EKS Auto Mode compared to self-managed Karpenter?
EKS Auto Mode supports only Bottlerocket AMIs — Amazon Linux 2, custom OS hardening, and Windows are unavailable. SSH and SSM access are disabled by design. The NodeClass API differs from self-managed Karpenter: Auto Mode uses eks.amazonaws.com/v1 NodeClass instead of karpenter.k8s.aws/v1 EC2NodeClass, requiring full rewrites of existing configs. AWS controls the Karpenter version, so you cannot pin versions or enable experimental feature flags. Platform engineers choosing between EKS Auto Mode and self-managed Karpenter follow the trade-offs on daily.dev.
How do I migrate from self-managed Karpenter to EKS Auto Mode?
Scale the self-managed Karpenter controller Deployment to 0 replicas first. Existing nodes it provisioned keep running but Auto Mode will not adopt them automatically — taint and drain them to force replacement. Rewrite NodePool specs from karpenter.k8s.aws/v1 EC2NodeClass to eks.amazonaws.com/v1 NodeClass from scratch; direct porting does not work. Migrate load balancers using a blue-green approach, then run both in parallel during validation before removing the old controller. Engineers mid-migration from self-managed Karpenter to Auto Mode find the latest EKS ecosystem updates on daily.dev.