容器服务入口怎么分工：托管入口、负载均衡与 Ingress 控制器的取舍

先说结论：托管入口、负载均衡器和 Ingress 控制器不是同一层的替代选项。负载均衡器承接真实流量；Ingress 控制器把路由声明翻译成负载均衡器配置；托管入口再把“为每个服务创建并同步负载均衡器、证书、WAF 和安全组”这件事收归平台层。选型的实质是回答两个问题：配置权放在哪一层，资源生命周期由谁维护。

下面以 Amazon ECS Gateway 为例，说明托管入口具体接管了什么、边界在哪。关于 Ingress 控制器的部分只做概念对照——本次材料是 AWS 于 2026 年 10 月 20 日发布的 ECS Gateway 公告，未提供具体 Ingress 控制器实现的细节，涉及该类产品的比较结论待核实。

三层各自承担什么#

传统自建路径通常是：平台团队部署 Ingress 控制器或提供一套服务模板，应用团队仍然要自己申请证书、写负载均衡器注解、维护安全组规则。这条路径的控制力最强，但每个新服务都会重复一遍申请与同步动作。托管入口把这段工作前移到平台层，应用侧只保留一个接入声明。

ECS Gateway 具体接管了什么#

据 AWS 官方发布说明，ECS Gateway 是一个账户级资源，由 ECS 在用户账户内动态预置并管理入口所需的基础设施。它把职责切成两半：平台团队创建网关，在一个地方定义子网、安全组、TLS 证书、监听器设置和 WAF web ACL，再把网关关联到一个或多个 ECS 集群；应用团队在创建或更新服务时加上 gateway connector 参数即完成接入。

接入之后，ECS 自动创建每个服务所需的资源：一张 ACM 证书、一个唯一 DNS 主机名、一条把该主机名流量导向服务目标组的监听器规则、一个目标组，以及一个只允许来自 ALB 入站流量的服务安全组。路由方式是基于主机名，并允许最多 25 个服务共享同一个 ALB。

底层基础设施的生命周期也由 ECS 管理：第一个服务接入时创建第一个 ALB，容量用满时继续增加，不再需要时删除。与手工维护相比，这一层减少的是“配置漂移”这类问题——资源不再由每个服务的流水线各自创建，而是由同一份网关配置推导出来。

兼容性判定与可用区

部署时，ECS 会评估集群关联的所有网关，把服务连接到每一个兼容的网关。兼容需要同时满足三个条件：网关的访问类型匹配服务 connector 里的 filter；网关与服务处于同一 VPC；网关覆盖服务所配置子网使用的全部可用区。

可用区这一条容易被忽略。服务使用的可用区必须是网关上可用区的子集，ALB 只会把流量路由到它有子网的可用区里的任务。官方建议对同一集群的网关和服务使用相同的可用区集合，否则会出现“部署成功但部分任务收不到流量”的情况。此外，该功能要求服务使用 awsvpc 网络模式，覆盖 EC2、Fargate 和 ECS Managed Instances 三种启动类型。

容量与不可变配置

两个数字需要提前规划。其一，maxAlbCount 的默认配额是 10；当达到上限且没有 ALB 还有余量时，部署会直接失败，所以这个值应当按预期接入的服务数量来设置。其二，网关与集群是多对多关系：一个网关最多可关联 10,000 个集群，一个集群最多支持 5 个网关关联，这让“公有网关 + 私有网关”这类组合成为可能。

还有一组配置在网关创建后无法修改：名称、scheme、VPC、子网、IP 地址类型、监听器协议与端口。也就是说，网络边界必须在创建前定好，后续调整只能新建网关。

迁移、回滚与清理#

已经在用自有负载均衡器的 ECS 服务，可以通过 UpdateService 加上 gateway connector 做增量迁移。此时两条入口路径同时存在，可以先验证网关链路，再移除旧的负载均衡器配置——这是整个方案里风险最低的一段路径。

每次重新部署时，ECS 都会重新评估集群的网关关联：新增了兼容网关就连接，网关被解除关联就断开并移除路由。服务被删除时，ECS 会自动断开所有网关、删除路由并清理每服务资源；如果该服务持有某个 ALB 上的最后一条路由，这个 ALB 也会被一并回收。

成本与可观测性#

ECS Gateway 本身不额外收费，可用区域为 ECS 已开放的所有商业区域；费用来自实际被创建的底层资源，包括 ALB、CloudWatch 日志与指标、ACM 证书和数据传输。

观测上要区分两个维度：用 TargetGroup 维度看单个服务的流量，用 LoadBalancer 维度看共享 ALB 的整体负载；目标健康状态可用 describe-target-health 实时查询。官方建议对 HealthyHostCount、TargetResponseTime、HTTPCode_Target_5XX_Count 等指标配置告警，并利用基于网关 ARN 的标签，让监控随 maxAlbCount 扩展而自动覆盖。

什么时候仍然该自建#

托管入口不是默认答案。以下判断依据供参考，属于建议而非材料结论：

• 需要 ALB 主机路由之外的能力。本次材料只描述了基于主机名的 ALB 路由；如果业务依赖路径级路由、非 HTTP 协议或其他类型的负载均衡器，是否在支持范围内需要另行核实。
• 需要自己控制控制器的升级节奏与规则生成逻辑，例如路由规则由内部平台按自定义策略下发。
• 已有成熟的多集群抽象和 GitOps 流水线。再引入一层托管资源，会多出一套需要对齐的事实来源。

最小命令示例#

以下命令结构参照官方示例改写，账号、角色、子网、集群名均为占位值，本次未执行，输出不作预期。healthCheck 的参数结构在本次材料中未完整给出，故省略。

aws ecs create-gateway \
  --name YOUR_GATEWAY_NAME \
  --infrastructure-role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/YOUR_INFRA_ROLE \
  --configuration '{
    "HostSharedAlb": {
      "networkConfiguration": {
        "subnets": ["subnet-EXAMPLE1", "subnet-EXAMPLE2"],
        "ipAddressType": "ipv4"
      },
      "scheme": "internet-facing"
    }
  }'

aws ecs associate-gateway-with-cluster \
  --gateway YOUR_GATEWAY_NAME \
  --cluster arn:aws:ecs:REGION:YOUR_ACCOUNT_ID:cluster/YOUR_CLUSTER

aws ecs create-service \
  --cluster YOUR_CLUSTER \
  --service YOUR_SERVICE \
  --task-definition YOUR_TASK_DEF \
  --gateway-connectors '[{
    "portName": "api",
    "filters": {"accessTypes": ["PUBLIC"]}
  }]'

回到取舍本身：托管入口买到的是“平台团队定义一次、应用团队声明一次”的一致性，付出的是对兼容条件、配额和不可变配置的让渡。Ingress 控制器买到的是控制力，付出的是自己维护控制面与规则同步的责任。把这两者的责任边界写清楚，比比较功能清单更能决定长期运维成本。