Platform versus application
Two owners, one handoff: the platform stands up the gateway and decides which clusters can use it; application teams opt a service in. ECS does the wiring in between.
Three steps to ingress
Section titled “Three steps to ingress”
Opt-in parameter on an ECS service that names the container port for gateway traffic. Can filter PUBLIC or PRIVATE access types and set health checks.
Connect services when creating or updating a service.
On deploy, ECS evaluates every gateway on the cluster and connects the service to each compatible one.
Compatibility
Section titled “Compatibility”A gateway is eligible only when all three checks pass:
| Check | Rule |
|---|---|
| Access type | Gateway scheme maps to PUBLIC or PRIVATE; connector filters.accessTypes must allow it (omit filter to accept either) |
| VPC | Gateway subnets and service subnets are in the same VPC |
| Availability Zones | Gateway has subnets in every AZ the service uses |
The AZ rule is the one that trips people up — the gateway must cover every AZ a service runs in. Partial overlap is not enough.
What ECS provisions
Section titled “What ECS provisions”Once a service is compatible, ECS creates and manages the load balancer path for you — reusing shared pieces and adding per-route pieces.
| Scope | Resources |
|---|---|
| Shared | ALB, listener, ALB security group |
| Per route | ACM cert, hostname, listener rule, target group, service security group |
See What a connected service creates for the full breakdown.
Lifecycle
Section titled “Lifecycle”Redeploy
Associations are re-evaluated. Newly compatible gateways attach; dropped associations remove their routes.
Delete service
Its routes and per-service resources are removed. ALBs left with no services are deprovisioned.
Delete gateway
Needs deletion protection off and no cluster associations (ACTIVE or DISASSOCIATING). Clear services first so routes drain.
Prerequisites then Create VPC.