AWS introduced Amazon ECS Gateway to manage ingress, the path by which traffic reaches ECS services. Platform teams define networking standards, while application teams connect services so the required resources can be managed for them. AWS official announcement
ECS Gateway provisions ALBs and service resources in the customer account. Charges for the underlying infrastructure still apply. An absence of an additional management fee does not make the complete networking path free.
On this page
A deployed service still needs a complete request path
A browser request depends on DNS, a TLS connection, a load balancer, and a healthy application target. Deploying a container and configuring this ingress path are related but separate jobs. Repeating the setup for every service can produce inconsistent certificate handling, routing rules, and health checks, even when the applications themselves follow a common deployment process.
Managed ingress aims to connect those resources according to a defined platform policy. Application teams identify the services to expose while platform teams establish common network boundaries. Map what the service automates and what remains your responsibility, including DNS decisions, access policy, and observability. That division also clarifies where to begin when a request fails.
Shared configuration also creates a shared change boundary
Several services using one ingress layer can reduce repeated configuration, but they can also share the effects of a faulty change. Routing rules may overlap, and common certificates or policies can affect more than one application. Review whether public applications and internal administration services belong within the same trust and operational boundary before optimizing the resource count.
Health checks need an application-level meaning. A running process is not necessarily ready to serve requests. Declaring a target healthy before its database connection is ready can cause deployment-time failures. An excessively sensitive check can instead remove healthy targets during brief delays. Define readiness using the behavior required by the service, then verify it during an update.
Compare the old and new paths during migration
In a hypothetical migration, first test TLS and routing through a temporary hostname on the new path. Exercise login, uploads, and longer responses rather than relying only on a successful landing-page request. Move a limited portion of traffic after those checks, and document the DNS or routing changes needed to return to the previous path.
Observe per-service request volume, errors, and latency alongside the underlying load-balancer metrics. An acceptable aggregate error rate can conceal a broken route. Budget for the underlying ALB and related resources separately from the management feature. Assign ownership and a deletion sequence so that automatically provisioned infrastructure is also cleaned up when a service is retired.
Migrating an existing service
- Verify network mode and the gateway’s VPC and Availability Zone requirements.
- Keep existing ingress while testing health checks and TLS on the new path.
- Plan ALB capacity, quotas, and per-service observability.
Automatically provisioned resources remain operational responsibilities. Migrate service by service while tracking changes and cleanup behavior.
Announcement reference date: 2026-10-20 · Checked: October 24, 2026
