Elastic Beanstalk新增EKS集群模式

亚马逊云科技为 Elastic Beanstalk 增加了新的 Cluster 模式，应用可作为容器运行在由服务自动创建和运维的 Amazon EKS 集群上。原有基于 EC2 的环境类型仍然保留，并被称为 Beanstalk Standard，两种模式继续沿用应用、版本、环境等既有概念。官方文档进一步披露了发布说明中未展开的部署、访问与隔离限制。

Beanstalk Cluster 面向希望在共享基础设施上运行多组应用的团队。开发者可以提交源代码、Dockerfile，或使用 Amazon ECR 中的容器镜像；如果使用源代码，系统会在客户账户内通过 AWS CodeBuild 结合 Cloud Native Buildpacks 构建镜像。底层节点由 EKS Auto Mode 提供，可观测能力则集成 OpenTelemetry。

该模式下，用户不能手动挑选集群。同一账户内使用相同 VPC 子网集合的环境会进入同一个集群，不同子网集合则会触发不同集群。集群首次创建大约需要 10 分钟，Kubernetes 版本、集群选择以及既有环境的子网和集群 IAM 角色均不可自行修改；若配置有误，只能重建环境。集群基础设施访问也由服务托管，用户主要通过 Elastic Beanstalk API、AWS CLI 或控制台操作。若在服务外部修改集群，平台会识别为配置漂移，并停止维护该集群、停止放置新环境，同时阻止更新已有环境，直到变更被撤销。

部署能力方面，实际文档显示的选项比发布介绍更有限。虽然相关介绍提到不可变部署和流量拆分部署，但架构文档仅列出滚动更新和一次性全部更新，最新说明也未列出上述高级部署方式；不可变部署目前仍属于 Beanstalk Standard 的能力。

隔离与合规是该模式的另一个重点。共享集群中，不同环境之间的网络流量默认被阻断，且该限制不能关闭。不过，对于不同最终客户、运行客户不可控代码，或受监管要求必须隔离基础设施的场景，官方仍建议使用不同子网集合以获得独立集群。与此同时，Elastic Beanstalk 被列入 HIPAA、PCI DSS、SOC、FedRAMP、IRAP 等合规项目适用范围。

成本结构取决于共享程度。Elastic Beanstalk 本身不收平台费，计算资源按 EC2 计费，但 Cluster 模式还会产生每个集群固定的 EKS 小时费用，以及 EKS Auto Mode 管理费，后者不能通过 Savings Plans 或 Spot 等 EC2 折扣降低。每个负载均衡环境还会拥有独立的 Application Load Balancer，Pod 级指标也会按资源计量，监控成本可能高于 Standard。成本优势主要来自共享节点；若使用独立集群，成本更高且容量利用率更低。Standard 模式则被定位为适合少量或较小规模应用的低成本选择，并且仍是支持 Windows 的模式。

新模式也引发了产品定位讨论。有开发者质疑它与 EKS、EKS Auto Mode、ECS、ECS Express Mode、经典 Beanstalk、Lambda 容器及 Lambda Managed Instances 的边界，并认为其与 ECS 的重叠尤其明显，不如集中资源把其中一项服务打磨得更好。对评估该模式的团队而言，子网集合将决定环境所在集群、是否共享基础设施以及潜在节省空间，且后续无法修改。应用还需符合无状态设计，副本应可互换，本地存储只能临时使用；若不配置子网，环境会被放入默认 VPC 的公有子网。该模式已在 Elastic Beanstalk 覆盖的所有亚马逊云科技商业区域上线，但不适用于 AWS Free Tier，可通过控制台、AWS CLI、EB CLI、CloudFormation、Terraform、GitHub Action 和智能体技能部署。