Windows Core Custom AMI Works Manually but Fails to Join EKS When Used in Self-Managed Node Group (EKS 1.33)

When using a custom Windows AMI with eksctl self-managed node groups, there are several key considerations that could explain why your AMI works manually but fails in the node group:

Bootstrap Command Requirements

Yes, eksctl does require special handling when using custom AMIs. For self-managed node groups with custom AMIs, you typically need to provide an overrideBootstrapCommand that properly configures the node to join your EKS cluster. The bootstrap script must call /etc/eks/bootstrap.sh (or the Windows equivalent) with the correct cluster name and any necessary kubelet arguments.

When you launch manually, you're likely running the bootstrap process yourself, which is why it works. However, when launched through eksctl, the default bootstrap process may not be compatible with your custom AMI, causing the node to fail to join the cluster.

AMI Type Configuration

When using a custom AMI with a launch template or node group configuration, the amiType should be set to CUSTOM. If you're specifying a launch template with a custom AMI, you should not specify an amiType at all, as this can cause deployment failures.

Windows-Specific Considerations

For Windows custom AMIs, you also need to ensure that eks:kube-proxy-windows is added to your Windows nodes' role ARN in the aws-auth ConfigMap. This is a specific requirement for Windows nodes that may not be automatically configured when using a custom AMI.

Recommended Solution

In your eksctl configuration, add an overrideBootstrapCommand that includes the proper bootstrap script execution with your cluster name and any required kubelet extra arguments. This ensures the node properly registers with your EKS cluster when launched through the node group, matching the manual process that works successfully.
Sources
EKS managed nodegroups - Eksctl User Guide
AWS::EKS::Nodegroup - AWS CloudFormation