Node Groups: Managed, Self-Managed, and Fargate

Three Ways to Run Your Workloads

Before diving into networking, it is important to understand the three distinct ways EKS can run your pods, because the choice affects cost, operational burden, and capability.

1. Managed Node Groups (MNG)
AWS provisions and manages EC2 instances for you. You define the instance type, AMI, and scaling bounds. AWS handles:
- Launching nodes with the correct EKS-optimized AMI
- Draining nodes gracefully before termination
- Rolling updates when you change the node group configuration

This is the most common choice for general workloads. You still pay for the EC2 instances, but the operational overhead of node lifecycle management is reduced significantly.

2. Self-Managed Node Groups
You manage the EC2 instances yourself using an Auto Scaling Group. You are responsible for:
- Choosing and updating the AMI
- Bootstrapping nodes to join the cluster
- Draining nodes before termination

Use this when you need deep customization — custom AMIs, specific kernel parameters, or instance types not yet supported by Managed Node Groups.

3. AWS Fargate
There are no EC2 nodes at all. AWS runs each pod in its own isolated micro-VM. You define a Fargate Profile that matches pods by namespace and labels, and AWS handles all underlying infrastructure.

• Pro: Zero node management. No patching, no capacity planning.
• Con: No DaemonSets, no privileged containers, no GPU support, higher per-pod cost, and cold start latency.
• Best for: Batch jobs, infrequent workloads, or teams that want to eliminate node operations entirely.