Amazon ECS Gateway 责任划分：托管入口网关替代自建负载均衡时，谁管什么

Amazon ECS Gateway 把入口网络拆成三层责任：平台团队在一处定义网关级标准（子网、安全组、TLS 证书、listener 设置、WAF web ACL），应用团队只在服务定义里加一个 gateway connector，而每个服务需要的 ACM 证书、唯一 DNS 主机名、listener 规则、target group 和服务安全组，由 ECS 在你的账户内自动创建与回收。替代自建负载均衡时，真正变化的不是“少配几个资源”，而是把“每个服务各自配一遍 ALB 和证书”换成“网关级共享配置加服务级声明”。本文依据 AWS 官方博客 2026 年 10 月 20 日的发布正文整理（Introducing Amazon ECS Gateway），未做实际部署验证；配额与计费细节请以官方文档为准。

责任为什么需要重新划分#

材料对旧做法的描述很具体：每上一个新服务，团队都要置备并连接 ALB、ACM 证书、WAF web ACL 和安全组，并在服务扩容、更新、运维时保持这些资源同步。结果是每个服务都重复一遍网络配置，跨团队的配置漂移风险随服务数量上升。

ECS Gateway 的应对方式是把这部分工作按角色切开：

有一点容易被“全托管”三个字盖过去：材料明确所有资源直接创建在你的账户内，ECS 是借你提供的 IAM infrastructure role 去置备 ALB、安全组和证书。由此可以直接推出，这个角色的权限范围、账户内的配额占用、成本归属和资源治理，仍然落在你这边。这是责任划分中新增的一层，而不是被托管掉的一层。

平台团队的边界：一次定义，部分不可回退#

创建网关需要三样东西：账户内唯一的网关名称、一个 infrastructure role，以及一个 configuration 对象。可选设置包括 listener、端口、网关可扩容到的负载均衡器最大数量（maxAlbCount）和 web ACL。

材料列出了一组创建后无法更改的字段：名称、scheme、VPC、子网、IP 地址类型、listener 协议与端口。这意味着入口网络的基本形状必须在建网关之前定下来。建议把这几个字段单独列成一次设计评审的检查项，而不是等在控制台里试出来——这是基于不可变字段的工程建议，不是材料给出的流程。

网关与集群是多对多关系：一个网关最多可关联 10,000 个集群，一个集群最多支持 5 个网关关联。材料给出的用法是按环境共享同一个网关，或给同一集群挂多个网关（例如 public 与 private 各一个）。访问控制也在这里：平台团队决定哪些网关关联哪些集群，需要更细的隔离时，用 IAM 策略限制谁能往特定集群部署服务。

应用团队的边界：connector 里只有三件事#

应用侧的动作是给服务加 connector。下面是依据官方博客示例改写的骨架，未执行，其中 healthCheck 在原示例中以省略形式出现，实际字段需查官方文档；账号 ID 一类内容为文档占位值。

aws ecs create-service \
  --cluster my-cluster \
  --service my-api-service \
  --task-definition my-api-service:1 \
  --gateway-connectors '[{
    "portName": "api",
    "filters": {"accessTypes": ["PUBLIC"]},
    "healthCheck": { ... }
  }]'

部署时，ECS 会评估该集群已关联的网关，并把这个服务连接到每一个兼容的网关。兼容有三个条件：网关的访问类型与 connector 的 filter 匹配；网关与服务在同一 VPC；网关覆盖服务所配置子网用到的所有可用区。因此一个服务同时被多个网关接入属于正常形态，而不是配置错误。

每建立一条连接，ECS 会自动准备该服务专属的资源：一张 ACM 证书、一个唯一 DNS 主机名、一条把该主机名流量导向服务 target group 的 listener 规则，以及一个只放行来自 ALB 安全组入站流量的服务安全组。服务创建完成后网关路由变为 ACTIVE，服务 URL 即可接收流量。反过来说，绕过网关直连任务在网络层是走不通的——这一条是对“仅允许来自 ALB 入站”的直接推论。

生命周期与灰度迁移#

• 每次部署重新评估：上次部署之后新关联的网关会被接上；被解除关联的网关会断开并移除路由。服务反映的是部署那一刻集群网关的状态，而不是实时跟随。
• 删除服务：ECS 自动断开该服务与所有网关的连接、移除全部路由并清理每服务资源；如果这个服务持有某 ALB 上的最后一条路由，该 ALB 会被回收。
• 增量迁移：已有自建负载均衡的服务，可以调用 UpdateService 加上 connector，两条入口路径同时可用，验证网关连接后再移除原有负载均衡配置。

针对迁移，建议按下面的顺序推进（工程建议，非材料内容）：先挑一个非生产服务加 connector；用 describe-target-health 确认目标注册与健康状态；对比新旧入口的响应和 5XX 情况；确认无误后再考虑下线旧负载均衡或切换上游 DNS。这样任何一步出问题都还留着回退路径。

六个容易忽略的边界#

1. 容量是双向约束：maxAlbCount 达到上限且没有 ALB 有余量时，部署会失败，该配额默认值为 10。材料同时提到单个 ALB 最多可让 25 个服务共享，因此规划时要把预期服务数和 ALB 数一起算。该配额是否可调高，材料未说明，待核实。
2. 可用区必须是子集：服务的可用区要落在网关可用区之内，ALB 只会把流量路由到它有子网的那些可用区里的任务。材料直接建议同一集群的网关和服务使用同一组可用区。
3. 网络模式限定：只适用于使用 awsvpc 网络模式的 ECS 服务，覆盖 EC2、Fargate 和 ECS Managed Instances 三种 launch type。
4. 可观测要分两个维度：按 TargetGroup 维度看单个服务的流量，按 LoadBalancer 维度看共享 ALB 的整体流量；用基于网关 ARN 的标签让监控随 maxAlbCount 自动扩展；建议对 HealthyHostCount、TargetResponseTime、HTTPCode_Target_5XX_Count 配置告警。
5. 计费口径：ECS Gateway 本身不额外收费，但你仍需为账户内实际置备的底层资源付费，包括 ALB、CloudWatch 日志与指标、ACM 证书和数据传输。具体单价待核实。
6. 区域与前置条件：材料称在所有提供 ECS 的商业区域可用。跨区域、跨账号共享网关这类场景材料没有涉及，不要按“账户级资源”自行外推。

本文没有验证的部分#

本文没有执行任何 CLI 命令或实际部署，示例仅用于说明参数形状。以下几点材料未提供，需要自行核对官方文档后再落到方案里：maxAlbCount 能否提升；多条 listener 规则冲突时的优先级处理；ACM 证书的验证与续期在托管流程中的具体表现；与既有 WAF 规则组的兼容细节；从网关回退到自建负载均衡的完整步骤。

把责任划清之后，ECS Gateway 的价值可以概括成一句：用“网关标准加服务声明”的两层契约，替换“每服务一套网络配置”的重复劳动。代价同样清楚——网关级不可变项必须前置规划，IAM infrastructure role 与账户配额成了新的责任面，而这两项恰好是最容易被“托管”二字掩盖的部分。