Connecting Multiple ECS Services Through Amazon ECS Gateway

Modern applications rarely run as a single containerized service. A typical application may have separate frontend, user, order, payment, notification, and reporting services. Running these services on Amazon ECS gives each component independent deployment and scaling, but it also creates a networking challenge: how should traffic reach the right service?

Amazon ECS Gateway provides a managed ingress layer for ECS services. A gateway can be associated with ECS clusters, and individual services can opt into the gateway by using a gateway connector. Amazon ECS then manages the underlying Application Load Balancer infrastructure, listener rules, certificates, target groups, service security groups, and unique HTTPS hostnames for connected services.

This becomes useful when several ECS services need a consistent ingress model without manually creating and maintaining a separate load-balancing setup for every service.

How Multiple ECS Services Connect to One Gateway

The basic architecture looks like this:

                    Clients
                       |
                       v
              Amazon ECS Gateway
                       |
          +------------+------------+
          |            |            |
          v            v            v
      User API      Order API    Payment API
       ECS Service   ECS Service   ECS Service
          |            |            |
          v            v            v
       Database      Database     Payment DB

The important point is that the gateway is not simply another ECS service.

The platform team creates and configures the gateway. ECS clusters are then associated with it. Individual application teams connect their ECS services to the gateway through a gateway connector.

When a service connects, Amazon ECS creates a gateway route and provides that service with its own HTTPS hostname. Multiple services can share the underlying Application Load Balancer infrastructure.

For example, an application might have:

ECS Service	Responsibility	Gateway Connection
user-api	Authentication and user profiles	HTTPS hostname
order-api	Order processing	HTTPS hostname
payment-api	Payment operations	HTTPS hostname
notification-api	Email and notifications	HTTPS hostname
report-api	Reporting	HTTPS hostname

Each service remains independently deployed and scaled while the gateway provides a common ingress model.

Gateway Routing for Multiple Services

Amazon ECS Gateway uses host-based routing through Application Load Balancers.

Each connected service receives a unique HTTPS hostname. Requests sent to that hostname are routed to the corresponding ECS service.

Conceptually:

https://user-service....ecs....on.aws
        |
        +--> User API

https://order-service....ecs....on.aws
        |
        +--> Order API

https://payment-service....ecs....on.aws
        |
        +--> Payment API

This differs from a traditional path-based API gateway design such as:

/api/users
/api/orders
/api/payments

With ECS Gateway, the routing model is based on the hostname assigned to the service.

This makes service ownership relatively simple because each service has an independent ingress endpoint.

Connecting an ECS Service to the Gateway

A service must use awsvpc network mode and expose a named container port that receives gateway traffic. The gateway connector identifies that port.

A simplified ECS service update looks like this:

aws ecs update-service \
    --cluster application-cluster \
    --service user-api \
    --gateway-connectors '[{
        "portName": "web"
    }]'

The corresponding container definition needs a named port.

For example:

{
  "name": "user-api",
  "image": "example/user-api:latest",
  "portMappings": [
    {
      "name": "web",
      "containerPort": 8080,
      "protocol": "tcp"
    }
  ]
}

The important detail is that the connector refers to the port name rather than simply relying on an arbitrary container port number.

When the service deploys, Amazon ECS determines which associated gateways are compatible and creates the required gateway route and supporting infrastructure.

Connecting Several Services

Suppose the cluster contains four services:

application-cluster
    |
    +-- user-api
    +-- order-api
    +-- payment-api
    +-- notification-api

Each service can opt into the gateway independently.

For example:

aws ecs update-service \
    --cluster application-cluster \
    --service user-api \
    --gateway-connectors '[{"portName":"web"}]'

aws ecs update-service \
    --cluster application-cluster \
    --service order-api \
    --gateway-connectors '[{"portName":"web"}]'

aws ecs update-service \
    --cluster application-cluster \
    --service payment-api \
    --gateway-connectors '[{"portName":"web"}]'

aws ecs update-service \
    --cluster application-cluster \
    --service notification-api \
    --gateway-connectors '[{"portName":"web"}]'

The gateway infrastructure is shared where capacity allows. A single Application Load Balancer can support up to 25 ECS services connected through the gateway. Amazon ECS can provision additional load balancers when required and within the gateway's configured limits.

Public and Private Service Connections

Not every ECS service should be publicly reachable.

A useful architecture is to separate public and private ingress:

                 Internet
                    |
                    v
             Public Gateway
                    |
              frontend-api
                    |
             Private services
          +---------+---------+
          |         |         |
       user-api  order-api  payment-api

For example, frontend-api may need public access, while payment-api should only be reachable through a private gateway or another internal networking mechanism.

Amazon ECS Gateway supports access type filtering. A service that should never be exposed through an internet-facing gateway should use a PRIVATE access type filter. Without an appropriate filter, a service may become eligible for a public gateway associated with its cluster during a later deployment.

This is an important platform-level security decision.

Gateway Does Not Automatically Mean Service-to-Service Traffic

One common architectural mistake is assuming that every ECS service should call every other service through the gateway.

For example:

order-api
    |
    +--> payment-api

does not necessarily mean:

order-api
    |
    v
ECS Gateway
    |
    v
payment-api

For internal service-to-service communication, Amazon ECS Service Connect is designed specifically for service discovery and connectivity between ECS services. AWS recommends Service Connect for ECS service-to-service communication.

A better division is often:

External client
      |
      v
ECS Gateway
      |
      v
order-api
      |
      v
Service Connect
      |
      v
payment-api

The gateway handles ingress into the application, while an internal service connectivity mechanism handles private service-to-service communication.

This reduces unnecessary network hops and keeps internal traffic separate from external ingress.

Designing Dependencies Between Services

When multiple services are connected, document their dependencies.

For example:

Source Service	Destination	Traffic Type	Recommended Pattern
Web application	user-api	External ingress	ECS Gateway
Web application	order-api	External ingress	ECS Gateway
order-api	payment-api	Internal	Service Connect
order-api	notification-api	Internal	Service Connect
Admin client	report-api	Private ingress	Private Gateway
External partner	payment-api	Controlled external access	Gateway

This prevents the gateway from becoming an unnecessary central dependency for internal communication.

Health Checks for Multiple Services

Each service connected to the gateway needs a reliable health check.

A lightweight endpoint is preferable:

GET /health

A simple ASP.NET Core example could return:

app.MapGet("/health", () =>
{
    return Results.Ok(new
    {
        status = "healthy"
    });
});

Avoid using an endpoint that performs expensive database queries or external API calls for every health-check request.

Amazon ECS configures health checks for gateway routes, and the default health-check behavior uses the root path unless another path is configured. A lightweight health endpoint is usually a safer choice for production services.

Handling Service Failures

Multiple services mean multiple possible failure points.

Consider:

Client
  |
Gateway
  |
Order API
  |
Payment API
  |
Payment Provider

If the payment provider is unavailable, the payment service may become slow or unhealthy.

The order service should not wait indefinitely.

Use explicit timeouts:

builder.Services.AddHttpClient<PaymentClient>(client =>
{
    client.BaseAddress = new Uri("http://payment-api");
    client.Timeout = TimeSpan.FromSeconds(5);
});

For internal calls, combine timeouts with appropriate retry and circuit-breaker behavior.

Do not blindly retry payment operations. A retry can accidentally submit the same payment more than once if the operation is not idempotent.

Request and Correlation IDs

When traffic crosses multiple services, troubleshooting becomes much easier when requests carry a correlation identifier.

For example:

Client
  Request ID: 8f21

     |
     v

Gateway

     |
     v

order-api
  Request ID: 8f21

     |
     v

payment-api
  Request ID: 8f21

The application should log this identifier with important operations.

A typical log entry might contain:

RequestId=8f21
Service=order-api
Operation=CreateOrder
Status=200
DurationMs=142

This allows developers to follow one request across several ECS services instead of searching logs independently.

Deployment Considerations

Adding a gateway connector or changing gateway connectivity can trigger an ECS deployment.

That means gateway configuration should be treated as part of the service deployment lifecycle rather than as an unrelated networking change.

Before production deployment:

Confirm the gateway is associated with the correct ECS cluster.
Verify the service uses awsvpc networking.
Confirm the named container port.
Check the gateway access type.
Verify Availability Zone coverage.
Confirm the health-check endpoint.
Deploy to a non-production environment first.
Verify the generated service hostname.
Test both healthy and unhealthy task behavior.
Monitor the deployment before removing an older ingress path.

Availability Zone coverage is particularly important. The gateway must cover every Availability Zone used by the ECS service. Partial coverage can result in tasks failing gateway health checks.

Common Mistakes

Sending all internal traffic through the gateway

This adds an unnecessary ingress layer to private service-to-service communication.

Use the gateway primarily for ingress and choose an internal connectivity mechanism for service-to-service traffic when appropriate.

Forgetting the access type

A service that should remain private can accidentally become eligible for a public gateway if access filtering is not configured correctly.

Using an expensive health-check endpoint

Health checks run repeatedly. Calling a database or external API from the health endpoint can create unnecessary load.

Assuming one service gets one gateway

A service connector can connect to every compatible gateway associated with its cluster. The connector does not select a gateway simply by name.

Ignoring Availability Zone coverage

A gateway that does not cover all Availability Zones used by the service can create unhealthy targets and failed deployments.

Treating the gateway as the service discovery layer

Gateway hostnames are ingress endpoints. They should not automatically become the naming mechanism for internal application dependencies.

Troubleshooting Multiple ECS Services

Problem	Likely Cause	What to Check
Service has no gateway URL	Connector or gateway association missing	ECS service configuration
Deployment fails	No compatible gateway	VPC, access type, and AZ coverage
Tasks become unhealthy	Incorrect health check	Health endpoint and port
Private service is publicly reachable	Missing access filter	Gateway connector configuration
Internal call is slow	Traffic unnecessarily crosses gateway	Service-to-service architecture
Gateway connection disappears	Gateway eligibility changed	Cluster associations and deployment
New service cannot connect	Gateway capacity or limits	Gateway and ALB resource limits
Logs are difficult to correlate	Missing request identifier	Logging and request propagation

Best Practices

Use ECS Gateway as the managed ingress layer for services that need gateway-based access.
Separate public and private ingress requirements.
Use access type filters for services that must remain private.
Use lightweight health endpoints.
Keep internal service-to-service communication separate from external ingress where appropriate.
Use consistent request and correlation IDs across services.
Define clear ownership between platform and application teams.
Test gateway configuration changes before production deployment.
Monitor gateway routes, target health, ALB metrics, and application logs.
Document service dependencies and communication patterns.
Plan Availability Zone coverage before connecting services.
Avoid manually modifying infrastructure managed by Amazon ECS Gateway.

Advantages and Disadvantages

Advantages	Disadvantages
Centralized ingress configuration	Adds another networking layer
Multiple ECS services can share ALB infrastructure	Gateway is focused on HTTPS ingress
ECS manages gateway infrastructure	Some gateway settings are immutable
Unique HTTPS hostname for each connected service	Services still need proper internal connectivity design
Platform teams can standardize networking	Incorrect gateway association can affect multiple services
Easier service onboarding	Gateway and ALB quotas still apply

When Amazon ECS Gateway Makes Sense

Amazon ECS Gateway is a good fit when an organization has multiple ECS services and wants platform teams to manage ingress standards centrally.

It is especially useful when teams want to avoid manually creating an Application Load Balancer, listener, certificate, target group, and security configuration for every ECS service.

It is less appropriate as a universal replacement for internal service-to-service networking. Internal communication should be designed independently, using mechanisms such as ECS Service Connect where they fit the workload.

Summary

Connecting multiple ECS services through Amazon ECS Gateway provides a managed way to standardize ingress across containerized applications.

The basic model is straightforward: create a gateway, associate it with ECS clusters, and connect individual services through gateway connectors. Amazon ECS then creates the required routes and supporting ingress resources, giving each connected service an HTTPS hostname.

The important architectural decision is knowing where the gateway belongs. Use it for controlled ingress into ECS services, while keeping internal service-to-service communication on an appropriate private connectivity model.

For production systems, pay particular attention to access type, Availability Zone coverage, health checks, request tracing, deployment behavior, and gateway capacity. With those pieces planned correctly, multiple ECS services can share a consistent ingress architecture without requiring each application team to manage the underlying load-balancing infrastructure.