ECS Gateway vs ALB Which Ingress Should You Own?

ECS Gateway vs ALB is an ownership decision, not a choice between two traffic-processing services. Launched on 20 October 2026, ECS Gateway provisions Application Load Balancers inside your AWS account. It manages ALB-based ingress; it does not replace ALB with another data plane.

The AWS launch announcement describes platform-defined networking standards and application-team connectors. The platform team defines the boundaries; application teams connect services within them. That changes who handles service onboarding, not where application traffic flows.

Do not confuse it with Amazon API Gateway, an API front door, or Gateway Load Balancer, which distributes traffic through network appliances.

Team-managed ECS ingress: your team provisions and operates the ALB and its service routing.

client → team-managed ALB → service target group → private ECS tasks

Gateway-managed ECS ingress: Gateway takes the ALB management role. Its management relationship sits above the traffic path, not inside it.

Management relationship: ECS Gateway manages the ALB below.
Traffic path:
client → gateway-managed ALB → service target group → private ECS tasks

For a Fargate load balancer, the important question remains operational: who approves exposure, changes routing and owns failed health checks? Across multiple services, unclear ownership becomes an on-call problem.

Treat ingress as part of platform architecture and cloud engineering, not merely a resource attached to an ECS service. Use three tests: Control, Cost, Exit.

• Control: preserve required networking, security and routing controls; name the team accountable for them.
• Cost: assess Amazon ECS Gateway pricing against the actual topology, including your shared ALB baseline.
• Exit: make any ECS Gateway migration reversible, with an owner for restoring the previous traffic path.

A reliable, self-service shared ALB is not technical debt merely because Gateway exists. In ECS Gateway vs ALB decisions, control earns its keep when teams can onboard without a networking ticket.

ECS already supports multiple services behind an ALB using path-based routing. Listener-rule priorities determine which matching rule wins. Gateway did not invent sharing, and separate target groups do not create separate failure boundaries.

Use Gateway’s documented host-routing model as the supported baseline. Make required listener behaviour, authentication, certificates, WAF policy boundaries and deployment tooling acceptance criteria. Neither assume every ALB feature is exposed nor declare undocumented incompatibilities.

• Keep: a reliable shared ALB with self-service provisioning and accountable ownership.
• Pilot: Gateway for standardised new-service onboarding before committing to an ECS Gateway migration.
• Retain dedicated infrastructure: where a specific isolation requirement justifies its operational overhead.

Understanding Cloud Risks expands on ownership and operational exposure.

Cost model: 20 October 2026. Region: London (eu-west-2); USD; 730 hours; two Availability Zones; internet-facing IPv4; prices before VAT. For ECS Gateway vs ALB, price the topology before claiming engineering savings.

AWS states that Gateway has no additional charge and shares up to 25 services per ALB. Amazon ECS Gateway pricing still includes the underlying load balancers and their usage.

Each cell below shows ALB count / monthly public IPv4 charge. The existing shared ALB has sufficient quotas; the gateway-managed pool is fully packed.

Assume two public addresses per ALB. At $0.005 per address-hour, that is $7.30 per ALB-month. This is an address-count assumption, not a fixed ALB address ceiling.

Define B as the London ALB-hour rate and L as the London LCU-hour rate.

Infrastructure subtotal =
730 × ALB count × B
+ L × total billed LCU-hours
+ public IPv4 charges

LCU billing takes the highest usage dimension per ALB, calculated hourly. Equal service counts do not establish equal usage costs. The shared ALB column shows its full footprint, not an incremental onboarding charge.

• Outside this ingress subtotal: WAF, logging, applicable certificates, DNS and data transfer.
• Keep unchanged task compute separate, including Fargate.

Hypothetical engineering ledger: two onboardings monthly × one hour saved × £100/hour = £200 monthly. Sixteen ECS Gateway migration hours cost £1,600: eight months’ labour-only payback. Keep this GBP ledger separate from USD infrastructure costs; Understanding Cloud Cost Dynamics explains why workload assumptions matter.

Pick one existing ECS service using rolling updates, with known health checks and an unchanged shared ALB route. Avoid a new VPC: that tests provisioning, not ECS ingress. Keep production DNS, listeners and target groups untouched.

The commands below adapt AWS’s documented Gateway creation example; they are not independently executed test results. Set the values for your pilot environment, then check your identity and CLI version.

export AWS_REGION=eu-west-2
export AWS_DEFAULT_REGION="$AWS_REGION"
export CLUSTER=your-existing-cluster
export SERVICE=your-existing-service
export ROLE_ARN=arn:aws:iam::123456789012:role/ecs-gateway-infrastructure
export SUBNET_A=subnet-REPLACE_A
export SUBNET_B=subnet-REPLACE_B
export OLD_TG_ARN=arn:aws:elasticloadbalancing:eu-west-2:123456789012:targetgroup/existing/0123456789abcdef

aws sts get-caller-identity
aws --version

get-caller-identity establishes the account and principal receiving these changes. The version output identifies the CLI installation; if it lacks Gateway commands, update it before changing infrastructure.

Capture the read-only baseline first. Save both outputs with the pilot record.

aws ecs describe-services --cluster "$CLUSTER" --services "$SERVICE"
aws elbv2 describe-target-health --target-group-arn "$OLD_TG_ARN"

The service description establishes deployment strategy, task definition, desired and running counts, and existing load-balancer attachments. Target health establishes which registered targets currently pass ALB checks, including failure reasons. Neither proves the complete application path works; retain an HTTP smoke check too.

The infrastructure role lets ECS Gateway provision and manage supporting ingress resources on your behalf. Configure its trust and permissions using AWS’s requirements, separately from task and execution roles.

aws ecs create-gateway \
  --region "$AWS_REGION" \
  --name ingress-pilot \
  --infrastructure-role-arn "$ROLE_ARN" \
  --configuration "{\"HostSharedAlb\":{\"networkConfiguration\":{\"subnets\":[\"$SUBNET_A\",\"$SUBNET_B\"],\"ipAddressType\":\"ipv4\"},\"scheme\":\"internet-facing\"}}"

aws ecs associate-gateway-with-cluster \
  --region "$AWS_REGION" \
  --gateway ingress-pilot \
  --cluster "$CLUSTER"

Use suitable existing public subnets for this internet-facing example. Gateway creation provisions additional infrastructure; it is not a free configuration preview. Cluster association alone does not replace the service’s existing ingress.

Keep IAM, networking and service configuration in separate changes. An access-denied error should not arrive alongside a routing change and a new task revision. That separation makes an ECS Gateway migration pilot diagnosable.

1. Preserve the working path. Retain the old ECS service load-balancer configuration, security-group access and listener rules while adding the connector. AWS documents incremental adoption with both ingress paths available. Keep the shared ALB operational throughout this ECS Gateway migration.

2. Validate independently. Test HTTPS against the generated service endpoint. Inspect existing ALB target health and check CloudWatch errors, latency and application logs for both paths.

   curl --fail --silent --show-error "https://$GATEWAY_HOST/health"
   aws elbv2 describe-target-health --target-group-arn "$TARGET_GROUP_ARN"

   Exercise login redirects, cookies, uploads, long-running connections and WAF responses. A healthy target alone proves little about user journeys.

3. Define the cutover boundary. The existing client or upstream must be able to select either validated endpoint. A CNAME change does not prove the production hostname’s certificate or host-routing rule works. If that hostname is mandatory, retain the old ALB unless both routes demonstrably accept it with correct TLS and routing.

4. Shift traffic in measured stages. For an endpoint-aware upstream, try 1%, 10%, 50%, then 100%. This is an example upstream policy, not a Gateway feature. Illustrative, service-specific gates at each stage: no new synthetic failures, no sustained 5xx increase above 0.5 percentage points, and p95 latency within 10% of baseline for 15 minutes. Pause or roll back on failure; this is not a zero-downtime guarantee.

5. Expect application-level surprises. Hypothetical failure: /health succeeds, but authentication redirects still point to the previous hostname. Login loops expose a failure the health probe missed. Stop promotion rather than treating green infrastructure checks as acceptance.

6. Roll traffic back first. Send the upstream back to the old endpoint, confirm old-path recovery, then address the failed replacement. Never delete the old route first. As with any cloud migration, rollback must remain executable under pressure.

The ECS Gateway vs ALB decision should end with a named owner, not a platform preference. Cloudline’s Control, Cost, Exit framework is an editorial decision aid, not an AWS requirement.

Your decision card

• Stay: your shared ALB already provides reliable self-service onboarding, required routing controls and clear operational ownership. Keep it when that control earns its maintenance cost.
• Pilot: routine ECS ingress work creates a measurable queue, and the application fits Gateway’s documented model. Record request-to-live lead time and engineer hours before changing anything.
• Migrate incrementally: the pilot meets agreed service-level objectives, the engineering ledger shows worthwhile savings, and traffic rollback remains independent of the replacement. Move one service first, not the entire estate.

A mixed estate is a valid outcome. Applications with different security, routing or organisational boundaries need not share one ingress model. Standardise the decision process rather than forcing universal adoption.

Name the people who still carry the pager

Put a named accountable owner against each responsibility. Outsourcing provisioning does not outsource production accountability.

• IAM permissions: platform or security lead.
• Networking policy: network or platform lead.
• Application health: the service-owning team.
• Incident response: a named on-call team with an escalation path.
• Cost monitoring: platform owner, supported by finance.

Bring a review pack, not a slide deck

Collect the service inventory, current listeners and target groups, certificate and WAF requirements, last month’s ingress spend, onboarding lead time and a rollback diagram. Compare Amazon ECS Gateway pricing with the complete ALB topology and measured engineering effort. Set a review date and record who can authorise traffic changes.

For a second pair of eyes on that decision, Talk to a cloud engineer about an ECS ingress architecture review.

Choose the ownership model that removes genuine friction without weakening controls you rely on. A well-run shared ALB may still be the right answer; a standardised gateway pilot may expose a better one. Keep infrastructure charges separate from engineering savings, and keep the old route until the new path has proved itself. Cloudline Consulting can help review your ECS ingress architecture, map the boundaries and decide whether to stay, pilot or migrate.