把 ECS 入口交给账户级网关前，先划清它与负载均衡的职责

如果只用一句话回答标题里的问题：ECS Gateway 管的是“入口该怎么被创建、被什么策略约束”，负载均衡管的是“流量怎么被转发”。两者不在同一层，不构成替代关系。把 ECS 入口交给账户级网关之前，需要先把组织策略、服务声明和流量执行这三件事拆开，否则托管只是把配置漂移从单个服务搬到了账户层。

以下事实来自 AWS 关于 Amazon ECS Gateway 的发布说明（AWS News Blog）。文中标注为推断的部分，是据此做出的判断，不是原文结论。

一、先确认它不是“另一种负载均衡”#

按 AWS 的描述，ECS Gateway 是一个账户级资源，作用是为容器化工作负载简化入口网络：它动态供给并管理所需基础设施，且所有资源直接创建在你的账户内。这句话有两个含义值得停下来看：第一，它是管理层，不是转发层；第二，资源仍然在你的账户里，成本与配额的责任没有转移出去。

真正的转发仍由 Application Load Balancer（ALB，应用负载均衡器）完成。ECS Gateway 使用 ALB 做基于主机名的路由，并让最多 25 个服务共享一个 ALB。当容量达到上限时，ECS 会新增 ALB；不再需要时移除。也就是说，ALB 从“每个服务手工创建的对象”变成了“由平台策略驱动的池”，但它依然是数据面。

二、三层职责：策略、声明、执行#

把职责划清楚，最有效的方式不是列功能，而是问“这个决定由谁做、变更节奏是什么”。

这张表里最容易被忽略的是最后一行。入口被托管之后，服务本身仍然要声明“我从哪个端口提供服务、健康检查打哪里”。这部分没有随网关一起被抽象掉，交接时应当明确写进服务模板，而不是留在口头约定里。

三、一个服务从声明到有流量#

发布说明给出的路径大致是这样：

1. 平台团队创建网关。需要提供网关名称，并选择一个基础设施角色（infrastructure role）。这是一个 IAM 角色，ECS 会代入它，在你的账户里创建和管理 ALB、安全组、证书等网络资源。
2. 平台团队配置标准。子网、安全组、TLS 证书、监听器设置、WAF web ACL 都在网关这一处定义，然后把网关关联到一个或多个 ECS 集群。
3. 应用团队选择加入。在创建或更新服务时添加 gateway connector 参数。按原文说法，这一步不需要网络专业知识。
4. ECS 供给每服务资源。ACM 证书、唯一 DNS 主机名、监听器规则、目标组，以及只允许来自 ALB 入站的服务安全组。
5. ECS 管理池的生命周期。第一个服务接入时创建第一个 ALB，容量到顶时增加，空闲时回收。

把这条链路和自管 ALB 对照，差异在“谁拥有变更”：

四、职责不清时，问题会先出现在哪#

以下是基于上述职责划分的推断，不是 AWS 的表述，也不代表已在实际环境中验证：

• 证书归属。平台团队在网关定义 TLS，ECS 又为每服务生成 ACM 证书。若团队仍按旧习惯自签或自传证书，会出现同一主机名两套证书来源，排查时难以判断哪一套生效。
• 安全组双向不一致。服务侧入站被限制为“仅来自 ALB”，但出站、以及服务间互访是否仍由平台安全组覆盖，需要在接入前写清楚，否则应用团队会以为“网络不用管了”。
• 共享 ALB 的容量预期。25 个服务共享一个 ALB 是材料明确给出的数字。容量到顶后新增 ALB 属于托管行为，平台团队需要知道这会在账户里出现新资源，而不是静默扩容。
• 删除与回收。网关或服务下线时，自动创建的监听器规则、目标组、证书如何回收，材料只说明 ALB 会在不再需要时移除，其余细节待核实。

五、接入前的检查清单#

1. 确认基础设施角色的权限边界：它能在账户内创建 ALB、安全组、证书，这个范围是否与你的最小权限要求一致。
2. 把子网、安全组、证书、监听器、WAF 标准落到网关配置里，并作为唯一来源，禁止应用侧重复定义。
3. 明确服务模板必须填写的内容：容器端口、健康检查、是否需要对外主机名。
4. 约定 ALB 池增长的观察方式：谁看账户内新增的 ALB，配额与成本由谁核算。
5. 写下回退路径：服务从 connector 摘除后，DNS 与证书如何变化，上游调用方如何切换。
6. 对未在材料中说明的能力（内部入口、跨账户、非 HTTP 协议）逐项查官方文档，不要按“应该支持”推进。

下面是一段职责对照的示意，不是可执行配置，字段名仅用于表达归属，实际参数以官方文档为准，本文未运行任何代码：

# 示意，未执行；参数名以官方文档为准
gateway:                      # 平台团队维护
  infrastructureRole: <iam-role>
  subnets: [...]
  securityGroups: [...]
  certificate: ...
  listener: ...
  wafWebAcl: ...
  clusters: [cluster-a, cluster-b]

service:                      # 应用团队维护
  gatewayConnector: <gateway> # 材料仅称 "gateway connector parameter"
  containerPort: ...
  healthCheck: ...

六、边界与待核实#

发布说明没有覆盖、因此不应替它补全的部分包括：是否支持内部或私有入口、是否支持跨账户或跨 VPC、是否只服务 HTTP/HTTPS、IPv6 支持情况、每账户的网关与 ALB 配额、计费方式、WAF 规则更新如何传播到已生成的监听器，以及删除网关时对在跑服务的影响。这些都需要以官方文档为准，本文不作推断性结论。

结论可以收得很窄：把 ECS 入口交给账户级网关，换来的不是“不用管网络”，而是把网络标准的决策点从 N 个服务收敛到 1 个网关，同时把每个服务的暴露声明留给应用团队。交接之前，把策略、声明、执行三层的归属写下来，比先跑通一个服务更重要。