Amazon ECS Gateway Shares Ingress Plumbing, but Teams Still Own the Boundaries

For a small ECS service, creating a load balancer and certificate is routine. For a platform with dozens of services, repeating that setup creates a second job: keep every ingress path, security group and listener aligned as teams deploy. AWS’s new ECS Gateway tries to centralize that plumbing while leaving application teams a simple connector to opt in.

A shared platform door for ECS services

AWS announced ECS Gateway on October 20 as an account-level resource. A platform team configures networking standards—subnets, security groups, TLS certificates, listener settings and optional WAF rules—and associates the gateway with one or more clusters. An application team then adds a gateway connector to an ECS service. ECS provisions the service-specific certificate, hostname, listener rule, target group and security group. AWS says up to 25 services can share one ALB. ^[1]

The separation matters: platform owners define which gateways a cluster may use, while service teams opt in through their service definition. AWS describes many-to-many associations: one gateway can be available to multiple clusters, and a cluster can be associated with multiple gateways, for example separate public and private ingress. The official guide and CloudFormation reference document the gateway object, including its shared ALB configuration, and the service connector model. ^{[2] [3]}

The gateway does not route arbitrary containers in any network mode. AWS says services must use awsvpc, and the feature is available across ECS on EC2, Fargate and ECS Managed Instances. The service and gateway need compatible VPC and Availability Zone coverage. A service that spans an AZ not covered by the gateway may not receive the expected route. ^{[1] [2]}

What it automates—and what it does not

A connector automates the creation and lifecycle of several AWS resources. On deployment, ECS checks compatible gateway associations and connects the service; when a service is deleted, it removes routes and per-service resources. Existing services can be adopted by adding a connector while retaining their current load balancer during validation. That gives teams a migration path in which they can confirm the new route before removing the old one. ^[1]

The platform still owns the underlying design. It must create an infrastructure role that ECS can assume, scope IAM permissions, choose subnets and decide which clusters can attach. Operators also own DNS dependencies, health checks, access policy, alerting and application-level behavior. AWS specifically recommends observing target health and ALB metrics such as healthy host count, response time and server errors. ^[1]

Capacity deserves a deployment guard. AWS says the default maxAlbCount quota is 10; the gateway’s shared ALB configuration exposes this maximum as a setting. If the configured limit is reached and no ALB has room, a service deployment can fail. A theoretical “25 services per ALB” is not a promise that every gateway configuration will carry the same number at every traffic level; teams need to size for their own service and routing patterns and check current quotas for their account and Region. ^{[1] [3]}

The cost is managed, not erased

AWS says ECS Gateway carries no additional charge as a service. The ALBs, CloudWatch logs and metrics, certificates and data transfer provisioned for connected services remain billable. Sharing ingress can reduce duplicated configuration and may improve infrastructure utilization, but savings depend on existing architecture and traffic. Compare a gateway’s actual resources with the load balancers it replaces; “no gateway fee” is not the same as “free ingress.” ^[1]

Some configuration choices are fixed after gateway creation, including the name, scheme, VPC, subnets, IP address type and listener protocol and port. That makes a disposable environment useful before a production rollout. Validate the public or VPC-internal scheme, subnet/AZ set, listener and security policy early; do not assume these are all mutable fields in a routine redeploy. ^[1]

A measured adoption path

Start with one low-risk service and a gateway in the same VPC and Availability Zone footprint. Confirm that the connector points to the intended named service port, the health check matches the application, and the generated host resolves through the expected path. Compare target health and 5xx metrics before shifting traffic or deleting the old ingress resources. Then test the failure case: a capacity limit, a health-check rejection and a gateway disassociation.

For a larger platform, decide whether gateways represent ownership boundaries, environment boundaries or traffic classes. An internal-only gateway and a public gateway may need different Web ACL, TLS and access policies. Bind those choices to IAM permissions that control who can deploy against which cluster. The feature can simplify repetitive cloud plumbing, but a shared ingress plane also makes platform governance more important.

ECS Gateway is a useful option for teams already standardizing on ECS who want a managed way to reuse ingress infrastructure. It should be evaluated as an account-controlled ALB lifecycle and service attachment system. It is not a generic API gateway and does not replace application authorization, traffic policy design or capacity planning. For alternatives and neighboring patterns, see how teams build custom API gateways and AWS Lambda Web Functions.