AWS runs the Auto Scaling group and the node lifecycle; you pick instance types and when to upgrade.

A managed node group is the traditional, most predictable EKS compute option, well suited to steady fleets.

create and update

$ eksctl create nodegroup --cluster shop-eu --name gpu \
    --node-type g5.xlarge --nodes-min 0 --nodes-max 4 \
    --node-labels workload=gpu --node-taints nvidia.com/gpu=true:NoSchedule
$ aws eks update-nodegroup-version --cluster-name shop-eu --nodegroup-name std

Taints and labels live on the group

Every node the group ever creates carries them automatically, so a GPU group stays reserved without a webhook or DaemonSet to tag nodes.

Managed node groups: an Auto Scaling group with EKS manners

A managed node group is an EKS-level object that owns an Auto Scaling group of EC2 instances in your account. EKS supplies the node bootstrap, registers new nodes with the cluster, cordons and drains nodes before scale-in and during updates, monitors node health, and replaces unhealthy nodes. You choose instance types, minimum and maximum size, labels and taints, the AMI type and the update strategy. Reveal the four layers with the right arrow.

Compared with a self-managed Auto Scaling group, you no longer maintain a bootstrap script or write your own drain-on-terminate logic, and AMI updates are a single API call (update-nodegroup-version) that rolls nodes safely. Taints and labels can be declared on the group so that every future node has them, which is how you reserve a GPU or Spot pool.

The limits of the model are the reason Karpenter exists: a node group has a fixed instance-type list and scales by changing its desired size, driven by the Cluster Autoscaler or by you. Capacity for a Pod with unusual requirements needs a node group shaped for it, so teams end up with a matrix of groups. That is fine for steady, predictable fleets and still very common.

Operational gotchas: set the update configuration's maxUnavailable to control rollout speed, make sure PodDisruptionBudgets allow drains, and spread node groups across the Availability Zones your volumes live in (one group per AZ is common for stateful workloads using zonal EBS volumes).