ECS 全托管入口网关的责任边界：平台管基线，应用管接入，ECS 管生命周期

ECS Gateway 的“全托管”容易让人以为平台团队可以把入站网络整体交出去。更准确的责任边界是：平台团队定义并关联网关基线，应用团队通过 gateway connector 声明接入意图，ECS 控制面负责每服务资源和生命周期；资源仍创建在账户内，IAM、容量、AZ 兼容、监控和费用责任没有转移。据 AWS 新闻博客 2026 年 10 月 20 日的发布文章，ECS Gateway 是账户级资源，会代表你动态创建和管理入口基础设施，但所有资源直接落在你的账户中。

三条责任线：基线、接入、生命周期#

把责任拆开看，平台团队、应用团队和 ECS 各自负责的内容并不重叠：

这里有两层证书和安全组容易混在一起：平台团队定义的是网关监听器与 TLS 基线，以及网关侧安全组；服务接入后，ECS 还会为该服务创建 ACM 证书、唯一主机名，以及只允许来自 ALB 入站的服务安全组。前者是组织基线，后者是每服务产物，不能当成同一层配置。

平台侧：先定不可变项，再谈自动化#

平台团队用 CreateGateway 提供账户内唯一的网关名、基础设施角色 ARN 和配置对象。基础设施角色由 ECS 代入，用来在账户内创建和管理 ALB、安全组、证书等资源；因此角色信任关系和权限范围是平台侧的安全边界。该文示例做了简化，下面账号、ARN 和子网均为占位，未执行：

aws ecs create-gateway \
  --name my-team-gateway \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole \
  --configuration '{"HostSharedAlb":{"networkConfiguration":{"subnets":["subnet-xxxxxxxx"],"ipAddressType":"ipv4"},"scheme":"internet-facing"}}'

素材明确列出，网关名称、public 或 VPC-internal 方案、VPC、子网、IP 地址类型、监听器协议和端口在创建后不能修改。由此可以推断，VPC 或子网选错通常要新建网关并重新调整集群关联；具体迁移步骤应以文档为准。WAF、最大 ALB 数等设置在创建时可配置，但素材没有给出完整的“可后改”清单，其他项待核实。

应用侧：connector 是声明，不是绕过兼容条件#

应用团队在 CreateService 或 UpdateService 中加入 gateway connector，服务就会在部署时被接入网关。该文给出的兼容条件有三条：网关访问类型匹配 connector 的过滤条件；网关与服务在同一 VPC；网关覆盖服务配置子网使用的所有 AZ。部署时 ECS 会连接服务到每一个兼容网关，而不是只挑一个。下面的参数片段来自该文示例思路，省略了健康检查等字段，不是完整可执行命令，也未执行：

--gateway-connectors '[{"portName":"api","filters":{"accessTypes":["PUBLIC"]}}]'

这解释了一个常见边界：应用团队不必逐项配置 ALB、证书和监听规则，但仍要对“服务能否被接入”负责。端口名如何对应任务定义、健康检查字段是否必填，需按文档核对，本次素材没有展开。一个网关最多关联 10,000 个集群，一个集群最多关联 5 个网关；如果同一集群同时关联公网和内网网关，服务可能按兼容性获得多个入口。

已有 ALB 的服务可以增量迁移：保留原入口，通过 UpdateService 添加 gateway connector，验证新入口后再移除旧负载均衡配置。该文明确两条入口可以并存。建议把旧入口保留到 DNS、健康检查和错误率验证完成，这是迁移建议，不是来源承诺。

运行期：自动化覆盖生命周期，但不覆盖容量规划#

每次部署，ECS 会重新评估集群关联的网关：上次部署后新关联的兼容网关会连上，已解除关联的网关会断开并删除路由。服务删除时，ECS 会断开所有网关、删除路由并清理每服务资源；如果该服务是某个 ALB 上的最后一条路由，该 ALB 会被回收。这些是 ECS 负责的生命周期部分。

容量和网络覆盖仍由账户侧负责。该文说单个 ALB 最多可让 25 个服务共享，maxAlbCount 默认配额为 10；如果达到上限且没有可用 ALB 容量，部署会失败，而不是自动超限扩容。服务使用的 AZ 必须是网关 AZ 的子集，ALB 只向有子网的 AZ 路由；建议同一集群的网关和服务使用相同 AZ 集合。网络模式方面，素材只说明支持 awsvpc，覆盖 EC2、Fargate 和 ECS Managed Instances 启动类型，其他网络模式未说明，待核实。

可观测性与费用：共享入口仍要按服务看#

共享 ALB 后，不能只看一个总入口。该文建议用 CloudWatch 的 ALB 指标，以 TargetGroup 维度看单服务流量，以 LoadBalancer 维度看共享 ALB 的整体流量；用 describe-target-health 查看实时目标健康状态。告警可围绕 HealthyHostCount、TargetResponseTime、HTTPCode_Target_5XX_Count 等指标设置，并利用 gateway ARN 标签让监控随 ALB 数量扩展。这是该文的建议，具体阈值要按业务基线定。

费用边界也值得单独说明。据该文，ECS Gateway 本身不额外收费，账户只为服务连接后置备的底层基础设施付费，包括适用的 ALB、CloudWatch 日志与指标、ACM 证书及数据传输费用；发布时在所有 ECS 可用的商业区域提供。价格和区域清单可能变化，具体以定价页和文档为准，待核实。

落地前先核对这几项#

• 先评审不可变项：VPC、子网、AZ 集合、public 或 VPC-internal 方案、监听器协议和端口；这些选错后不能靠改网关修正。
• 明确谁可以创建网关、谁可以关联集群，以及基础设施 IAM 角色的权限范围；建议按最小权限治理。
• 应用接入前核对同 VPC、AZ 子集、端口名和访问类型；不要假设加了 connector 就一定连上。
• 迁移时保留旧 ALB 入口，直到新入口验证完成；这是该文支持的增量路径。
• 按单 ALB 最多 25 个服务和 maxAlbCount 规划容量；到顶后的结果是部署失败。
• 监控同时看 TargetGroup 和 LoadBalancer 两个维度；服务安全组是否允许人工修改及漂移行为，本次素材未说明，待核实。

一句话划界：平台团队定共享网络基线，应用团队报接入意图，ECS 做每服务资源和生命周期；账户仍拥有资源、IAM、容量、监控和费用责任。