How is EKS deployed in your environment, and what are the differences between AWS Managed Node Groups, self-managed nodes, and EKS Auto Mode?

Think of renting a car for a road trip. Self-managed nodes are like buying a car — you choose the model, handle maintenance, insurance, and repairs. Managed Node Groups are like a long-term lease — the dealer handles servicing, but you choose the model and drive it yourself. EKS Auto Mode is like a ride-sharing service — you just say where you want to go, and someone else handles the car, driving, and routing.

EKS deployment typically starts with creating the control plane (API server, etcd, scheduler) which is fully managed by AWS. Then you choose how to run worker nodes. Managed Node Groups are the most common choice: you specify instance types, desired capacity, and AMI family, and AWS creates an Auto Scaling Group, handles AMI updates, and manages node lifecycle. Self-managed nodes give you full control — you create your own ASG with custom AMIs, custom bootstrap scripts, and custom instance configurations, but you manage patching and upgrades yourself.

EKS Auto Mode, introduced in late 2024, takes automation further. Instead of specifying instance types and node groups, you let AWS choose the optimal compute for your workloads. Auto Mode manages the Kubernetes components typically installed as add-ons: kube-proxy, CoreDNS, VPC CNI, EBS CSI driver, and pod identity agent. It also handles GPU scheduling and Karpenter-style intelligent node provisioning. The tradeoff is less control over specific instance types and node configurations in exchange for significantly reduced operational burden.

At production scale, most enterprise teams use Managed Node Groups with specific instance families defined per workload type: compute-optimized (c6i) for API services, memory-optimized (r6i) for caching layers, and GPU instances (p4d, g5) for ML workloads. Teams deploy EKS using Terraform with the terraform-aws-modules/eks module, which handles the VPC, security groups, IAM roles, OIDC provider, and node group configurations. Add-ons like VPC CNI, CoreDNS, and EBS CSI driver are managed as EKS add-ons with version pinning.

The non-obvious gotcha is that Managed Node Groups handle rolling updates differently than you might expect. When you update the AMI or instance type, MNG creates new nodes and drains old ones, but it respects PodDisruptionBudgets. If a PDB blocks draining, the update stalls silently. Teams should monitor node group update status and set appropriate PDBs. With Auto Mode, you lose the ability to SSH into nodes or run DaemonSets for custom monitoring agents, which can be a blocker for teams with specific compliance or debugging requirements.