Skip to main content
In this guide, we’ll dive into Amazon EKS Node Groups—the primary compute resource for your EKS cluster. A Node Group is simply a collection of EC2 instances (nodes) that register with the EKS control plane and run your Kubernetes workloads.
The image shows a diagram labeled "Node Groups" with an "EKS Cluster" containing an "EC2 Instance" icon.

​
Unmanaged Node Groups

Before Managed Node Groups existed, you had to “bring your own” nodes. You’d create an Auto Scaling Group (ASG) to launch EC2 instances and register each kubelet with your EKS API server. Scaling up or down was similar to managing a Deployment’s replica count.
The image illustrates unmanaged node groups with a speech bubble requesting a specific type of EC2 instance, alongside a scale indicating the ability to scale up or down.
With unmanaged Node Groups, you were responsible for:
  • Creating and configuring the Auto Scaling Group
  • Ensuring nodes join the correct cluster via kubelet
  • Managing IAM roles and instance credentials
  • Handling node lifecycle tasks (drain, replace, upgrade)
The image is a diagram titled "Unmanaged Node Groups," showing four components: Autoscaling Group, Node Placement, Kubelet Clustering, and IAM Credentials, all associated with a customer.
This approach worked, but it placed the full operational burden on you.

​
Managed Node Groups

AWS Managed Node Groups simplify node operations by handling ASG provisioning, kubelet registration, and automated upgrades.
The image shows a comparison between unmanaged and managed node groups, each represented by three hexagons with gear icons inside.

​
Feature Comparison

FeatureUnmanaged Node GroupsManaged Node Groups
Auto Scaling GroupYou configure ASGAWS manages ASG
AMI SelectionManual AMI bakingLaunch template support
Kubernetes Node RegistrationManual kubelet setupAutomated registration
IAM Role ManagementManual role attachmentIAM roles handled by AWS
Rolling UpgradesCustom scripts requiredBuilt-in upgrade flow
By offloading these tasks, you can focus on your workloads instead of operational overhead.

​
Node Group Fundamentals

Under the hood, every Node Group—managed or unmanaged—follows this workflow:
  1. You request nodes from EKS via the AWS API.
  2. The ASG spins up EC2 instances.
  3. Each node registers its kubelet with the EKS API server.
  4. Your Kubernetes scheduler places pods onto these nodes.
You can run multiple Node Groups per cluster—for high availability, GPU workloads, or mixed instance types.
The image is a diagram illustrating how a node group works, showing nodes connected to an API server with memory and GPU specifications. It includes labels for node groups, memory, GPU, and instance type.

​
Scaling, Fargate, and Cluster Autoscaler

Label and taint your Node Groups to direct workloads where they belong—GPU jobs to GPU nodes, memory-heavy pods to high-memory instances, and so on. Keep each Node Group’s instance types similar to balance performance and cost. Some control-plane add-ons or lightweight services (like the Cluster Autoscaler itself) can run on AWS Fargate to avoid scaling across many Node Groups.
The image illustrates how a node group works, showing nodes organized into groups connected to an API server, with components like Fargate and Cluster Autoscaler.
Use taints and tolerations to isolate workloads to specific Node Groups and prevent scheduling conflicts.

​
Custom AMIs with Managed Node Groups

If you need hardened or pre-baked images, Managed Node Groups support custom AMIs via launch templates. You can supply your own AMI ID, user data, and instance type overrides.
The image outlines the benefits of Managed Node Groups, highlighting "Custom Amazon Managed Image (AMI)" and "Managed upgrades."

​
Managed Upgrades and Churn

The standout feature of Managed Node Groups is built-in upgrades. When you bump your control plane version, AWS will:
  1. Generate a new launch template with the updated AMI/library versions
  2. Roll the ASG: terminate old nodes and launch new ones
  3. Drain each node so pods gracefully migrate
During this replacement, pods may be scheduled onto new and old nodes multiple times, causing churn. The Cluster Autoscaler may also react, so coordinate your upgrades carefully.
The image illustrates a diagram of a cloud computing architecture involving Fargate, a cluster autoscaler, and a node group with multiple nodes. It shows the relationship between these components in managing churning workloads.
Pod disruptions are expected during Node Group upgrades. Plan for kubectl drain windows and monitor the Cluster Autoscaler to avoid unexpected scale events.
Node Groups—whether unmanaged or AWS-managed—are the standard way to run Kubernetes nodes in EKS. Understanding their architecture, scaling patterns, and upgrade behavior ensures you build reliable, cost-effective clusters.

Watch Video