Elastic Beanstalk新增集群模式：底层依托EKS Auto Mode，开发者质疑为何不做好ECS

亚马逊云科技为Elastic Beanstalk增加了集群模式，将应用程序作为容器运行在由该服务创建和运维的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或控制台进行操作。亚马逊云科技软件工程经理Paul Pollack回应供应商锁定问题时表示，借助集群模式，如有需要可以接管应用程序资源的管理工作。

文档还说明了在Elastic Beanstalk之外更改集群时会发生什么：服务会检测到配置漂移，停止维护集群，不再向其中放置新环境，并阻止更新已运行在该集群中的环境，直到相关变更被撤销。部署选项也比发布博客暗示的更少，博客将不可变部署和流量拆分部署列为集群模式优势，但架构文档只列出了默认的滚动更新和一次性全部更新，不可变部署仍是Beanstalk Standard的功能。

在隔离方面，共享集群中不同环境之间的网络流量默认会被阻止，且无法关闭该限制。对于属于不同最终客户、运行客户无法控制的代码，或受合规制度约束要求基础设施隔离的环境，指南仍建议使用不同的子网集合，从而使用不同的集群。经济性同样取决于共享机制：Elastic Beanstalk不收取平台费用，计算资源按EC2费率计费，但定价页面列出了Standard模式没有的两项费用——每个集群固定的EKS小时费用，以及实例费用之外的EKS Auto Mode管理费，Savings Plans或Spot等EC2折扣无法降低这项管理费。每个负载均衡环境还会获得自己的Application Load Balancer，Pod级指标按资源计量，亚马逊云科技表示这可能导致监控成本高于Standard模式。