容器服务托管入口的职责划分：监听、健康检查与 TLS 终止各归谁

托管入口方案常被描述成“少建几个负载均衡器”的省事工具，但在容器服务里，它真正改变的是三件事的归属：谁定义监听器、谁决定健康检查、谁持有 TLS 证书。这三项一旦划错，自动化省下的时间会以排障时间还回去。

本文以 Amazon ECS Gateway 为例。AWS 于 2026 年 10 月 20 日发布公告介绍该功能（AWS News Blog，来源日期以该公告标注为准）。以下事实均取自该公告正文；本文未在控制台或 CLI 中实际执行任何命令，凡材料未展开之处均标注为待核实，请以官方文档与实测为准。

一、先把职责摊开：一张归属表#

公告把它描述为平台团队与应用团队之间的职责分离：平台团队创建 gateway，集中定义子网、安全组、TLS 证书、监听器设置与 WAF web ACL，并把 gateway 关联到一个或多个 ECS 集群；应用团队只需在服务的创建或更新请求里加一个 gateway connector 参数。两者之间由 ECS 控制面补齐每服务资源。

二、监听：共享的监听器，独占的规则#

理解这套方案的关键，是分清“监听器”与“监听规则”不是一回事。gateway 持有监听器：负载均衡 scheme（公网或 VPC 内网）、监听协议与端口、子网、IP 地址类型都在这一层确定；公告明确列出，name、scheme、VPC、subnets、IP 地址类型、监听协议与端口在 gateway 创建后不可修改。可选配置还包括 gateway 可扩展到的负载均衡器数量上限（maxAlbCount）与 web ACL。

每个服务拿到的是规则，不是监听器。服务通过 connector 接入后，ECS 创建监听规则，按该服务唯一的主机名转发流量——公告称之为基于主机的路由（host-based routing）。所以应用团队从来没有“我的端口”可争，只有一个被分配的主机名。

这条分工带来三个直接后果：

• 端口变更是入口级变更。改监听端口不能靠改配置，只能新建 gateway 再迁移，这是把入口契约提前到平台层的代价。
• 密度有上限。公告写明单个 ALB 最多承载 25 个服务；达到容量后 ECS 再创建新的 ALB，直到 maxAlbCount。该配额默认值为 10，用尽且没有空闲容量时部署失败。
• 成本随服务数非线性变化。公告称首个服务连接时才创建第一个 ALB，无服务使用后移除；也就是说基础设施随连接数伸缩，而不是随 gateway 数量。

三、TLS 终止：证书分两层，边界要看清#

材料中证书出现在两个位置。第一层是平台级：平台团队在配置 gateway 时定义 TLS 证书。第二层是每服务级：服务接入时，ECS 为其签发一张 ACM 证书并分配唯一 DNS 主机名，两者一起构成服务可用的 HTTPS 入口。

需要克制的地方在这里：公告说明了证书由谁配置、由谁签发，但没有明确写出 TLS 在 ALB 上终止，也没有说明 ALB 到任务之间是否加密。合理推断是终止发生在 ALB 的 HTTPS 监听器上，后端按目标组协议转发；但这属于推断，落地前应查官方文档确认后端协议与加密要求。同理，公告只提到“唯一 DNS 主机名”，是否支持自带域名、证书如何校验，材料未说明，待核实。

另一条容易被忽略的边界是安全组：ECS 创建的服务安全组只允许来自 ALB 安全组的入站流量。这意味着后端信任边界由网络层承担，不需要应用再自行校验来源。反过来说，如果服务同时还挂着旧的手工负载均衡器，那份安全组规则并不在这个托管范围内。

四、健康检查：声明在服务侧，执行在目标组#

公告的 create-service 示例里，gateway connector 包含 portName、filters 与 healthCheck 三项，其中 healthCheck 的具体内容以 {...} 省略。可以确认的是：健康检查由应用团队在服务定义中声明，目标组由 ECS 创建，因此检查配置最终落在目标组上，决定 ALB 是否把流量打给某个任务。

路径、间隔、健康与不健康的阈值、匹配状态码这些字段名与默认值，材料均未给出，属于待核实。不要照抄其他地方看到的字段就上线。

可观测性方面，公告给了明确口径：用 CloudWatch 的 ALB 指标，TargetGroup 维度看单服务流量，LoadBalancer 维度看共享 ALB 的整体流量；用 describe-target-health 查实时目标状态；对 HealthyHostCount、TargetResponseTime、HTTPCode_Target_5XX_Count 配置告警，并基于 gateway ARN 打标签，让监控随 maxAlbCount 自动扩展。

五、一次接入的最小顺序#

以下命令摘自公告示例，本次未执行；账户 ID、IAM 角色名、子网 ID 与集群 ARN 均为占位值，请替换为自己的真实资源。

1. 平台团队创建 gateway。此时不创建任何基础设施，要等到有服务通过 connector 接入。
2. 把 gateway 关联到集群，使其对该集群上的服务可用。
3. 应用团队在创建服务时带上 gateway connector。
4. 部署完成后确认 gateway route 状态为 ACTIVE，再用 describe-target-health 核对目标健康。

# 占位示例，未执行
aws ecs create-gateway \
 --name my-team-gateway \
 --infrastructure-role-arn arn:aws:iam::123456789012: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:us-east-1:123456789012:cluster/my-cluster

服务侧示例同样摘自公告，其中 healthCheck 在原文中即以省略形式出现，不能据此推断字段：

# 占位示例，未执行；healthCheck 内容原文省略
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": {...} }]'

六、兼容条件与失败路径#

公告给出的兼容判定是三条同时成立：gateway 的 access type 与服务 connector 的 filter 匹配；gateway 与服务在同一 VPC；gateway 覆盖服务所配置子网使用的全部可用区。部署时 ECS 会把服务连接到所有兼容的 gateway，比如公网与内网各一个。

• 可用区错配是静默失败。gateway 的 ALB 只向它有子网的可用区转发流量。建议同一集群的 gateway 与服务使用相同的可用区集合。
• 容量耗尽会阻断部署。maxAlbCount 达到上限且无空闲容量时，部署失败。应按预期服务数规划该值。
• 关联变更不是实时的。ECS 在每次部署时重新评估 gateway 关联：新关联的兼容 gateway 会接上，被解除的会断开并移除路由。改完关联不重新部署，服务看到的仍是旧状态。
• 网络模式有前提。该功能面向使用 awsvpc 网络模式的 ECS 服务，覆盖 EC2、Fargate 与 ECS Managed Instances 三种启动类型。
• 关联规模有上限。单个 gateway 可关联最多 10,000 个集群，单个集群最多关联 5 个 gateway。

七、迁移顺序：先并存，再摘旧入口#

已有服务自带负载均衡器时，公告给出的路径是增量迁移：调用 UpdateService 添加 gateway connector，两条入口同时可用，验证新入口的 route 为 ACTIVE、健康检查通过、流量指标正常后，再移除旧的负载均衡器配置。这个顺序的价值在于回滚成本低——旧入口还在，出问题直接切回。

服务删除时，ECS 会断开该服务与所有 gateway 的连接、移除路由并清理每服务资源；如果这条路由是该 ALB 上的最后一条，ALB 一并回收。计费上，公告称使用该功能本身不额外收费，只为账户内实际创建的基础设施付费，包括适用的 ALB、CloudWatch 日志与指标、ACM 证书与数据传输费用；具体口径与区域可用性以定价页与官方文档为准。

八、上线前的核对清单#

• 监听协议、端口、scheme、VPC、子网、IP 类型是否已按长期规划确定？这些创建后不可改。
• maxAlbCount 是否覆盖预期服务数除以 25 的结果，并留出余量？
• gateway 与服务的可用区集合是否一致？
• healthCheck 字段是否已对照官方文档确认，而不是照抄示例？
• ALB 到任务之间是否需要加密？材料未说明，需单独确认。
• 是否接受“唯一主机名”这一限制，还是需要自带域名？后者待核实。
• 告警是否已按 TargetGroup 与 LoadBalancer 两个维度分开配置？

回到标题的问题：托管入口并没有让责任消失，只是把责任重新分配。监听器归平台、规则归控制面、证书分两层、健康检查归服务方。把这四句写进团队的接入规范，比记住某个 CLI 参数更有用。