EKS Managed Node Groups vs Self-Managed Nodes

EKS managed node groups vs self-managed nodes is a choice about who owns node lifecycle work. Managed node groups are the default when workloads fit the controls EKS exposes. Self-managed nodes are worth the extra work when the workload needs more control over the OS, security, or hardware. The right answer depends on the control your workloads need and the operational burden your team can absorb.

What managed and self-managed node groups actually are, and what differs between them

On update day, EKS orchestrates rolling AMI replacements for a managed node group after your team triggers the update. With self-managed nodes, your team detects the new image, tests it, and runs the replacement process. Both run EC2 instances that are registered to the same EKS control plane. The split is in who manages those instances. GOV.UK’s architecture decision record captures that distinction through upgrades, which managed node groups handle largely automatically while self-managed groups require the team to orchestrate the process.

Underneath a managed node group, EKS creates and manages the Auto Scaling Group and runs the bootstrap script that joins nodes to the cluster. With self-managed nodes, your team provisions that group and maintains the user-data bootstrap script. That ownership extends through provisioning, AMI selection, draining, and replacement. It does not end when a node joins. Fargate is a third option that removes EC2 management entirely, but its constraints, including no DaemonSets, no EBS volumes, and limited observability, put it outside this comparison.

The node lifecycle work that managed node groups remove from your team

The recurring work includes AMI detection, image validation, rolling replacement, node draining, and failure monitoring during rollouts. Managed node groups take over much of that standard lifecycle. An AMI update starts with a single API call. EKS then drains and replaces nodes through a rolling process that respects your max_unavailable setting. Self-managed teams have to build and maintain the equivalent workflow themselves.

For Capacity Blocks for ML, EKS creates a scheduled scaling policy that drains the node group shortly before the reservation ends. That removes a separate piece of termination handling. Teams do not need the AWS Node Termination Handler or custom scale-down automation for that workflow.

GOV.UK’s infrastructure team chose managed node groups while looking at how to upgrade a Kubernetes cluster on a four-month release cycle. With upgrades so often, the team needed a replacement process it could trust, especially because worker updates could be destructive. Managed groups removed much of that orchestration work. The decision also preserved room for later requirements. Adding self-managed groups or Fargate would extend the initial choice.

What your team actually gives up when it chooses managed node groups

Managed node groups trade some OS-level control for simpler operations. In the intended declarative workflow, your team supplies the desired instance type, AMI type, scaling bounds, and launch template overrides, and EKS handles the transition. Post-launch host mutation is not the operating model. SSH changes and custom kernel modules installed on running nodes do not fit that workflow, while kubelet configuration is limited by what EKS exposes.

Custom AMIs make the boundary less absolute, but they also reduce the operational benefit. Managed node groups support custom images. However, when your team specifies a custom AMI ID, EKS no longer selects an updated AMI on its behalf. Your team owns patching the image and initiating node replacement with the new version. Self-managed nodes are an alternative when a custom AMI, a hardened OS, or unexposed kubelet flags leave the team with so much lifecycle work of its own that the managed model no longer helps.

How CVE remediation timelines expose the dependency at the heart of managed node groups

Security patching exposes the sharpest limit of the standard managed model. AWS builds patched EKS-optimized AMIs, but your team is responsible for deploying them. Your rollout has to wait until the image is ready. That creates two separate clocks, one for the provider’s release and another for your deployment. Automation can shorten the second without giving your team control over the first.

CVE-2026-31431 illustrates the cost of that dependency. The vulnerability enables local privilege escalation, container escape, and sandbox bypass through AF_ALG crypto sockets present in EKS-optimized AMIs. The AWS EKS AMI GitHub issue #2699 records reports of teams waiting for a patch during the April–May 2026 exposure window, with AWS Support unable to provide an ETA. A kernel-level fix was required for permanent remediation. AWS’s security bulletin later reported that patched EKS-optimized AMIs were available.

The workaround and the permanent fix were different. The same issue identifies algif_aead as a loadable kernel module, and AWS’s mitigation was to remove it with rmmod algif_aead. Some teams baked the workaround into UserData and Karpenter NodeClasses as a stopgap. Self-managed teams could instead patch custom AMIs and begin rolling replacements without waiting for AWS’s image release. Separately, package updates cannot fix a vulnerable component statically linked into a binary that needs rebuilding, and pod-level hardening is not a substitute for fixing the host kernel.

For security-sensitive teams, control over that patch path can decide the choice. The counterweight is that AWS ships patched AMIs quickly for most vulnerabilities, while a custom image pipeline creates continuous work. This episode was notable because it was an outlier. The decision depends on whether the threat model accepts that exposure window, with security responsibility remaining under either model.

When compliance requirements make self-managed nodes the only viable path

Compliance can require teams to own their images before any vulnerability shows up. Some regulated workloads require CIS Level 2, DISA STIG, or FIPS 140-2 configurations that EKS-optimized AMIs cannot satisfy. Those requirements change the starting point of the decision. When the hardened OS build and lifecycle that a team needs fall outside the managed workflow, self-managed groups let it link its custom AMI pipeline straight to node replacement. Custom AMI support in managed groups means a hardened image alone is not automatically a disqualifier.

The cost is ownership of that pipeline, including its build, testing, maintenance, AMI rotation, and rolling replacement. The nodes otherwise retain equivalent functional capabilities. Choosing self-managed does not mean surrendering instance type flexibility, security groups, custom images, or scaling configuration. Hardened groups can serve only the workloads that require them, leaving managed groups to handle everything else.

GPU workloads and the specific ways the managed-vs-self-managed decision plays out for AI teams

GPU workloads apply the same tradeoff where operational mistakes and idle capacity are expensive. AWS’s EKS user guide recommends managed node groups as the starting point for training and inference when teams are not using EKS Auto Mode or Karpenter. They handle AMI selection, bootstrap, rolling updates, node repair, and graceful draining. The choice still depends on whether the workload needs controls that the managed lifecycle cannot provide.

AWS’s distributed LLM training reference architecture makes that default concrete. It uses a managed system group on c5.2xlarge instances and a managed GPU group on p4d.24xlarge instances, with EFA networking and RAID0 local storage. Managed groups handle lifecycle, software, and cluster integration for that design. AWS’s vLLM deployment guide takes a similar approach. It creates a managed group using p4d.24xlarge instances with 8 NVIDIA A100 GPUs each, EFA enabled, and placement in private subnets for secure, optimized networking.

Dynamic Resource Allocation, or DRA, currently calls for managed or self-managed groups as the established options for GPU management. Karpenter added DRA scheduling support in v1.14, but that support is early-stage and not yet generally available. Capacity reservations are a different question. Both managed groups and Karpenter support Capacity Blocks, with Karpenter using capacityReservationSelectorTerms, so teams can use reservations with either.

NVIDIA’s Run:ai on EKS edge architecture uses managed groups for the Run:ai control plane, but self-managed groups for g5.4xlarge instances in an AWS Local Zone and g4dn.12xlarge instances on an Outpost. Those placements fall outside what managed groups can satisfy. A GPU node costs the same whether busy or idle, so static capacity is a good fit for predictable training and reservations, while Karpenter’s just-in-time provisioning is a better fit when inference demand goes up and down.

How most production clusters resolve the tradeoff in practice through the hybrid pattern

A single EKS cluster can combine managed groups, self-managed groups, and Fargate, using node labels and taints to route pods to the right capacity. The dominant production pattern uses a small managed group of two to three nodes for system components, Karpenter for elastic workloads, and self-managed nodes where custom images or OS configuration require them. Each pool has a distinct job to do. The Run:ai architecture illustrates the managed-and-self-managed part of that split rather than forcing both control-plane and edge workloads into one model.

Static managed groups tend toward overprovisioning when demand varies. Teams that move from managed-only clusters to a mix of node groups and Karpenter say nodes are provisioned faster, idle nodes are deleted automatically, and EC2 costs are lower. Those gains come from matching capacity to demand. They are not an argument for taking over AMI maintenance where the workload gains nothing from it.

The practical decision therefore starts with three questions. Do the workloads require a custom AMI or specific kernel configuration. Do compliance requirements call for a pipeline to build a hardened OS. Can the team accept AMI patch dependency on AWS release schedules. If the workloads need no custom OS or build and the team can accept the patch dependency, managed groups do the lifecycle work, while self-managed nodes cost more without giving the team anything in return.

Where EKS Auto Mode fits and what it changes about the decision

EKS Auto Mode gives AWS more of the work by putting it in charge of the node layer. It provisions EC2 instances with Karpenter-style logic, patches and replaces them on a maximum 21-day lifetime, and manages networking, DNS, block storage, and load balancing rather than leaving them as add-ons your team installs. As of July 2026, Auto Mode management fees were cut for G-series and more substantially for P-series and Trainium instances. Those changes make it more competitive for GPU workloads.

With this extra automation, teams have less control than they do with standard managed groups. The need for custom AMIs, compliance-hardened OS images, or DRA-based GPU scheduling is therefore at least as strong a reason to rule out Auto Mode. It changes how much work AWS can absorb when the workload fits its boundaries. The underlying decision remains how much OS-level control the workload requires and how much node lifecycle work the team is prepared to own.

A PaaS layer above EKS can let another operator make that choice and run the cluster inside the team’s own cloud account. The platform then handles node group configuration, AMI rotation, CVE patching, and autoscaling, leaving engineers focused on workload configuration. The lifecycle work still needs an owner. Whether that owner is AWS, a platform provider, or the team itself, extra control is worth paying for only when the workload requires it.