Amazon ECS Gateway automates service ingress and removes per-service provisioning

October 20, 2026. AWS announces Amazon ECS Gateway, an account-level resource that provisions and manages the ingress networking of Amazon ECS services for you. One ALB for twenty-five services. The same resource shares an Application Load Balancer across up to 25 services and hands each one a unique DNS hostname, ready to use the moment provisioning completes. Why it matters: ingress wiring — load balancer, certificate, WAF, security groups — was, until now, the bottleneck every new service replayed identically, and it just disappeared.

The problem ECS Gateway solves

On ECS, running a container became easy. Putting it online, less so. For every new service, a team had to provision and wire an Application Load Balancer, an AWS Certificate Manager certificate, an AWS WAF web ACL and security groups, then keep those resources in sync as the service evolved. Multiplied across dozens of services, that repetitive work slows deployment velocity and raises the risk of configuration drift — two services that should be identical end up diverging.

ECS Gateway attacks the root cause by separating responsibilities. The platform team creates the gateway and sets the networking standard once: subnets, security groups, TLS certificates, listener settings and WAF web ACLs. It then associates the gateway with one or more ECS clusters. The application team opts a service in by adding a single connector parameter when creating or updating it — no networking expertise required.

What the gateway does for you

The moment a service connects, ECS provisions the per-service resources automatically: an ACM certificate, a unique DNS hostname, listener rules, target groups and a service security group that only allows inbound traffic from the ALB.

Host-based routing on the ALB is the core mechanism: one ALB carries several services, each on its own hostname. ECS then manages the full lifecycle of the underlying infrastructure — it provisions the first ALB when the first service connects, adds more ALBs as capacity fills, and removes them when they are no longer needed.

The relationship is many-to-many: a gateway can be associated with up to 10,000 clusters, and a single cluster supports up to five gateway associations. A platform team can share one gateway across environments, or assign several gateways — public and private — to the same cluster.

Before and after, in one table

The change is easiest to measure by comparing what a team did by hand with what the gateway takes over.

The “end of life” row is usually the most neglected — and it is where configuration drift is born, when orphaned resources linger because no one remembered to remove them. The gateway closes that gap by construction.

The security and IAM model

The gateway relies on an infrastructure IAM role that ECS assumes to create ALBs, security groups and certificates in your account. That is the central control point: the platform grants the role the strict minimum to provision networking, and nothing more.

Access control then works at two levels. First, which gateways are associated with which clusters — a platform team decides who can deploy into which environment. Second, restrictive IAM policies limit who can create or connect services on a given cluster. The result: the application team never needs the broad networking rights the manual approach demanded, and the error surface shrinks accordingly.

In practice

Creation works in the console or via the CLI. You first create the gateway with an infrastructure IAM role that ECS assumes to provision ALBs, security groups and certificates in your account.

aws ecs create-gateway \
  --name my-team-gateway \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole \
  --configuration '{
    "HostSharedAlb": {
      "networkConfiguration": {
        "subnets": ["subnet-080779f9bd887757a", "subnet-03d5b2fead6bc6258"],
        "ipAddressType": "ipv4"
      },
      "scheme": "internet-facing"
    }
  }'

No infrastructure is provisioned until a service actually connects. The cluster association comes next:

aws ecs associate-gateway-with-cluster \
  --gateway my-team-gateway \
  --cluster arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster

Adoption is opt-in and requires no migration: an existing service keeps running on its current ALB until you add a gateway connector. You can therefore switch a cluster over service by service, with no downtime window, and compare the gateway against your current setup before rolling it out broadly. To drive all of this from code, the gateway exposes its APIs and is documented through the AWS MCP Server and its plugins.

What to watch for

A few guardrails prevent surprises at deploy time.

• Networking. The gateway applies to services using the awsvpc network mode, across ECS EC2, Fargate and ECS Managed Instances. Your service’s Availability Zones must be a subset of the gateway’s AZs — the ALB only routes to tasks in AZs where it has subnets.
• Capacity. If maxAlbCount is reached and no ALB has room, the deployment fails. The default quota is 10 ALBs per gateway: size it against the number of services you expect to connect.
• Observability. Track per-service traffic with the TargetGroup dimension of ALB metrics in CloudWatch, and shared ALB traffic with the LoadBalancer dimension. describe-target-health gives real-time target status.
• Deletion. When a service is deleted, ECS disconnects it from every gateway, removes its routes and cleans up its resources — and deprovisions the ALB if it held the last route.
• Immutable settings. The name, scheme, VPC, subnets, IP address type, and listener protocol and port cannot be changed after gateway creation — get them right the first time.

The gateway is available in all commercial regions where ECS exists, at no additional charge: you pay for the infrastructure actually provisioned — ALBs, CloudWatch logs and metrics, ACM certificates and data transfer.

Where the gateway sits in the AWS lineup

ECS Gateway replaces neither App Mesh nor API Gateway. App Mesh remains the service-mesh tool — mutual TLS, application observability, traffic management between services. API Gateway remains the API-management tool — quotas, authentication, usage plans. The gateway covers strictly the HTTP/HTTPS ingress of an ECS service, via host-based routing: it is the missing brick between a container and the internet, now native to the service.

That boundary is also its limit. No advanced path-based routing, no request transformations: for those needs, you will keep driving an ALB or an API Gateway by hand. The gateway excels at the massive, repetitive case — dozens of simple web services — and steps aside for specialized requirements.

Verdict

If you run more than a few ECS services, adopt ECS Gateway. Entry cost is zero, and the payoff scales with fleet size: each new service stops being a full networking project. If you are a platform team already enforcing an ingress standard, the gateway turns that standard into a single resource instead of a runbook. If you are on EKS with App Mesh or an API gateway, stay where you are — this is not a replacement, it is the same logic finally carried natively onto ECS. A sensible first step is a staging cluster: create a gateway, connect a few low-risk services, and watch ALB and CloudWatch behavior before pointing production traffic at it.

References

• AWS News Blog — Introducing Amazon ECS Gateway
• Amazon ECS Documentation — Gateway overview
• Amazon ECS Pricing