Amazon ECS Gateway: ingress administrado para tus servicios, con ALBs compartidos y sin módulos propios

El 20 de octubre de 2026 AWS presentó Amazon ECS Gateway, un recurso nuevo a nivel de cuenta que se encarga del ingress de tus servicios de Amazon ECS. En vez de que cada servicio tenga su propio Application Load Balancer, su listener, su target group, su security group y su certificado, el equipo de plataforma define un gateway una sola vez y los servicios se conectan con un parámetro en el create-service o el update-service. ECS crea y mantiene todo lo de abajo, y además reparte los servicios en ALBs compartidos de hasta 25 servicios cada uno.

Si alguna vez armaste un módulo de Terraform "para que los equipos no tengan que pensar en el ALB", ya sabés qué problema ataca. La diferencia es que ahora ese módulo lo mantiene AWS, viene con reglas de compatibilidad, límites y un par de trampas que conviene conocer antes de mover servicios productivos.

En este artículo vemos qué es, cómo decide ECS a qué gateway conectar cada servicio, cómo se configura de punta a punta con la AWS CLI, cuánto cuesta en la práctica y qué mirar con lupa si corrés en São Paulo.

TL;DR

• ECS Gateway es un recurso de cuenta (con su propio ARN) que provisiona y administra el ingress de servicios ECS: ALB, listener HTTPS, listener rules, target groups, security groups, certificados ACM y un hostname por servicio.
• El equipo de plataforma crea el gateway y lo asocia a clústeres; el equipo de aplicación solo agrega un gateway connector al servicio, nombrando el puerto de la task definition.
• Cada servicio recibe una URL HTTPS con el formato https://<id-unico>.ecs.<region>.on.aws. Hasta 25 servicios comparten un mismo ALB con ruteo por host.
• Solo HTTPS en el puerto 443, solo modo de red awsvpc (EC2, Fargate y ECS Managed Instances), y el gateway y los clústeres tienen que estar en la misma cuenta.
• El gateway no tiene costo propio: pagás ALBs, IPs públicas, logs, métricas y transferencia de datos. El ahorro viene de tener muchos menos ALBs.
• Está disponible en todas las regiones comerciales donde está ECS, incluida sa-east-1.
• Trampa principal: update-gateway reemplaza la configuración completa. Lo que no mandes se borra o vuelve al valor por defecto.

Por qué ahora

El ingress en ECS siempre fue un trabajo repetido. Cada servicio nuevo que tenía que recibir tráfico HTTP necesitaba un target group, una regla en un listener, un certificado, un security group que solo aceptara tráfico desde el ALB y, muchas veces, un ALB propio. Con diez servicios es manejable. Con cien, tenés cien ALBs facturando por hora, cien IPs públicas por zona de disponibilidad y una cantidad de código de infraestructura que nadie quiere tocar.

Los equipos de plataforma resolvieron esto de distintas maneras: ALBs compartidos administrados a mano, módulos internos de Terraform o CDK, o directamente la decisión de que "todo pase por el mismo ALB y que plataforma agregue las reglas". Todas funcionan, pero todas tienen el mismo costo: alguien tiene que mantener la lógica de qué servicio va a qué ALB, qué pasa cuando un ALB se llena, cómo se limpian los recursos cuando un servicio se borra y cómo evitar que un equipo exponga a internet algo que debería ser interno.

ECS Gateway mete esa lógica dentro del servicio. La propuesta es clara: el equipo de plataforma decide las reglas del juego (red, WAF, logs, capacidad, qué es público y qué es interno) y los equipos de aplicación se enganchan sin necesitar conocimientos de redes. Es el mismo enfoque que AWS viene empujando con ECS Express Mode, pero pensado para servicios ECS estándar y con el equipo de plataforma a cargo de las decisiones.

Qué es y qué no es

ECS Gateway es una capa de automatización sobre Elastic Load Balancing que vive dentro de ECS. Los recursos que crea son ALBs, target groups y security groups comunes y corrientes, en tu cuenta, visibles en la consola de EC2. ECS los etiqueta con AmazonECSManaged=true y con el tag de sistema aws:ecs:gateway-arn; los target groups, las listener rules y los security groups de servicio llevan además aws:ecs:gateway-route-arn.

ECS Gateway no es:

• Un reemplazo de ECS Service Connect. Service Connect resuelve el tráfico entre servicios dentro de la malla; Gateway resuelve la entrada desde afuera (o desde la VPC) hacia tus servicios.
• Un API Gateway. No hay transformación de requests, cuotas por cliente, API keys ni autorizadores. Es ingress HTTP(S) con ruteo por host.
• Un balanceador de capa 4. Solo Application Load Balancer. Si necesitás TCP, UDP o gRPC sobre NLB, seguís con tu configuración actual.
• Algo que se repara solo. Si alguien modifica o borra a mano un recurso administrado, ECS no lo restaura. El tráfico puede cortarse y los deploys siguientes pueden fallar.

Un detalle que conviene tener presente desde el principio: la documentación no menciona dominios propios. Cada servicio recibe un hostname bajo on.aws. Si tus clientes tienen que entrar por api.tuempresa.com, revisá ese punto antes de planificar una migración.

Cómo funciona: gateway, asociación, connector y ruta

El modelo tiene cuatro piezas:

El flujo completo es este:

1. Plataforma crea el gateway. En este punto no se provisiona nada: no hay ALB ni costo.
2. Plataforma asocia el gateway a uno o más clústeres. La asociación no cambia el tráfico de ningún servicio por sí sola.
3. Un equipo agrega el connector a su servicio en CreateService o UpdateService.
4. En el deploy, ECS busca los gateways compatibles, ubica el servicio en un ALB con lugar (o crea uno nuevo) y crea los recursos por servicio: certificado ACM, hostname DNS, listener rule, target group y security group de servicio.
5. Cuando la ruta pasa a ACTIVE, la URL está lista para recibir tráfico.

Por cada gateway, los recursos compartidos son el ALB, el listener y el security group del balanceador. Por cada ruta, los recursos propios son el certificado, el hostname, la regla, el target group y el security group del servicio, que solo acepta tráfico desde el security group del ALB.

Cómo elige ECS a qué gateway conectar

Este es el punto que más conviene entender, porque define tu modelo de seguridad. El connector no elige un gateway por nombre ni por ARN. Se conecta a todos los gateways del clúster que cumplan tres condiciones:

1. Tipo de acceso. Un gateway internet-facing es PUBLIC y uno internal es PRIVATE. Si el connector tiene filtro accessTypes, el gateway tiene que coincidir; si no tiene filtro, acepta cualquiera.
2. Misma VPC que las subnets del servicio.
3. Cobertura de zonas de disponibilidad. Las subnets del gateway tienen que cubrir todas las AZ donde corre el servicio. La recomendación de AWS es usar el mismo conjunto de AZ para los gateways y los servicios de un clúster.

Si ningún gateway cumple las tres, la operación falla. Y si cumplen varios, el servicio queda conectado a todos (por ejemplo, a uno público y a uno interno a la vez).

La documentación lo marca como importante y vale la pena repetirlo: un servicio que nunca debería ser accesible desde internet tiene que filtrar por PRIVATE. Sin ese filtro, si en el futuro alguien asocia un gateway público al clúster, el servicio queda expuesto en su próximo deploy. No hace falta que nadie toque el servicio: alcanza con un redeploy cualquiera.

Qué pasa en cada deploy

ECS reevalúa las asociaciones en cada deployment. Si se asoció un gateway compatible nuevo, el servicio se conecta; si se desasoció uno, se eliminan sus rutas. Al borrar un servicio, ECS lo desconecta de todos los gateways, borra sus recursos y elimina cualquier ALB que haya quedado sin rutas.

Lo que no hace es consolidar: si tenías tres ALBs y la mitad de los servicios se fueron, pueden quedar ALBs a medio llenar. Los vacíos se eliminan; los parcialmente ocupados se quedan.

Capacidades que define el equipo de plataforma

La configuración del gateway se divide en dos grupos: lo que se fija al crearlo y lo que se puede cambiar después.

Inmutables (para cambiarlas hay que crear otro gateway y mover los servicios):

• Nombre (hasta 255 caracteres).
• Subnets, que definen la VPC y las AZ cubiertas. Por defecto usa las de la VPC default, algo que casi nunca vas a querer.
• Tipo de dirección IP: ipv4, dualstack (default) o dualstack-without-public-ipv4.
• Esquema: internet-facing (default) o internal.
• Listener: siempre HTTPS en el puerto 443.

Modificables:

Tres configuraciones merecen un comentario aparte:

Capacidad (maxAlbCount). Cada ALB aloja hasta 25 servicios, así que un gateway soporta 25 × maxAlbCount servicios: 250 con el default. Si un servicio intenta conectarse cuando no hay lugar, el deploy falla, y subir el límite después no reintenta ese deploy. Subilo antes de necesitarlo. El máximo es 200 ALBs por gateway.

Tráfico de prueba. Durante un deployment progresivo (blue/green o canary), los requests que traen el header configurado van a la revisión nueva y el resto sigue en la actual. Es solo por coincidencia de header, sin división por porcentaje, y el cambio del header llega a cada servicio en su próximo deploy. Para QA o smoke tests automatizados es justo lo que hace falta.

HTTP desync. La recomendación de la documentación es arrancar en monitor, prender access logs, revisar qué se marcaría y recién después pasar a strictest.

Capacidades del lado del servicio

Para el equipo de aplicación, la superficie es chica a propósito. El connector tiene tres campos:

• portName (obligatorio): el nombre de un puerto de la task definition. ECS toma de ahí el número, el protocolo y la versión de protocolo para configurar el target group. Si el nombre no coincide, el request falla.
• filters.accessTypes (opcional): PUBLIC, PRIVATE o ambos.
• healthCheck.healthCheckPath (opcional): por defecto el ALB pide / cada 30 segundos y espera un 200 en menos de 5 segundos.

Un servicio tiene como máximo un connector, aunque ese connector puede terminar conectado a varios gateways.

Hay una restricción con los health checks que te puede sorprender: cambiar el health check reemplaza el target group, y eso no se puede hacer con la estrategia de deployment ROLLING. El error es literal: Target group properties cannot be changed with ROLLING deployment strategy. O definís el health check bien desde el primer connect, o usás BLUE_GREEN o CANARY.

Manos a la obra

Vamos a armar el flujo completo con la AWS CLI: rol de infraestructura, un gateway público con access logs y tráfico de prueba, la asociación con el clúster, un servicio conectado y cómo obtener su URL. Necesitás una versión reciente de la AWS CLI v2 que ya incluya los comandos de gateway (aws ecs create-gateway help te lo confirma).

1. Rol de infraestructura

ECS necesita un rol para crear y administrar balanceadores, listeners, target groups, security groups y certificados. Se usa la política administrada AmazonECSInfrastructureRoleForGatewayHostSharedALB:

aws iam create-role \
  --role-name ecsInfrastructureRoleForGateways \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "ecs.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }]
  }'

aws iam attach-role-policy \
  --role-name ecsInfrastructureRoleForGateways \
  --policy-arn arn:aws:iam::aws:policy/AmazonECSInfrastructureRoleForGatewayHostSharedALB

Quien cree o actualice el gateway necesita iam:PassRole sobre ese rol. Si create-gateway falla con The infrastructureRoleArn could not be assumed..., es la consistencia eventual de IAM: esperá un minuto y reintentá.

2. Crear el gateway

Un gateway público en tres subnets, con capacidad para 500 servicios, access logs en S3, desync en modo monitor y un header para tráfico de prueba:

aws ecs create-gateway \
  --name plataforma-public \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForGateways \
  --configuration '{
    "hostSharedAlb": {
      "scheme": "internet-facing",
      "networkConfiguration": {
        "subnets": ["subnet-aaa111", "subnet-bbb222", "subnet-ccc333"],
        "ipAddressType": "dualstack"
      },
      "maxAlbCount": 20,
      "httpDesync": "monitor",
      "accessLogs": {
        "destination": { "s3": { "bucket": "mi-empresa-alb-logs", "prefix": "gateway" } }
      },
      "testTrafficRules": {
        "header": { "name": "x-test-traffic", "values": ["canary"] }
      }
    }
  }'

CreateGateway es sincrónico y devuelve "status": "ACTIVE". El bucket de logs tiene que estar en la misma región y su política tiene que permitir que Elastic Load Balancing escriba. Si querés un gateway interno para servicios privados, repetís el comando con "scheme": "internal" y subnets privadas.

3. Asociarlo al clúster

aws ecs associate-gateway-with-cluster \
  --gateway plataforma-public \
  --cluster produccion

aws ecs list-gateway-cluster-associations --gateway plataforma-public

Recordá: asociar no cambia el tráfico de nadie. Los servicios se enganchan en su próximo deploy, y solo si tienen connector.

4. Nombrar el puerto en la task definition

El connector referencia un puerto por nombre, así que el portMappings necesita name:

"containerDefinitions": [{
  "name": "api",
  "image": "123456789012.dkr.ecr.sa-east-1.amazonaws.com/api:1.4.2",
  "portMappings": [{
    "name": "web",
    "containerPort": 8080,
    "protocol": "tcp",
    "appProtocol": "http"
  }]
}]

La task definition tiene que usar "networkMode": "awsvpc".

5. Crear el servicio con el connector

aws ecs create-service \
  --cluster produccion \
  --service-name pagos-api \
  --task-definition pagos-api:7 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-priv1,subnet-priv2,subnet-priv3],securityGroups=[sg-0123abcd],assignPublicIp=DISABLED}' \
  --deployment-configuration '{"strategy": "BLUE_GREEN"}' \
  --gateway-connectors '[{
    "portName": "web",
    "filters": { "accessTypes": ["PUBLIC"] },
    "healthCheck": { "healthCheckPath": "/health" }
  }]'

Las subnets de las tareas tienen que estar en las mismas AZ que cubren las del gateway. Elegimos BLUE_GREEN para poder cambiar el health check más adelante y para aprovechar el header de tráfico de prueba.

Para un servicio que ya existe y ya tiene su propio load balancer, el camino es update-service con el mismo --gateway-connectors. Las dos vías de ingress quedan activas hasta que saques la configuración vieja, lo que permite una migración sin corte.

6. Obtener la URL del servicio

La URL vive en la revisión del servicio. Primero buscás el deployment, después la revisión destino:

DEPLOY_ARN=$(aws ecs list-service-deployments \
  --cluster produccion --service pagos-api \
  --query 'serviceDeployments[0].serviceDeploymentArn' --output text)

REV_ARN=$(aws ecs describe-service-deployments \
  --service-deployment-arns "$DEPLOY_ARN" \
  --query 'serviceDeployments[0].targetServiceRevision.arn' --output text)

aws ecs describe-service-revisions \
  --service-revision-arns "$REV_ARN" \
  --query 'serviceRevisions[0].ecsManagedResources.gatewayConnections'

Cada conexión devuelve serviceUrl, accessType y status. Esperá a que el estado sea ACTIVE antes de mandar tráfico. Si ves CREATE_FAILED, esperar no lo arregla: revisá el motivo.

curl -s https://<id-unico>.ecs.sa-east-1.on.aws/health

# Durante un deployment blue/green, este request va a la revisión nueva
curl -s -H "x-test-traffic: canary" https://<id-unico>.ecs.sa-east-1.on.aws/health

Para ver qué rutas tiene un gateway en un clúster:

aws ecs list-gateway-routes --gateway plataforma-public --cluster produccion

7. Alarmas por servicio

Como los recursos llevan tags de sistema, podés encontrar los target groups de un gateway sin conocer sus nombres y usarlos para alarmas de HTTPCode_Target_5XX_Count, TargetResponseTime o HealthyHostCount:

aws resourcegroupstaggingapi get-resources \
  --resource-type-filters elasticloadbalancing:targetgroup \
  --tag-filters Key=aws:ecs:gateway-arn,Values=arn:aws:ecs:sa-east-1:123456789012:gateway/plataforma-public/a1b2c3d4 \
  --query 'ResourceTagMappingList[].ResourceARN'

La dimensión TargetGroup te da las métricas de cada servicio y la dimensión LoadBalancer, el tráfico agregado del ALB compartido.

Trampas comunes

• update-gateway reemplaza todo. Si mandás solo maxAlbCount, el WAF se desasocia, los access logs se apagan, el header de prueba desaparece y deletionProtection vuelve a true. Corré siempre describe-gateway primero y armá la configuración completa. Si esto lo manejás desde un pipeline, mejor.
• Servicios internos sin filtro PRIVATE. Ya lo dijimos, pero es la trampa más cara.
• Subnets por defecto. Si no pasás subnets, el gateway usa la VPC default y no va a ser compatible con servicios en tu VPC real.
• Capacidad al límite. Un deploy que falla por falta de ALBs no se reintenta solo cuando subís maxAlbCount.
• Tocar recursos a mano. Nada de editar listener rules o security groups desde la consola de EC2 "para probar". ECS no los repara.
• Health check con ROLLING. Definilo bien desde el primer connect.
• Express Mode. Los servicios de ECS Express Mode no se pueden conectar a un gateway.
• IaC. La documentación indica soporte en CloudFormation, pero el provider de Terraform para AWS todavía tiene abierto el pedido de soporte (issue #50573, del 21 de octubre). Si tu plataforma es Terraform, por ahora vas a depender de la CLI o de CloudFormation para esta parte.

Precios

ECS Gateway no tiene cargo propio. Pagás los recursos que se crean en tu cuenta cuando los servicios se conectan:

Un ejemplo para dimensionar (cálculo propio, solo componentes fijos, 730 horas por mes, tres AZ, us-east-1). Treinta servicios con un ALB cada uno:

• 30 ALBs × USD 0,0225 × 730 h = USD 492,75 por mes.
• 30 ALBs × 3 IPv4 × USD 0,005 × 730 h = USD 328,50 por mes.
• Total fijo: unos USD 821 por mes.

Los mismos treinta servicios en un gateway entran en 2 ALBs:

• 2 ALBs × USD 0,0225 × 730 h = USD 32,85.
• 2 ALBs × 3 IPv4 × USD 0,005 × 730 h = USD 21,90.
• Total fijo: unos USD 55 por mes.

El costo variable (LCU) depende del tráfico y no desaparece: lo que antes se repartía en treinta ALBs ahora se suma en dos. Hay un detalle a favor y otro en contra. A favor, las LCU se cobran por la dimensión más alta, así que agrupar tráfico chico en un mismo ALB suele salir más barato que pagar el mínimo de muchos ALBs ociosos. En contra, las primeras 10 reglas de un listener son gratis y un ALB compartido con 25 servicios tiene más de 10, así que la dimensión de evaluaciones de reglas empieza a contar. Para la mayoría de las cargas no va a ser la dimensión dominante, pero conviene mirarlo en el Cost Explorer el primer mes.

Cómo bajar costos en la práctica:

• Usá dualstack-without-public-ipv4 en gateways públicos si tus clientes soportan IPv6: ahorrás las IPv4 públicas. Ojo que es inmutable, así que se decide al crear el gateway.
• Separá público e interno con criterio. Cada gateway tiene sus propios ALBs; no crees un gateway por equipo si no hay una razón de red o de seguridad.
• Vigilá los ALBs a medio llenar. Como no hay consolidación automática, después de una limpieza grande de servicios puede valer la pena revisar cuántos ALBs quedaron.
• Access logs con lifecycle en S3. Los logs de un ALB compartido crecen rápido; poné una regla de expiración o de transición desde el día uno.

Disponibilidad y lo que conviene mirar con lupa

ECS Gateway está disponible en todas las regiones comerciales donde está ECS. Eso incluye sa-east-1 (São Paulo), así que si tus cargas ya corren ahí, no hay que mover nada de región.

Algunas cosas a revisar desde Latinoamérica:

• Precios de São Paulo. El ALB y la transferencia de datos en sa-east-1 son más caros que en us-east-1. El ejemplo de arriba sirve para la proporción (muchos ALBs contra pocos), pero hacé la cuenta con la calculadora de AWS para tu región.
• Residencia de datos. Todo lo que crea el gateway vive en tu cuenta y en la región del gateway. No hay un plano de datos externo ni tráfico que salga de la región por usar Gateway.
• Transferencia entre AZ. El ALB distribuye entre zonas como siempre. Si tu servicio corre en tres AZ y el gateway cubre las tres, el comportamiento es el mismo que con un ALB propio.
• Dominios y certificados. Las URLs son *.ecs.<region>.on.aws con certificados que crea ECS. Si tenés requisitos de dominio propio, certificados privados o mTLS, la documentación actual no los cubre.
• Multi-cuenta. El gateway y los clústeres tienen que estar en la misma cuenta. Si tu modelo es una cuenta por equipo o por carga de trabajo, vas a necesitar un gateway por cuenta.
• Gobierno. Usá IAM para controlar quién puede ejecutar associate-gateway-with-cluster, porque esa acción define qué queda expuesto en el próximo deploy de cada servicio.

¿Vale la pena?

Para equipos que corren muchos servicios HTTP en ECS y hoy mantienen ALBs compartidos a mano o con módulos propios, sí. El ahorro en ALBs e IPs públicas es real a partir de unas decenas de servicios, y la división de responsabilidades (plataforma define, aplicación se engancha) es exactamente la que buscan los equipos de plataforma. También es una buena opción para proyectos nuevos con varios servicios, donde todavía no hay deuda de ingress.

Donde hay que ir con calma es en plataformas que ya tienen ruteo especializado: reglas por path, dominios propios, mTLS, NLBs o autenticación en el ALB con Cognito u OIDC. Nada de eso aparece en la documentación actual, y migrar para perder funcionalidades no tiene sentido.

Mi lectura: lo más interesante de ECS Gateway no es el ALB compartido (eso se podía hacer desde siempre) sino que AWS se hace cargo del ciclo de vida completo: crear, ubicar, escalar a más ALBs, limpiar. Es el mismo movimiento que en Kubernetes hizo el AWS Load Balancer Controller con los IngressGroups o que hoy empuja la Gateway API, con roles separados para quien define la infraestructura y quien publica rutas. Si venís de EKS, el modelo te va a resultar familiar (lo contamos en la guía de migración de Ingress NGINX a Gateway API). Lo que me preocupa es la combinación de "el connector se conecta a todos los gateways compatibles" con "asociar un gateway afecta el próximo deploy": es cómodo, pero convierte una acción de plataforma en un cambio de exposición de servicios ajenos. Yo arrancaría con una regla simple: todo connector lleva filtro accessTypes explícito, siempre, y el permiso de asociar gateways queda en pocas manos.

Mi sugerencia para probarlo: un clúster de staging, un gateway interno y uno público, dos o tres servicios no críticos migrados con update-service manteniendo el ALB viejo en paralelo. Medí durante una semana costo, latencia y comportamiento en deploys blue/green con el header de prueba, y recién ahí decidí.

Recursos

• Anuncio en What's New
• Post en AWS News Blog: Introducing Amazon ECS Gateway
• Documentación: ECS Gateway overview
• Documentación: crear y administrar un gateway
• Documentación: conectar servicios a un gateway
• Precios de Elastic Load Balancing
• Issue de soporte en el provider de Terraform para AWS
• Análisis de la comunidad en DEV: What changes for DevOps engineers