EKS Auto Mode hands-on: AWS runs the nodes, autoscaling and add-ons

What Auto Mode changes

A hands-on walkthrough published on dev.to examines EKS Auto Mode, the Amazon option in which AWS takes over the compute, storage and networking of a Kubernetes cluster instead of the operator. Under the hood it runs Karpenter and Bottlerocket-based nodes, according to the author, but those details stay behind the curtain: there are no node groups to size and no add-ons to install and version one by one.

The problem it targets is the operational load of running a conventional EKS cluster. The author lists what operators normally own: choosing and sizing node groups, deciding between Spot and On-Demand, installing and tuning an autoscaler such as Cluster Autoscaler or Karpenter along with its IAM permissions, managing add-ons like CoreDNS, kube-proxy, the EBS CSI driver and the VPC CNI, patching node AMIs whenever an operating-system CVE appears, and debugging pods stuck in Pending on insufficient memory. None of that makes the product better, the author argues — it is work that exists only so Kubernetes itself can exist.

One command, two node pools

The lab requires the AWS CLI v2, eksctl v0.195.0 or newer, kubectl, and IAM permissions spanning EC2, EKS, IAM and VPC. A single eksctl create cluster invocation with the auto mode flag brings up the cluster, the VPC, the subnets and AWS-managed essential add-ons in roughly 15 minutes, per the walkthrough.

Auto Mode then creates two node pools on its own. The system pool starts with one node hosting cluster internals such as CoreDNS and the managed add-ons, which is why kubectl get nodes shows a node immediately after creation. The general-purpose pool starts at zero and stays empty until a workload needs compute. The author's takeaway: an empty application pool is not a failure state — it means nothing is scheduled yet and AWS is not billing for idle nodes.

Nodes appear on demand

In the lab, deploying a three-replica nginx deployment with a LoadBalancer service made a node appear in the general-purpose pool in about 30 seconds, with no autoscaler touched and no node group edited. Scaling the deployment to ten replicas prompted further instances once existing capacity ran short. Cleanup is one eksctl delete cluster command, and the author stresses tearing down lab resources to avoid an unpleasant surprise on the bill.

What you trade for it

The walkthrough contrasts classic EKS with Auto Mode across several axes: node management moves from the operator, or a self-run Karpenter, to AWS; add-ons become managed; AMI updates become AWS's job; autoscaling is automatic. In exchange, customization drops from total to limited, though the ramp-up curve goes from steep to gentle.

The author recommends Auto Mode when standing up a new cluster quickly, for small teams that cannot spare someone to tend nodes, and for fairly standard workloads such as APIs, workers and web services. Caution is advised for workloads that depend on very specific node configurations — custom kernels, demanding DaemonSets, GPUs with tailored drivers — for teams already running a finely tuned Karpenter that saves them money, and for compliance regimes that require full control of the AMI lifecycle.

The cost question

Auto Mode adds a small management charge on top of the underlying EC2 costs, according to the article. The author frames the real calculation differently: the fee minus the engineering hours no longer spent on nodes, autoscalers and patching, which changes the picture considerably.

Why it matters

Node sizing, autoscaler upkeep and AMI patching have been among the most persistent time sinks in operating production Kubernetes on AWS, and none of it differentiates the software running on top. Auto Mode shifts that entire layer across the shared-responsibility line to AWS, continuing the broader move toward fully managed Kubernetes surfaces. The trade is explicit: operators give up degrees of node-level control and gain operational hours back. For standard workloads that deal looks strong; for specialised or compliance-bound clusters, the author's account suggests the manual path still holds. Teams running EKS in production can trial it on a non-critical workload and measure the time saved before committing.