ECS Gateway vs ALB: Should You Replace Your ECS Ingress?

Not yet as a blanket swap. ECS Gateway fits services that can live behind HTTPS on port 443 with host-based routing and a generated hostname. It moves ALB, certificate and DNS work to ECS. Teams with custom listeners or carefully tuned ALB rules should pilot one internal service first and compare bills before retiring anything.

What is Amazon ECS Gateway?

Amazon ECS Gateway is a managed ingress layer for ECS services that creates and runs the load balancing infrastructure for you. As each service opts in, ECS provisions the Application Load Balancer, listeners, target groups, security groups, certificates and DNS hostnames. The ECS developer guide documents how it works.

The model splits ownership. A platform team creates a gateway, sets its networking, security and operations policy, and associates it with one or more clusters. Associations are many-to-many, so one gateway can serve several clusters and one cluster can use several gateways. An application team then adds a gateway connector to a service. The connector names the container port that receives traffic and can set an access type filter and health checks.

Creating a gateway provisions nothing. ECS builds the shared load balancer only when the first service connects. It then adds a listener rule, target group, certificate, security group and hostname for each connected service. Routing between services on a shared ALB is host-based, and each service gets a generated HTTPS hostname under the ecs..on.aws domain.

Who should consider replacing their ALB with ECS Gateway?

Teams that run many small HTTPS services, each with its own hand-wired ALB, listener rules and certificates, are the clearest fit. For them the gateway removes repeated setup and centralizes policy such as the WAF web ACL, the inbound security group, the access log destination and load balancer capacity. It also sets the request header that marks test traffic during progressive deployments, which matters if those are part of the release pipeline.

The fit is weaker for ingress built around anything other than HTTPS on port 443, because the gateway listener supports only that protocol and port. A team that serves plain HTTP internally, needs other ports, or depends on routing rules beyond the hostname should map those requirements against the gateway documentation before planning a move. Public traffic on branded domains needs the same check. The docs describe a generated hostname per service, so work out how a custom domain would sit in front of it.

Permissions shift too, mostly in a helpful direction. Load balancer creation rights live in an infrastructure IAM role that ECS assumes, built on an AWS managed policy for gateways with host-shared ALBs. Application teams need neither iam:PassRole nor gateway API access to give a service an HTTPS endpoint. Only the user or role that creates or updates the gateway must be allowed to pass that role.

Does ECS Gateway reduce load balancer costs?

It can, because services with the same networking configuration share one Application Load Balancer instead of each running their own. AWS lists that sharing as the cost benefit. The material behind this analysis gives no gateway price and no ALB unit price, so work out the saving against the current Elastic Load Balancing pricing page and your own bill.

A first estimate is simple. Count the ALBs in front of ECS today, group them by scheme, subnets and IP address type, and see how many groups remain. Each group is roughly one shared gateway load balancer. If most services already sit behind a single shared ALB, the cost case is thin and the argument has to rest on operations.

What are the migration risks?

The biggest risk is picking gateway settings that cannot be changed later. Name, subnets, IP address type and scheme are fixed at creation. Changing one means creating a new gateway, reconnecting every service to it, and deleting the old one. Subnets decide which VPC and Availability Zones the gateway covers, and a service connects only to gateways that cover where it runs. The defaults are an internet-facing scheme, dualstack addressing and the default VPC’s subnets, which may not match a production network.

The second risk is drift with infrastructure as code. ECS tags everything it creates with AmazonECSManaged=true. If that tag is changed or removed, ECS can no longer update or clean up the resource. Terraform or CloudFormation modules that rewrite tags broadly, or engineers who edit load balancers by hand, can break that contract without noticing.

Two smaller items tend to trip first attempts. A newly created infrastructure role can fail on the first create call because IAM is eventually consistent, so automation should wait briefly and retry. A Region without a default VPC needs explicit subnets when the gateway is created.

What to check this week

Spend two days on inventory. List every ALB in front of ECS with its listeners, ports, protocols, rule types, domains and WAF attachment. Mark anything that is not HTTPS on 443 or that routes on more than the host. Those services stay on their current ALB for now.

Spend one day on cost. Group the remaining services by scheme, subnets and IP address type, then price the shared result against today’s load balancer line items.

Spend the last two days on a pilot in a non-production account. Create the infrastructure role, create an internal gateway with explicit subnets, and connect one low-risk service. Read back the gateway route, its status, its URL and the resources ECS created. Then run your IaC pipeline and see how its next plan treats the AmazonECSManaged tag. If the pilot holds and the grouping shows real consolidation, record the immutable settings as a written decision before any production gateway exists.

Sources

• docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-overview.html, retrieved 2026-10-23.
• docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-managing.html, retrieved 2026-10-23.