容器服务托管入口网关：从自建负载均衡迁移前的六组检查项

把一个容器服务的入口从自建负载均衡迁到托管资源，判断标准不是"托管能不能替我做"，而是"我原来的入口责任里，哪些可以交给平台侧统一表达，哪些必须由我自己核对"。本文以 2026 年 10 月发布的 Amazon ECS Gateway 作为已公开的参照样本，拆出迁移前应当逐项确认的六组检查项。

需要先说明范围：以下关于网关行为、配额与限制的事实，均来自 AWS 的发布说明（Introducing Amazon ECS Gateway，来源日期 2026 年 10 月 20 日）。其他容器平台的等价能力是否存在、字段是否一致，本文不作断言，需要按同样维度自行核对。

先看清托管层接走了哪些责任#

ECS Gateway 被定义为一个账户级资源：平台团队创建并配置网关，在其中集中定义子网、安全组、TLS 证书、监听器设置和 WAF web ACL，然后把网关关联到一个或多个 ECS 集群。应用团队则在创建或更新服务时添加一个 gateway connector 参数，由 ECS 自动为该服务准备资源。

这张表解释了迁移的真正收益：减少的是重复配置与配置漂移，而不是入口本身的复杂度。复杂度被搬到了平台侧，因此下面的检查项大多也落在平台侧。

检查项一：可用区是否构成子集关系#

发布说明给出的硬条件是：服务的可用区必须是该集群上每个网关可用区的子集。原因很直接——网关的 ALB 只会把流量路由到它有子网的那些可用区。官方同时建议，为同一个集群创建网关和服务时使用同一组可用区。

迁移时这一条容易被忽略：自建 ALB 时，可用区覆盖往往是隐式满足的（因为你在同一批子网里建了 ALB 和目标）。改成托管后，网关由平台团队按组织标准创建，服务由应用团队声明，两边的可用区集合可能不一致。建议在迁移清单里加一条显式核对：列出每个集群的网关可用区集合，再比对将要接入的服务子网集合。

检查项二：容量上限带来的硬失败#

发布说明里有三个数量关系需要记住：单个 ALB 最多承载 25 个服务；maxAlbCount 的默认配额是 10；一个网关最多关联 10,000 个集群，一个集群最多关联 5 个网关。

关键在失败模式：当 maxAlbCount 已达到且没有可用容量的 ALB 时，部署会失败。这不是降级，而是发布被阻断。所以迁移前应按预期接入的服务数量估算所需 ALB 数，并把这一项写进发布门禁——尤其是服务数量会持续增长的组织，默认值 10 很可能不够。

25 个服务共享一个 ALB 是官方给出的成本优化点，但它同时意味着共享 ALB 上的指标是混在一起的，这一点会在第六组检查项里再提。

检查项三：接入的兼容条件#

部署时，ECS 会评估集群关联的所有网关，把服务连接到每一个兼容的网关。兼容需要同时满足三条：网关的访问类型匹配服务连接器里的过滤器（例如 accessTypes 为 PUBLIC）；网关与服务在同一 VPC；网关覆盖服务所配置子网用到的全部可用区。

由此可以推出一个需要提前想清楚的点：所谓"连接到每一个兼容网关"，意味着一个服务可能同时拥有多个入口。DNS 记录、安全组规则、以及下游调用方的白名单如果默认"一个服务一个入口"，在接入多个网关（例如一个公网、一个 VPC 内网）时需要重新审视。

检查项四：渐进迁移路径与生效时点#

对已有自建负载均衡的服务，发布说明给出的路径是：调用 UpdateService 添加 gateway connector，两条入口路径保持并存，验证网关连接正常后再移除原有负载均衡配置。这条路径的价值在于回滚成本低——旧入口在验证期间没有被动过。

另一个必须理解的时点问题是：服务反映的是部署时集群网关的状态。每次部署时 ECS 重新评估关联——期间新增的兼容网关会接入，被解除关联的网关会断开并移除路由。换句话说，在网关上做关联变更不会立即影响正在运行的服务，要等该服务下一次部署才收敛。迁移期间如果期望"改完网关马上生效"，就会误判。

检查项五：创建后不可变的字段#

发布说明明确列出，网关创建后不能修改的设置包括：名称、scheme（公网或 VPC 内网）、VPC、子网、IP 地址类型、监听器协议与端口。可调整的则包括监听器与端口之外的部分附加设置、maxAlbCount 与 WAF web ACL。

这是一个典型的"先设计后创建"约束。如果后续要换 VPC 或调整子网，按已披露的信息只能重建网关并重新关联集群。建议在迁移方案里先把这几项确定下来：VPC 归属、子网集合、公网还是内网、监听协议与端口。

另外，服务的生命周期与入口资源是绑定的：删除服务时，ECS 会自动断开该服务与所有网关的连接、移除路由并清理按服务创建的资源；如果该服务占用的是某个 ALB 上的最后一条路由，这个 ALB 会被回收。清理是自动的，但这也意味着排查历史路由时不能指望它还在。

检查项六：可观测性与成本归属#

共享 ALB 会让指标口径发生变化。发布说明给出的做法是：在 CloudWatch 中使用 ALB 指标时，用 TargetGroup 维度看单个服务的流量，用 LoadBalancer 维度看整个共享 ALB 的流量；用 describe-target-health 查看实时目标状态。告警建议覆盖 HealthyHostCount、TargetResponseTime 和 HTTPCode_Target_5XX_Count，并基于网关 ARN 打标签，让监控随 maxAlbCount 自动扩展。

成本方面，发布说明称 ECS Gateway 在所有 ECS 可用的商业区域提供且不额外收费，只需为账户内实际创建的底层基础设施付费，包括适用的 ALB 费用、CloudWatch 日志与指标、ACM 证书和数据传输。具体的区域清单与单价不在本次材料范围内，属于待核实项。

一个最小示例（未执行）#

下面的命令按发布说明中的字段整理，账号、子网与 ARN 均替换为占位值。该示例未实际执行，仅用于说明参数结构。

# 文档结构示例；未执行。账号 ID、子网均为占位。
aws ecs create-gateway \
  --name my-team-gateway \
  --infrastructure-role-arn arn:aws:iam::<ACCOUNT_ID>:role/ECSGatewayRole \
  --configuration '{
    "HostSharedAlb": {
      "networkConfiguration": {
        "subnets": ["subnet-xxxxxxxx", "subnet-yyyyyyyy"],
        "ipAddressType": "ipv4"
      },
      "scheme": "internet-facing"
    }
  }'

aws ecs associate-gateway-with-cluster \
  --gateway my-team-gateway \
  --cluster arn:aws:ecs:<REGION>:<ACCOUNT_ID>:cluster/my-cluster

服务侧的连接器通过 --gateway-connectors 传入，包含 portName、filters.accessTypes 与健康检查配置；健康检查的具体字段应按对应平台的文档填写，此处从略。需要注意，创建网关时并不会立刻创建任何基础设施，要等第一个服务带上连接器接入才会开始。

边界与待核实#

• 本次材料只覆盖 AWS 的一个产品，其他云厂商或自建方案是否存在同等语义的托管入口，未作核对。
• 自动配置的 ACM 证书覆盖哪些域名、能否复用已有通配符证书，材料未说明，待核实。
• 配额提升的申请流程、maxAlbCount 可提升到的上限，待核实。
• 已有 WAF 规则迁移到网关级 web ACL 的具体差异，材料未涉及。
• 具体区域的可用性清单与底层资源单价，待核实。

把入口迁到托管资源，本质上是一次责任重新划分。判断是否准备好了，可以回到六个问题：可用区集合是否对齐、ALB 容量是否留有增长余量、服务是否满足接入兼容条件、是否打算用两条入口并存的渐进路径、不可变字段是否一次定好、指标能否从共享 ALB 中拆到单服务。这六项都答得上来，迁移才是一次配置收敛，而不是把复杂度换了个地方存放。