Elastic Beanstalk 新增了 Cluster Mode。启用后，应用会运行在由 Elastic Beanstalk 创建并运维的 Amazon EKS 集群上。这个模式降低了团队直接管理 Kubernetes 控制面的负担，但也引入了新的架构约束：集群按子网集合分配，分配后不能修改；集群访问由服务管理；计费中还会增加 EKS 与 Auto Mode 相关费用。
共享的是集群，关键边界是子网集合
Cluster Mode 的核心不是“让开发者获得一个 EKS 集群”，而是让 Elastic Beanstalk 使用 EKS 承载应用，并继续负责底层集群的创建与运维。团队得到的是更托管化的应用平台，而不是完整的 Kubernetes 管理权限。
这里最需要提前确定的是子网集合。Elastic Beanstalk 会根据应用配置的 subnet set 分配集群，而且这个关联之后不能更改。因此，子网不能再被当成一个随时可调整的普通网络参数，它实际上参与定义了应用落在哪个共享集群边界内。
这会影响环境设计：
- 开发、测试和生产环境不应随意复用同一组子网。
- 需要隔离的业务应在创建环境前规划独立的子网集合。
- 如果未来需要更换子网集合，应把它视为一次迁移，而不是一次简单的原地配置修改。
- 网络地址空间、可用区和路由设计需要比应用部署更早确定。
换句话说，Cluster Mode 将部分“集群规划”转化成了“网络规划”。子网集合选错后，修正成本通常高于修改一项普通环境变量。
权限、信任边界与成本不能沿用 EC2 思路
Cluster Mode 下的直接集群访问由服务管理。应用团队不应假设自己能像管理自建 EKS 那样，长期依赖管理员级 kubectl、直接修改控制面配置，或者安装任意集群级组件。评估现有系统时，应重点排查是否存在这些隐含依赖。
共享集群也不等于所有工作负载都适合混合部署。AWS 建议为不受信任或受监管的工作负载使用独立集群。实践中，可以按以下维度划分隔离边界：
- 是否执行第三方或用户提交的代码；
- 是否处理支付、医疗或其他受监管数据；
- 是否要求独立审计、变更审批或故障域；
- 是否属于不同安全等级或不同组织的工作负载。
如果答案指向更严格的隔离要求，就不应只为了提高共享率而复用集群。
成本模型也发生了变化。除应用使用的计算、存储和网络资源外，还要计算 EKS 与 Auto Mode 费用。已有的 EC2 折扣不会降低这两类费用。因此，不能只把当前实例账单代入新模式，还应单独估算：
Cluster Mode 月成本
= 应用工作负载资源费用
+ EKS 费用
+ Auto Mode 费用
+ 存储、网络及其他关联服务费用
具体单价和计费维度应以部署区域的最新 AWS 定价为准。对于小型环境，固定或平台层费用可能尤其显眼；对于大量应用，共享集群带来的运维简化则可能更有价值。
上线前先固定并校验子网集合
下面的脚本不是创建 Cluster Mode 环境的命令，而是一个可以直接放进部署前检查或 CI 流程的网络校验示例。运行前替换区域和子网 ID，并确保本机已经配置 AWS CLI 凭证。
#!/usr/bin/env bash
set -euo pipefail
REGION="us-east-1"
SUBNET_IDS=(
"subnet-0123456789abcdef0"
"subnet-0fedcba9876543210"
)
echo "Subnet inventory:"
aws ec2 describe-subnets \
--region "$REGION" \
--subnet-ids "${SUBNET_IDS[@]}" \
--query 'Subnets[].{SubnetId:SubnetId,VpcId:VpcId,AZ:AvailabilityZone,CIDR:CidrBlock,AvailableIPs:AvailableIpAddressCount}' \
--output table
mapfile -t VPCS < <(
aws ec2 describe-subnets \
--region "$REGION" \
--subnet-ids "${SUBNET_IDS[@]}" \
--query 'Subnets[].VpcId' \
--output text | tr '\t' '\n' | sed '/^$/d' | sort -u
)
if (( ${#VPCS[@]} != 1 )); then
echo "ERROR: all subnets must belong to one planned VPC boundary" >&2
exit 1
fi
FINGERPRINT=$(
printf '%s\n' "${SUBNET_IDS[@]}" | sort | sha256sum | awk '{print $1}'
)
printf 'Validated VPC: %s\n' "${VPCS[0]}"
printf 'Subnet-set fingerprint: %s\n' "$FINGERPRINT"
这个脚本做了三件事：列出子网的 VPC、可用区和剩余地址；阻止来自多个 VPC 的子网被误组成一套配置；为排序后的子网集合生成稳定指纹。
可以把指纹写入环境配置仓库或变更单，例如：
environment: production
region: us-east-1
network_boundary:
subnet_ids:
- subnet-0123456789abcdef0
- subnet-0fedcba9876543210
subnet_set_fingerprint: "replace-with-script-output"
security_classification: regulated
cluster_isolation: dedicated
这份 YAML 是治理示例，不是 AWS 官方的 Cluster Mode 配置格式。它的作用是让代码评审人员清楚看到：子网集合、数据等级和隔离决策必须一起变更，而不是在控制台中临时选择。
是否采用：先回答五个问题
Cluster Mode 更适合希望保留 Elastic Beanstalk 应用体验、同时把容器工作负载放到服务托管 EKS 基础设施上的团队。落地前可以逐项确认：
- 子网集合是否已经稳定，并能作为长期集群分配边界？
- 应用是否依赖直接的 Kubernetes 管理员访问或集群级扩展？
- 不受信任、生产和受监管工作负载是否已经规划独立集群？
- 成本测算是否单列了 EKS 与 Auto Mode 费用，而不是只看 EC2 折扣后的价格？
- 如果未来必须更换子网，团队是否准备好了迁移、验证与回滚方案？
如果这些问题都有明确答案，Cluster Mode 可以减少自建 EKS 的日常运维工作。反之，如果系统要求完全控制集群、频繁调整网络边界，或必须安装大量集群级组件，自主管理 EKS 仍可能是更合适的选择。