Running a containerized application on Amazon Elastic Container Service (Amazon ECS) is only part of deploying it. Users also need a reliable way to reach the application over the network.
Traditionally, exposing an ECS service to HTTP or HTTPS traffic involves configuring an Application Load Balancer (ALB), listeners, target groups, security groups, certificates, and routing rules. These resources work together, but managing them for multiple services can add complexity to a deployment.
Amazon ECS Gateway simplifies this process by allowing platform teams to define ingress networking settings centrally and connect ECS services to that configuration. Amazon ECS then provisions and manages the required networking resources.
AWS announced ECS Gateway on October 20, 2026. It supports host-based HTTPS routing and can share an Application Load Balancer across multiple services. Each connected service receives a unique HTTPS hostname.
This article explains how ECS Gateway works, how to connect a service, and what developers should consider before using it in production.
What Is Amazon ECS Gateway?
Amazon ECS Gateway is a managed ingress solution for containerized applications running on Amazon ECS.
Ingress refers to the path incoming network traffic follows to reach an application. In a typical web application, a user sends an HTTPS request to a hostname, a load balancer receives the request, and the load balancer forwards it to a healthy application container.
ECS Gateway automates much of the infrastructure setup required for this process.
Instead of manually creating and connecting every load-balancing resource for each service, platform teams configure a gateway and associate it with ECS clusters. Application teams can then connect eligible services to that gateway.
ECS manages the required Application Load Balancer resources, certificates, DNS hostnames, target groups, and routing rules.
How ECS Gateway Works
Consider an application consisting of three services:
Each service runs as an ECS service and needs to receive HTTPS traffic.
Without a managed gateway, teams may need to configure separate ingress resources or manually manage shared load-balancing infrastructure.
With ECS Gateway, the platform team defines the gateway configuration once. Each application team connects its service by specifying the container port that should receive traffic.
ECS then creates a gateway route for the service and assigns a unique HTTPS hostname.
The overall request flow looks like this:
User or Client
|
| HTTPS Request
v
Amazon ECS Gateway
|
v
Application Load Balancer
|
| Host-Based Routing
v
Target Group
|
v
Healthy ECS Task
|
v
Container Application
The gateway manages the ingress infrastructure, while the application continues to run inside its ECS task.
Amazon ECS Gateway vs. Traditional Load Balancer Configuration
ECS Gateway does not eliminate the underlying load balancer. Instead, it automates the provisioning and management of the infrastructure needed to expose ECS services.
Area | Traditional ECS ingress | ECS Gateway |
|---|
Load balancer setup | Teams configure the required resources | ECS provisions and manages the required resources |
Routing rules | Configured through load balancer settings | Created for connected services |
HTTPS certificates | Teams configure certificate resources | ECS manages service-specific certificates |
Service hostname | Configured through the team's routing setup | Each connected service receives a unique HTTPS hostname |
Security configuration | Managed through the selected ingress resources | Centralized through gateway configuration |
Multi-service deployments | Teams manage resource sharing and routing | Compatible services can share gateway infrastructure |
Operational responsibility | More manual infrastructure configuration | Less manual ingress configuration |
Traditional load balancer configuration remains useful when an application requires specific routing behavior or infrastructure that does not fit ECS Gateway's supported model.
ECS Gateway is particularly useful when teams want a consistent way to expose multiple ECS services without repeating the same ingress configuration.
Prerequisites for Using ECS Gateway
Before connecting a service, verify that your environment meets the gateway requirements.
An ECS Cluster and Service
You need an ECS cluster containing the service you want to expose. The gateway and the cluster must belong to the same AWS account.
The Correct Network Mode
The service must use awsvpc network mode. Services using bridge, host, or none network modes cannot connect to ECS Gateway.
The gateway supports ECS services running on Fargate, EC2, and ECS Managed Instances, subject to the documented requirements.
A Named Container Port
The task definition must define a named port for the container that receives incoming traffic. The gateway connector refers to this port by name.
An Associated Gateway
The gateway must already be associated with the ECS cluster, and the association must be active.
Compatible gateway and service networking configurations must also align, including the VPC, access type, and Availability Zone requirements.
Step 1: Configure the Container Port
Suppose you have a Node.js API that listens on port 3000.
Your ECS task definition needs to expose the application port and assign it a name.
A simplified container definition might look like this:
{
"name": "orders-api",
"image": "example/orders-api:latest",
"essential": true,
"portMappings": [
{
"name": "web",
"containerPort": 3000,
"protocol": "tcp"
}
]
}
The important setting is "name": "web".
The gateway connector uses this name to identify the container port that should receive incoming traffic.
The example shows only the relevant container definition fields. A complete task definition must include the other settings required by your application, such as its execution role, logging configuration, and appropriate resource settings.
In production, use an image reference that follows your deployment and versioning policies rather than relying on a mutable latest tag.
Step 2: Associate the Gateway With Your Cluster
The platform team creates an ECS Gateway and configures its ingress settings.
Depending on the application requirements, these settings can include:
Whether the services are accessible from the internet or only within the VPC.
The subnets used by the load-balancing infrastructure.
The security group controlling inbound traffic.
The AWS WAF web ACL, where applicable.
Access logging and other operational settings.
The team then associates the gateway with one or more ECS clusters.
Gateway configuration is an important platform-level decision because connected services inherit the applicable networking and security settings.
Review these settings before connecting production workloads. Some gateway settings cannot be changed after creation, so the initial configuration should match the intended deployment architecture.
Step 3: Connect the ECS Service to the Gateway
Once the gateway association is active and the task definition contains a named container port, you can connect the service.
The AWS CLI command for updating an existing ECS service is:
aws ecs update-service \
--cluster my-cluster \
--service orders-api \
--gateway-connectors '[{"portName":"web"}]'
Replace my-cluster and orders-api with your actual ECS cluster and service names.
The portName value must match the name declared in the task definition. In this example, the value is web.
When the service deployment proceeds, ECS selects compatible gateways and creates or reuses the required ingress infrastructure. It then creates a gateway route for the service.
The route provides the service's HTTPS hostname and reports the connection status. The exact hostname is generated by ECS, so you should retrieve it from the resulting gateway route rather than inventing one.
If multiple gateways associated with the cluster are compatible with the service, the connector can connect the service to those gateways. A service supports only one gateway connector, although that connector can connect it to multiple compatible gateways.
Step 4: Verify Routing and Health Checks
Connecting a service does not automatically guarantee that the application is ready to handle requests.
Verify that the service deployment completes successfully and that its gateway route reports a healthy connection status.
You should also check the underlying target group's health.
An Application Load Balancer periodically sends health checks to registered targets. Only healthy targets normally receive traffic when healthy targets are available.
For an application listening on port 3000, a health endpoint might return HTTP 200 when the application is ready to serve requests.
For example, an Express application could provide a basic endpoint:
const express = require("express");
const app = express();
app.get("/health", (req, res) => {
res.status(200).json({
status: "healthy"
});
});
app.listen(3000, "0.0.0.0", () => {
console.log("Application listening on port 3000");
});
This example provides a simple health endpoint. A production readiness check may also need to verify that required dependencies are available.
Configure the gateway connector's health-check settings to match the application's actual readiness endpoint and response behavior.
Avoid reporting an application as ready if it cannot perform the work required to serve requests. At the same time, do not make a basic health check depend on every optional downstream service, because a temporary dependency problem could remove otherwise useful application capacity.
Security and Production Considerations
Choose the Correct Access Type
Not every ECS service should be publicly accessible.
Use an internet-facing configuration only when external clients need access. Internal APIs should use an appropriate private access configuration.
Review the gateway's networking settings and the security groups controlling traffic between the load balancer and ECS tasks.
Keep Application Permissions Separate
ECS Gateway manages ingress infrastructure, but it does not replace application authentication or authorization.
An HTTPS endpoint can still expose sensitive functionality if the application does not validate user identity and permissions.
Continue to enforce authentication, authorization, input validation, and rate limits where required.
Monitor Traffic and Availability
Use Amazon CloudWatch metrics and the available Elastic Load Balancing target health information to investigate traffic patterns and service failures.
Monitor application errors and latency alongside infrastructure health. A healthy target does not necessarily mean that the application is returning correct business results.
Plan for Capacity
ECS Gateway can allow up to 25 services to share one Application Load Balancer. It can provision additional load balancers when capacity or compatibility requirements call for them.
However, sharing infrastructure does not mean that every service has unlimited capacity. Consider traffic levels, resource limits, and failure scenarios when planning a deployment.
Common Mistakes to Avoid
One common mistake is connecting a service that does not use awsvpc network mode. Confirm the task definition and service configuration before attempting the connection.
Another mistake is specifying a port name that does not match the task definition. The connector refers to the named container port, not merely the numeric port.
Teams may also overlook gateway-cluster associations. The association must be active before a service can connect successfully.
Finally, avoid treating a successful deployment as proof that the application is reachable and healthy. Verify the generated hostname, routing configuration, security rules, and target health after deployment.
Advantages and Disadvantages of ECS Gateway
Advantages
Reduces manual configuration of ingress infrastructure.
Centralizes networking and security settings.
Provides a unique HTTPS hostname for each connected service.
Allows compatible services to share Application Load Balancers.
Reduces repeated configuration work for application teams.
Disadvantages
Requires services to use awsvpc network mode.
Supports HTTPS ingress rather than arbitrary application protocols.
Provides less flexibility for configurations outside its supported model.
Requires careful initial gateway configuration because some settings cannot be changed later.
Still incurs charges for the underlying AWS infrastructure.
AWS does not charge an additional fee specifically for ECS Gateway, but the underlying resources, including Application Load Balancers and applicable data transfer and monitoring services, remain chargeable.
Summary
Amazon ECS Gateway simplifies the process of exposing containerized applications running on Amazon ECS. Platform teams configure ingress networking centrally, associate the gateway with clusters, and allow application teams to connect eligible services through a gateway connector.
ECS then manages the required load-balancing resources, certificates, hostnames, and routing rules.
For production use, confirm the awsvpc network mode, define a named container port, configure the gateway association, and verify service health after deployment. Continue to enforce application-level security and monitor traffic and availability.
ECS Gateway is a useful option for teams that want a consistent way to expose multiple ECS services without manually managing every ingress resource. The best fit depends on the application's networking requirements and how much control the team needs over its load-balancing infrastructure.
Join the conversation! Your thoughts help the community grow.