Amazon ECS Gateway Arrives with Generated Hostnames and No Custom Domain Support

The gateway is described by principal developer advocate Channy Yun as:

a new account-level resource that simplifies ingress networking for containerized workloads by dynamically provisioning and managing the necessary infrastructure on your behalf, with all resources created directly in your account.

It is available in all commercial regions where ECS runs, at no additional charge beyond the resources it provisions. The first question practitioners asked was how to put their own domain in front of it.

The split it introduces is organizational. Platform teams create a gateway with an infrastructure IAM role, subnets, security groups, TLS certificates, listener settings, and optional WAF web ACLs, then associate it with clusters. Application teams add a gateway connector through CreateService or UpdateService, and ECS provisions per service an ACM certificate, a hostname, a listener rule, a target group, and a security group accepting traffic only from the load balancer.

Amazon ECS Gateway architecture. (Source: AWS News Blog post )

On Reddit, commenter zurnout went straight at the hostname:

I don’t get how this is useful at all since you get a random domain name for your ecs service. How am I going to direct traffic to that? It’s the same thing with ECS Express.

Asked whether a CNAME would solve it, he explained why it would not:

It creates host-based rules in the load balancer, so it wouldn’t know where to route if you used a CNAME.

Commenter ResponsibleWaltz1479 reached the same conclusion, calling the feature usable "for ephemeral /preview environments if the app is not hostname aware," but not for their existing setup.

The documentation supports the reading. Each service "gets a generated hostname in the form https://<unique-id>.ecs.<region>.on.aws," and "Amazon ECS uses host-based routing to direct requests from a shared Application Load Balancer to the appropriate service." Custom domain names, Route 53, and CNAME records go unmentioned. Commenter Kralizek82 raised the one workaround nobody resolved, asking whether a gateway could serve as an internal CloudFront origin.

Opinion split on whether the service is substantial. Commenter bioJesusMain called it:

It could even just be a CDK construct on top of ALB/NLB and Route 53

Commenter brokenlabrum answered that from experience:

Those higher level L3 constructs have often turned out to be a mistake because they need to expose every knob on the L2 constructs they wrap. And if they’re opinionated and don’t, ejecting from an L3 construct without it deleting your resources is hell.

Commenter Aggressive-Height167 put the case for it, noting that letting a cloud team define networking once while application teams deploy against it "seems like a pretty solid improvement." The test, they added, "is whether it actually removes complexity without taking away too much control."

The documentation adds a cost detail the announcement leaves out. A gateway adds load balancers as existing ones fill and removes them only when they empty, but it "does not consolidate load balancers" and "does not move services between load balancers, so several partly filled load balancers can remain after services leave." Each one is billed.

Commenter jregovic noted that more than 25 services means more than one load balancer. An AWS respondent answered that "multiple ALBs are handled by the gateway itself - so it’s not something that you need to worry about." The gateway does handle them. It does not pack them.

ECS also "does not repair changes made outside it." Modify or delete a managed resource and traffic "can stop," with later deployments, gateway updates, and cleanup operations liable to fail.

The envelope is specific. Twenty-five services share one load balancer, against a default maxAlbCount of 10 and a documented ceiling of 200 per gateway. AWS warns that "if maxAlbCount is reached and no ALB has available capacity, the deployment fails." Listeners serve HTTPS on port 443 only; services must use awsvpc networking in the same VPC and account, and Express Mode services are excluded.

The thread’s most upvoted comment dismissed the launch as "a promotion project," and several commenters asked why AWS Elastic Beanstalk did not already cover the ground, one pointing at its Cluster Mode release last month. Commenter dmcnaughton1 offered the other side, saying a current ECS migration was early enough to adopt it.

December 15–16, 2026. Examine how senior practitioners run agents, evals, model serving, and AI-assisted engineering in production, including what failed and what changed. Register Now.