By AWS shipped Amazon ECS Gateway last month, and container infrastructure teams finally have an official answer to one of ECS’s most persistent complaints: why is ALB management still a manual slog? The feature is genuinely useful. It also has enough sharp edges that adopting it blindly in production is a mistake. Here is the honest breakdown.
What ECS Gateway Actually Does
ECS Gateway automates the provisioning and lifecycle management of Application Load Balancers for ECS services. The model splits responsibility cleanly: platform teams create and configure a gateway once, defining networking (internet-facing vs. VPC-internal), security (WAF ACLs, security groups), and operational settings. Application teams then attach services using a gateway connector — a parameter on CreateService or UpdateService that names the container port to expose.
When a service connects, ECS automatically provisions the underlying ALB infrastructure shared across services, plus per-service resources: an ACM certificate, a unique HTTPS hostname, a listener rule, a target group, and a security group. No infrastructure is provisioned until the first service connects. Up to 25 ECS services share one ALB, with ECS spinning up additional ALBs as capacity fills.
Each connected service gets a generated HTTPS URL in the form https://<unique-id>.ecs.<region>.on.aws. Available across all commercial regions on EC2, Fargate, and ECS Managed Instances. No additional charge beyond underlying ALB, ACM, and CloudWatch costs. For teams running a dozen microservices that each had their own dedicated ALB, the cost reduction is real.
The No-Custom-Domain Problem
Here is the limitation AWS buries in its documentation: there is no custom domain support. Services get generated on.aws hostnames, full stop. More critically, a CNAME will not solve it — ECS Gateway uses host-based routing on the shared ALB, so routing decisions are made on the incoming Host header. A CNAME pointing api.yourco.com at the gateway hostname means the ALB sees api.yourco.com in the header, not the generated hostname it has a listener rule for. Traffic does not route.
What this means in practice: ECS Gateway is not yet suitable for most public-facing production workloads. Internal services, dev and staging environments, preview deployments, and tools behind a corporate VPN are fine. Anything that needs a branded URL or public DNS is not. The InfoQ analysis noted that AWS documentation provides no guidance on custom domain routing whatsoever — the omission is deliberate, not an oversight.
The Security Trap Nobody Warned You About
This one is actively burning teams. By default, a service without an explicit accessTypes filter in its gateway connector automatically attaches to every compatible gateway associated with its cluster. “Compatible” means same VPC, matching AZs, and matching access type filter.
The trap: a platform engineer adds a new internet-facing gateway to a cluster. Every existing service that did not explicitly specify PRIVATE becomes publicly reachable on its next deployment — no warning, no confirmation prompt. An analysis of adoption traps puts this at the top of the list: always explicitly set accessTypes on every connector, and treat gateway-cluster association as a security-reviewed infrastructure operation.
"gatewayConnector": {
"portName": "web",
"accessTypes": ["PRIVATE"],
"healthCheck": {
"path": "/health",
"interval": 30,
"timeout": 5
}
}What You Cannot Change After Creation
Several gateway settings are immutable once created: name, scheme (internet-facing vs. internal), subnets, listener port and protocol, and IP address type. Wrong scheme at creation means creating a new gateway and migrating services. There is no in-place fix.
The update-gateway command compounds this. It does not patch — it replaces. Send a single parameter update and you silently wipe your WAF web ACL, access logging configuration, test traffic headers, and deletion protection. The correct pattern: retrieve current configuration first, update the full object, then send the complete payload. The DevOps engineering breakdown includes the full workflow for safe updates. Also worth noting: ECS does not consolidate ALBs when services disconnect. Partially-filled ALBs remain and keep billing until manually cleaned up.
ECS Gateway vs. ECS Service Connect
These solve different problems and are not competing features. ECS Gateway handles external ingress: routing traffic from the internet or VPC into your services (north-south traffic). ECS Service Connect handles inter-service discovery: letting Service A call Service B by name instead of IP (east-west traffic). Most production ECS architectures will use both.
Who Should Adopt Now
ECS Gateway earns its place for specific use cases: teams running many small internal microservices drowning in ALB costs, dev and staging environments where generated URLs are acceptable, and greenfield services built entirely around VPC-internal traffic. The platform/app team ownership split is a genuine improvement over manually threaded Terraform modules.
For everyone else — anything public-facing, anything requiring custom domains, path-based routing, mTLS, or NLB — wait. The official AWS documentation lists several other current constraints: no Express Mode support, single-account only, no path-based routing. Terraform support was still pending at launch, which blocks most enterprise adoption anyway.
ECS Gateway is a step in the right direction. It is not the ALB management solution ECS teams have been waiting for. That would require custom domain routing, which AWS has not committed to a timeline for.
