Which strategy should I use for EKS AL2 Node Group Migration to AL2023 or Bottlerocket Before June 30,?
Kubernetes operators on EKS need to choose whether AL2023 or Bottlerocket is the better node OS destination before Amazon Linux 2 support ends on June 30, 2026.
Blockers
- runtime/amazon-linux-2 incompatible with framework/kubernetes-1-33: Kubernetes 1.32 is the last EKS version that gets AL2 AMIs; AL2023 and Bottlerocket are available for 1.33 and higher.
- requires_version: runtime/amazon-linux-2023 → package/amazon-vpc-cni-1-16-2
- breaking_change_in: runtime/amazon-linux-2023 → protocol/imdsv2
- breaking_change_in: runtime/amazon-linux-2023 → capability/nodeadm-bootstrap
Who this is for
- cost-sensitive
- enterprise
- compliance
Candidates
Migrate EKS node groups to Amazon Linux 2023
Amazon EKS stopped publishing EKS-optimized AL2 AMIs on November 26, 2025, and Kubernetes 1.32 is the last EKS version that gets AL2 AMIs; AL2023 and Bottlerocket are available for supported versions including 1.33 and higher. AL2023 is the general-purpose successor to AL2, and Amazon Linux 2023 support runs until June 2029. As of 2026-04-09, Amazon Linux 2023 has no additional OS charge on EC2, while EKS pricing still bills clusters per hour and worker nodes as EC2, EBS, public IPv4, and related AWS resource usage. The main differentiator is that AL2023 preserves a more conventional Linux operating model while moving EKS to `cgroupv2`, `IMDSv2` by default, and the newer `nodeadm` bootstrap flow.
When to choose
Use this when you need the least cultural change from AL2, still require host-level customization, or depend on agents and workflows that expect a conventional Linux host. It is the safer default when your workloads are not fully container-pure and you need broad compatibility with existing operational tooling.
Tradeoffs
Pros: familiar Linux environment, long support runway, no extra AL2023 OS fee on EC2, and better fit for host customizations. Cons: migration is not drop-in because AL2023 changes bootstrap behavior, package availability, metadata access defaults, and cgroup behavior.
Cautions
AL2023 introduces `nodeadm`, so self-managed nodes or launch-template-based nodes must provide cluster metadata such as `apiServerEndpoint`, `certificateAuthority`, and service `cidr` explicitly instead of relying on the old AL2 bootstrap discovery flow. Amazon VPC CNI 1.16.2 or later is required. `IMDSv2` is on by default, managed node groups without a launch template default hop limit to `1`, and blue/green migration is required for many existing managed node groups that were using the standard launch template path. AL2023 also drops or changes some AL2-era packages, including the lack of `amazon-linux-extras` and unsupported EPEL.
Migrate EKS node groups to Bottlerocket
Bottlerocket is AWS-sponsored, purpose-built for container hosts, and EKS documents it as available for managed node groups, self-managed nodes, and Karpenter. The same EKS AL2 cutoff applies here: EKS stopped publishing AL2 AMIs on November 26, 2025, and AL2023 or Bottlerocket are the supported destinations for Kubernetes 1.33 and higher. As of 2026-04-09, EKS pricing still bills the cluster and underlying worker resources rather than listing a Bottlerocket node-OS surcharge, and Bottlerocket itself is open source. Its key differentiator is the minimal, immutable host design with atomic updates, smaller footprint, and fewer host-management surfaces.
When to choose
Use this when your nodes are truly container-focused, you want lower host-management overhead, and your security posture benefits from a smaller attack surface and atomic OS updates. It is the better fit when you can standardize on orchestrator-driven operations and avoid host-by-host customization.
Tradeoffs
Pros: smaller footprint, shorter boot times, atomic rollback-capable updates, reduced management complexity, and strong alignment with container-native operations. Cons: much less flexibility for host customization, no normal SSH-first workflow, and more friction if your estate relies on host-installed agents or manual node debugging.
Cautions
Bottlerocket images do not include an SSH server or a shell. Operational access is centered on a control container with AWS Systems Manager support, and the admin container is recommended only for development and testing, not production. AWS states Bottlerocket is a poor fit if you need to install host software with package managers, customize each instance individually, or run non-containerized third-party host agents. Bottlerocket updates require reboots, so you need a controlled rollout pattern for stateful or disruption-sensitive workloads.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for EKS AL2 Node Group Migration to AL2023 or Bottlerocket Before June 30,?"