每个服务都送随机域名，ECS网关怎么接自己的域名？

AWS 最近上线了 Amazon ECS Gateway，一个账户级的入口资源。平台团队把网络配置定义一次，应用团队通过一个连接器把服务挂上去。每个服务会拿到一个自动生成的域名，但无论是发布公告还是官方文档，都没有说明怎么在它前面放一个自定义域名。

这个网关被首席开发者布道师 Channy Yun 描述为：一个账户级的新资源，通过代为动态配置和管理必要的基础设施，简化容器化工作负载的入口网络，所有资源都直接创建在你的账户里。

它在 ECS 运行的所有商业区域可用，除了它自己配置出来的资源之外不额外收费。从业者问的第一个问题就是：怎么把自己的域名放到它前面？

它带来的分工是组织层面的。平台团队用基础设施 IAM 角色、子网、安全组、TLS 证书、监听器设置以及可选的 WAF Web ACL 创建一个网关，然后把它关联到集群。应用团队通过 CreateService 或 UpdateService 添加一个网关连接器，ECS 就会为每个服务配置一张 ACM 证书、一个域名、一条监听器规则、一个目标组，以及一个只接受来自负载均衡器流量的安全组。

在 Reddit 上，用户 zurnout 直接冲着域名开火：我不明白这有什么用，你给 ECS 服务拿到的是一个随机域名。我要怎么把流量导过去？ECS Express 也是一样的问题。

被问到 CNAME 能不能解决时，他解释了为什么不行：它会在负载均衡器里创建基于主机的规则，所以如果你用 CNAME，它根本不知道该往哪路由。用户 ResponsibleWaltz1479 得出了同样的结论，称这个功能对“应用不感知主机名的临时/预览环境”可用，但不适用于他们现有的架构。

文档支持这种解读。每个服务“会得到一个形如 https:// .ecs. .on.aws 的生成域名”，并且“Amazon ECS 使用基于主机的路由，把请求从共享的 Application Load Balancer 转发到对应的服务”。自定义域名、Route 53、CNAME 记录都没有被提及。用户 Kralizek82 提出了一个没人解答的变通办法：网关能不能当作 CloudFront 的内部源站？

对这个服务是否算得上实质改进，意见是分裂的。用户 bioJesusMain 说它“就是 ALB 和 DNS 套了个壳”，aneryx 认为“它甚至可以只是架在 ALB/NLB 和 Route 53 之上的一个 CDK 构造”。brokenlabrum 则从经验出发回应：那些更高层的 L3 构造往往被证明是个错误，因为它们需要把所包装的 L2 构造的每一个旋钮都暴露出来。而如果它们有主见、不暴露，想从一个 L3 构造里脱身而不让它删掉你的资源，那简直是地狱。

用户 Aggressive-Height167 为它说了话，指出让云团队把网络定义一次、应用团队照着部署，“看起来是个相当扎实的改进”。他补充说，真正的考验是“它是否真的在移除复杂性的同时，没有拿走太多控制权”。

文档还补了一个公告没提的成本细节。网关会在现有负载均衡器填满时新增，只在它们清空时移除，但它“不合并负载均衡器”，也“不在负载均衡器之间移动服务，所以服务离开后可能留下好几个半满的负载均衡器”。每一个都要计费。

用户 jregovic 指出，超过 25 个服务就意味着不止一个负载均衡器。一位 AWS 方面的回应者答复说，“多个 ALB 由网关自己处理——所以这不是你需要操心的事”。网关确实会处理它们，但它不会把它们打包。

ECS 也“不会修复在它之外所做的更改”。修改或删除一个受管资源，流量“可能会中断”，后续的部署、网关更新和清理操作都可能失败。

边界很具体。25 个服务共享一个负载均衡器，而默认的 maxAlbCount 是 10，文档记载的每个网关上限是 200。AWS 警告说，“如果达到 maxAlbCount 且没有 ALB 还有可用容量，部署就会失败”。监听器只在 443 端口提供 HTTPS；服务必须使用同一 VPC 和同一账户内的 awsvpc 网络，Express 模式的服务被排除在外。

这个帖子里得票最高的评论把这次发布斥为“一个推广项目”，还有几位评论者问为什么 AWS Elastic Beanstalk 没有覆盖这块地盘，其中一位提到了它上个月的 Cluster Mode 发布。用户 dmcnaughton1 给出了另一面：他手上正在进行的 ECS 迁移开始得够早，可以采纳它。