为何AWS为EKS节点组创建eks前缀启动模板而非使用CFN定义的模板

结论 #

你观察到的创建EKS托管节点组时生成两个启动模板的行为是预期的官方默认行为，不属于配置错误或CloudFormation部署异常。

核心设计原因 #

• 配置隔离：AWS不会直接修改用户提交的自定义启动模板，避免污染用户的原始配置、导致用户后续更新自定义模板时出现版本冲突。生成的eks-前缀启动模板属于EKS内部使用的中间资源，完全由AWS侧托管维护，生命周期和对应的节点组绑定。
• 托管逻辑独立：当你在节点组配置中指定AmiType而非自定义AMI时，EKS需要自动注入节点接入集群必需的引导逻辑（即调用/etc/eks/bootstrap.sh的脚本），这部分逻辑由EKS服务侧动态生成，包含当前集群的CA证书、API Server地址、集群DNS地址等动态参数，需要和你自定义的UserData合并为完整的MIME多段格式配置，因此需要生成新的启动模板存储合并后的完整配置。
• 溯源能力保障：你观察到引导脚本中eks.amazonaws.com/sourceLaunchTemplateId字段指向你原始的自定义启动模板，是为了保留配置溯源链路，方便你关联节点配置和你提交的自定义模板，也支持你后续迭代自定义启动模板版本时，EKS可以正确拉取最新版本重新生成合并后的启动模板。

可选优化方案 #

如果你不需要EKS自动注入集群引导逻辑，可以按照官方规范使用自定义AMI模式：

• 在你的启动模板中显式指定ImageId（自定义AMI ID）
• 删除EKS节点组配置中的AmiType参数
• 自行在自定义UserData中实现EKS节点接入集群的引导逻辑

这种场景下EKS会直接使用你提交的自定义启动模板创建节点，不会再额外生成eks-前缀的启动模板。

内容的提问来源于stack exchange，提问作者satya