AWS Just Launched ECS Gateway: What Changes for DevOps Engineers?

If you've deployed applications on Amazon ECS, you've probably dealt with the networking setup needed to make a container accessible.

Deploying the container is one part. Exposing it often means configuring:

• An Application Load Balancer (ALB)
• Target groups and health checks
• Listener rules
• Security groups
• TLS certificates and DNS

You can manage these with Terraform or CloudFormation, but as the number of services grows, so does the infrastructure configuration you have to maintain.

On October 20, 2026, AWS announced Amazon ECS Gateway, a managed ingress solution for ECS services.

The interesting part isn't that AWS invented a new load balancer.

It's that ECS can now manage much of the load balancer infrastructure for you.

Let's look at what changes and what stays the same.

---

What Is Amazon ECS Gateway?

Amazon ECS Gateway is an ECS resource that defines shared ingress settings for services.

You associate a gateway with one or more ECS clusters, and individual ECS services opt in using a gateway connector.

ECS then provisions or reuses the underlying resources, including:

• Application Load Balancers
• HTTPS listeners
• Target groups
• Security groups
• TLS certificates
• DNS hostnames

Platform teams configure the gateway; application teams connect their services.

Important: ECS Gateway doesn't replace the Application Load Balancer. It automates provisioning and managing ALB-based ingress.

Also, creating a gateway doesn't immediately create an ALB. ECS provisions the first one when a service connects.

---

Before vs. After ECS Gateway

Imagine three microservices running on ECS:

• orders-api
• products-api
• payments-api

Before ECS Gateway

You could use a shared ALB with separate target groups and host-based listener rules.

However, you'd still configure and maintain those resources yourself, perhaps through Terraform.

                     Application Load Balancer
                               |
                  +------------+------------+
                  |            |            |
             Target Group  Target Group  Target Group
                  |            |            |
              Orders API   Products API  Payments API

Sharing an ALB across ECS services was already possible.

That isn't the new feature.

With ECS Gateway

A platform engineer defines the gateway configuration once and associates it with ECS clusters.

Services add a gateway connector specifying the named container port to expose.

ECS manages the shared ALB and service-specific routing resources, and each connected service gets a generated HTTPS hostname.

What's new is the infrastructure lifecycle management, not the concept of host-based routing.

---

How ECS Gateway Works

There are three main steps.

Step 1: Create an ECS Gateway

A platform team creates a gateway and defines settings such as:

• Public or private ingress
• VPC subnets
• Security groups
• AWS WAF configuration
• Access logging
• Maximum ALB capacity

The gateway becomes a centrally managed ingress configuration.

Step 2: Associate the Gateway with ECS Clusters

The gateway is associated with one or more ECS clusters.

This allows different application teams to use the same networking standards.

Step 3: Connect ECS Services

An application team adds a gateway connector to its ECS service.

The connector specifies which named container port should receive traffic.

When the service deploys, ECS checks for compatible gateways, creates a gateway route, and provisions or reuses the required infrastructure.

Request Flow

Here's a simplified architecture:

Client
  |
  | HTTPS :443
  v
Shared Application Load Balancer
  |
  | Host-based listener rule
  v
Service Target Group
  |
  v
ECS Task

Each service gets a unique generated URL following a pattern like:

https://<unique-id>.ecs.<region>.on.aws

ECS uses the hostname to route incoming requests to the appropriate target group.

One ALB can serve up to 25 ECS services through ECS Gateway.

When existing ALBs reach capacity, ECS can add another, up to the gateway's configured limit.

---

Getting Started with ECS Gateway Using AWS CLI

Let's look at a simplified example based on the official AWS documentation.

Note: This example assumes you already have an ECS cluster, an ECS service using awsvpc networking, a suitable VPC, and the necessary IAM permissions. It is not a complete production deployment.

Step 1: Create an ECS Infrastructure IAM Role

ECS needs permission to provision and manage the gateway's ingress resources.

The IAM role must trust ecs.amazonaws.com and have the AWS-managed policy:

AmazonECSInfrastructureRoleForGatewayHostSharedALB

Create the role using the AWS CLI in a Bash-compatible shell:

aws iam create-role \
  --role-name ecsInfrastructureRoleForGateways \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ecs.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

Attach the managed policy:

aws iam attach-role-policy \
  --role-name ecsInfrastructureRoleForGateways \
  --policy-arn arn:aws:iam::aws:policy/AmazonECSInfrastructureRoleForGatewayHostSharedALB

Your IAM identity must also have the necessary ECS permissions and iam:PassRole permission for this infrastructure role.

Step 2: Create the Gateway

For an AWS account with a suitable default VPC:

aws ecs create-gateway \
  --name shared-ingress \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForGateways \
  --configuration '{"hostSharedAlb": {}}'

Replace 123456789012 with your AWS account ID.

If your ECS service runs in a custom VPC, configure the gateway subnets explicitly.

Otherwise, the gateway's default VPC might not match the ECS service.

Verify the gateway:

aws ecs describe-gateway \
  --gateway shared-ingress

Step 3: Associate the Gateway with Your ECS Cluster

aws ecs associate-gateway-with-cluster \
  --gateway shared-ingress \
  --cluster my-cluster

Wait until the gateway-cluster association becomes ACTIVE before connecting a service.

Step 4: Connect an ECS Service

Assume our orders-api service:

• Already exists in my-cluster
• Uses awsvpc networking
• Has a named task-definition port called api
• Responds with HTTP 200 at /health

Connect it using:

aws ecs update-service \
  --cluster my-cluster \
  --service orders-api \
  --gateway-connectors '[
    {
      "portName": "api",
      "filters": {
        "accessTypes": ["PUBLIC"]
      },
      "healthCheck": {
        "healthCheckPath": "/health"
      }
    }
  ]'

The connector matches all compatible public gateways associated with the cluster.

It does not select one by gateway name.

Compatibility also depends on VPC and Availability Zone coverage.

Deployment consideration: Changing gateway health-check configuration later may require replacing a target group. AWS documents restrictions on doing this with the ROLLING deployment strategy. Plan these changes carefully.

Once the deployment succeeds, inspect the gateway connection in the ECS service revision.

Look for an ACTIVE connection and its generated serviceUrl.

For the complete setup and verification procedure, refer to the official AWS connection guide.

---

Why ECS Gateway Matters for DevOps Engineers

I see three particularly useful improvements.

1. Less Repetitive Infrastructure Configuration

Terraform and CloudFormation already help us automate ALB provisioning.

However, we still have to maintain configurations for:

• Listener rules
• Target groups
• Security groups
• Certificates
• Resource relationships

ECS Gateway shifts much of this infrastructure lifecycle management into ECS itself.

This could be particularly useful for teams frequently deploying new microservices.

2. More Consistent Networking and Security

In a traditional setup, different application teams might configure their ingress infrastructure differently.

For example:

• One service uses restricted security groups.
• Another exposes unnecessary ports.
• Another has inconsistent routing configurations.

ECS Gateway lets platform engineers establish common networking standards.

Application teams can then connect their ECS services without independently rebuilding the same ingress setup.

Of course, this doesn't remove the need for IAM controls, network security reviews, or application-level authentication.

3. Potential Cost Savings

Application Load Balancers have ongoing costs.

Running a separate ALB for every small microservice can become expensive.

Since ECS Gateway allows up to 25 services to share one ALB, it could help reduce unnecessary load balancer provisioning.

However, there's an important distinction:

ECS Gateway itself has no additional charge, but the underlying AWS resources are still billed.

You still pay for services such as:

• Application Load Balancers
• Applicable CloudWatch usage
• Data transfer
• Other underlying infrastructure

Actual savings depend on your existing architecture and traffic patterns.

---

Important ECS Gateway Limitations

Before adopting it in production, there are several limitations worth understanding.

1. HTTPS-Only Ingress

ECS Gateway currently uses HTTPS listeners on port 443.

It's not a general-purpose TCP or UDP ingress solution.

2. awsvpc Networking Is Required

ECS services must use awsvpc networking.

Bridge, host, and none network modes aren't supported.

3. VPC and Availability Zone Compatibility

The gateway and ECS services must use a compatible VPC configuration.

Gateway subnets must cover the Availability Zones used by the service.

4. No Direct Gateway Selection

Services connect to every compatible gateway associated with their cluster.

You cannot directly select a specific gateway by name in the connector.

5. Maximum 25 Services per ALB

A shared ALB supports up to 25 connected services.

ECS can provision additional ALBs as necessary, within the configured gateway capacity.

6. No Automatic ALB Consolidation

ECS doesn't automatically move services between partially filled ALBs just to consolidate them.

This is worth considering when evaluating long-term infrastructure costs.

7. Avoid Modifying ECS-Managed Resources

Manually changing resources provisioned by ECS Gateway can interfere with deployments, routing, and cleanup.

Gateway settings such as scheme and subnets also cannot be changed after creation.

Plan these carefully before production adoption.

---

ECS Gateway vs. ECS Service Connect

One common question is whether ECS Gateway replaces ECS Service Connect.

The answer is no.

They solve different networking problems.

Feature	Primary Purpose
ECS Gateway	Manage ingress into ECS services through shared ALBs
ECS Service Connect	Enable service discovery and communication between applications
Application Load Balancer	Distribute incoming application traffic to configured targets

For example, imagine an e-commerce application.

External clients access the orders-api service through ECS Gateway.

The orders-api communicates with an internal inventory-api using ECS Service Connect.

Both features can work together in the same architecture.

---

Should You Start Using ECS Gateway?

For a new ECS project with several HTTP-based services, I think ECS Gateway is worth evaluating.

It can reduce repetitive ingress configuration and improve consistency between deployments.

However, I wouldn't recommend immediately migrating every existing ECS application.

If your current infrastructure already uses Terraform-managed ALBs with specialized routing requirements or established deployment workflows, compare those requirements with ECS Gateway's limitations first.

AWS documents a gradual migration approach:

1. Keep your existing load balancer.
2. Add a gateway connector to the ECS service.
3. Test the generated gateway endpoint.
4. Validate routing, health checks, and application behavior.
5. Consider removing the original ingress configuration after successful testing.

This allows teams to evaluate the new feature without immediately replacing production ingress infrastructure.

---

Final Thoughts

AWS ECS Gateway is an interesting addition to the ECS ecosystem.

For me, the most important takeaway isn't simply that multiple services can share one ALB.

We've already been able to do that using existing AWS infrastructure.

The bigger improvement is that ECS can now manage more of the ingress infrastructure lifecycle automatically.

Instead of managing every ALB listener rule, target group, and related resource individually, application teams can connect their services to centrally managed gateway configurations.

It doesn't eliminate the need to understand networking.

We still need to consider security, availability, routing, costs, and operational requirements.

But reducing repetitive infrastructure configuration is a meaningful improvement.

I'm interested to see how this feature evolves and how teams adopt it alongside their existing infrastructure-as-code workflows.

Would you use ECS Gateway for your next ECS deployment, or would you prefer to keep managing ALBs through Terraform?

---

References

1. AWS Announcement — Amazon ECS Gateway
2. Amazon ECS Gateway Documentation
3. Creating and Managing ECS Gateway
4. Connecting ECS Services to a Gateway

---

Thanks for reading! If you're working with AWS ECS, I'd love to hear your thoughts on this new feature.