Si alguna vez publicaste un servicio en ECS, conocés la lista: un Application Load Balancer, un listener, un target group, un certificado en ACM, los security groups, quizás un web ACL de WAF, y que todo quede conectado. Ahora multiplicalo por cada servicio nuevo, y sumale mantenerlo sincronizado cuando algo cambia.
El 20 de octubre de 2026 AWS anunció Amazon ECS Gateway, y la idea es simple: esa lista la define el equipo de plataforma una sola vez, y cada servicio que se suma obtiene su entrada HTTPS sin que nadie toque un load balancer.
Si usaste Elastic Beanstalk, la sensación es familiar: vos decís qué querés, AWS crea y conecta los recursos en tu cuenta. Por eso me gusta pensarlo como un "Beanstalk" para el ingress de ECS.
El problema que viene a resolver
AWS lo plantea sin vueltas en el anuncio: configurar el networking de entrada de cada servicio "often becomes a bottleneck". Para cada servicio nuevo hay que provisionar y conectar ALBs, certificados, web ACLs y security groups, y mantenerlos alineados a medida que los servicios escalan o cambian. Según el blog oficial, ese trabajo por servicio frena la velocidad de despliegue y aumenta el riesgo de configuration drift (que la configuración real se aleje de la que pensás que tenés).
El síntoma típico: cada equipo de aplicación termina necesitando saber de redes, o depende de un ticket al equipo de plataforma para cada servicio que quiere exponer.
La analogía con Beanstalk
La documentación de Elastic Beanstalk lo describe así: vos construís y desplegás tu aplicación, y Beanstalk provisiona instancias EC2 o clusters EKS, configura el load balancing, el monitoreo de salud y escala tu entorno.
ECS Gateway toma solo una parte de esa promesa, la del tráfico de entrada, y la aplica a ECS:
| Elastic Beanstalk | ECS Gateway | |
|---|---|---|
| Qué declarás | Tu aplicación y su entorno | Una vez, la configuración de ingress |
| Qué crea AWS por vos | Cómputo, load balancing, monitoreo, escalado | ALB, listener, certificado, hostname, reglas, target group, security groups |
| Dónde viven los recursos | En tu cuenta | En tu cuenta |
| Costo extra del servicio | No tiene | No tiene |
Lo que no hace ECS Gateway: no corre tus tareas, no escala tu servicio, no maneja tu cómputo. Eso sigue siendo ECS como siempre. Gateway se ocupa exclusivamente de que el tráfico HTTPS llegue a tus servicios.
Los conceptos que entran en juego
Antes de ver cómo funciona, un repaso rápido de las piezas que ECS Gateway administra por vos. Si ya las conocés, saltá a la siguiente sección.
- Application Load Balancer (ALB): el punto de entrada que recibe las requests HTTP/HTTPS y las reparte entre tus tareas.
- Listener: el "oído" del ALB en un puerto y protocolo. En ECS Gateway es siempre HTTPS en el puerto 443.
- Listener rule y host-based routing: reglas que deciden a dónde va cada request. Con host-based routing la decisión se toma por el hostname al que apunta la request, y eso es lo que permite que muchos servicios compartan un mismo ALB.
- Target group: el grupo de tareas que recibe el tráfico de una regla, con sus health checks.
- Certificado de ACM: el certificado TLS que hace posible el HTTPS.
- Security groups: el firewall a nivel de recurso. Gateway crea uno para cada servicio que solo acepta tráfico que viene del ALB.
- AWS WAF web ACL: reglas de protección a nivel aplicación (filtrar requests maliciosas) que se asocian al ALB.
-
Modo de red
awsvpc: cada tarea de ECS tiene su propia interfaz de red en la VPC. Es requisito para usar Gateway.
Cómo funciona: dos equipos, tres pasos
Diagrama oficial de AWS. Abajo, el equipo de plataforma declara el ingress. Arriba, el equipo de aplicación hace opt-in con un connector. En el medio, la infraestructura que ECS crea y comparte.
La gran idea de ECS Gateway es separar responsabilidades:
- El equipo de plataforma crea el gateway y define los estándares una sola vez: si los servicios son públicos o solo internos de la VPC, qué subnets usan los load balancers, qué security group controla la entrada, qué web ACL de WAF aplica, a dónde van los access logs y cuánta capacidad de load balancers se permite.
- El equipo de aplicación solo marca su servicio como "quiero entrar por el gateway" (un gateway connector) e indica qué puerto del contenedor recibe el tráfico. Nada más.
En la práctica son tres pasos:
- Crear el gateway. El equipo de plataforma define la configuración de ingress.
- Asociarlo a clusters. Lo deja disponible para los servicios de uno o más clusters de ECS.
- Conectar servicios. Cada servicio hace opt-in al crearse o actualizarse.
Así se ve la creación desde la consola. Fijate que la decisión importante es el scheme: público (internet-facing) o interno.
Captura oficial: pantalla "Create gateway" en la consola de Amazon ECS.
Y así, la asociación con un cluster:
Captura oficial: el cluster con el gateway asociado, dentro de la pestaña Infrastructure.
El vocabulario nuevo: gateway, association, connector, route
La documentación define cuatro conceptos propios. Con estos cuatro entendés todo el modelo:
- Gateway: un recurso a nivel de cuenta (con su propio ARN) que guarda la configuración de ingress y administra la infraestructura de los servicios conectados.
- Gateway-cluster association: el vínculo entre un gateway y un cluster. Es de muchos a muchos: un gateway puede servir a hasta 10.000 clusters, y un cluster puede tener hasta 5 gateways (por ejemplo, uno público y uno privado).
- Gateway connector: el parámetro de opt-in en el servicio. Dice qué puerto exponer y, opcionalmente, si aceptás gateways públicos, privados o ambos, y cómo hacer el health check.
- Gateway route: la conexión concreta entre un servicio y un gateway. Tiene su propio estado y la URL del servicio.
Un detalle de diseño interesante: el servicio no elige el gateway por nombre. Se conecta a todos los gateways del cluster que sean compatibles: mismo VPC, mismo tipo de acceso (si filtraste) y que cubran todas las Availability Zones donde corre el servicio. Eso le da al equipo de plataforma el control de por dónde entra el tráfico, sin que cada equipo de aplicación tenga que conocer la topología.
Qué hace AWS por vos
Acá está la parte "Beanstalk". ECS Gateway divide la infraestructura en dos capas:
Infraestructura compartida (una por ALB, la comparten varios servicios):
- Application Load Balancer
- Listener
- Security group del load balancer
Infraestructura por servicio (una por cada gateway route):
- Certificado de ACM
- Hostname DNS propio, con la forma
https://<id-único>.ecs.<región>.on.aws - Listener rule
- Target group
- Security group del servicio
Y el ciclo de vida también lo maneja ECS:
- Nada se crea hasta que hace falta. Crear el gateway o asociarlo a un cluster no provisiona nada. El primer ALB aparece cuando se conecta el primer servicio.
- Hasta 25 servicios por ALB. Cuando uno se llena, ECS crea otro (hasta el máximo que configure plataforma; por defecto 10, o sea 250 servicios).
- Limpieza automática. Si borrás un servicio, se van su route y sus recursos. Cuando un ALB se queda sin servicios, ECS lo elimina.
Todo esto vive en tu cuenta, etiquetado con AmazonECSManaged=true y el ARN del gateway, así que lo podés ver en la consola de Elastic Load Balancing, EC2 o ACM como cualquier otro recurso.
Captura oficial: el detalle del gateway, con sus pestañas de routes, load balancers, métricas y clusters asociados. Fijate el "0 of 10 maximum": todavía no se conectó ningún servicio, así que no hay ALBs.
Por qué simplifica la gestión
Resumiendo lo que trae, según la documentación oficial:
1. Configuración centralizada. Plataforma define networking, seguridad y tráfico una vez, y todos los servicios conectados lo heredan, en todos los clusters. Un web ACL de WAF configurado en el gateway protege a todos los servicios detrás, sin que cada equipo lo configure.
2. Equipos de aplicación sin fricción. Obtienen su URL HTTPS sin crear recursos ni necesitar conocimiento de redes. Ni siquiera necesitan permisos para crear load balancers: esos permisos viven en un rol de infraestructura que ECS asume.
3. Menos costo por compartir. Hasta 25 servicios comparten un ALB en lugar de uno por servicio. ECS Gateway en sí no tiene costo adicional: pagás los recursos que se crean (ALB, logs y métricas de CloudWatch, certificados, transferencia de datos).
4. Infraestructura transparente. No es una caja negra: todo está en tu cuenta y lo inspeccionás con las herramientas de siempre.
5. Adopción gradual. Un servicio que ya tiene su propio ALB puede sumar el connector: ECS crea una route y un hostname nuevo sin tocar el load balancer existente. Los dos caminos sirven tráfico a la vez, validás el nuevo y después retirás el viejo.
6. Despliegues progresivos. Plataforma puede definir un header de "tráfico de prueba" en el gateway: durante un despliegue blue/green o canary, las requests con ese header llegan a la revisión nueva y el resto sigue en producción.
Cómo se monitorea
La documentación separa tres niveles de estado, y conviene tenerlos claros porque son independientes:
- Estado del gateway: si su configuración se aplicó bien.
- Estado de la route: si ECS terminó de provisionar el ingress de un servicio puntual.
- Salud de los targets: si tu aplicación responde a los health checks.
Un gateway puede estar ACTIVE aunque la route de un servicio haya fallado, y una route puede estar ACTIVE aunque la aplicación esté caída. Cada cosa se mira en su lugar.
Para tráfico y salud, ECS Gateway no publica métricas propias: usás las métricas del ALB en CloudWatch. Como un ALB lo comparten hasta 25 servicios, la recomendación es mirar tu servicio por la dimensión TargetGroup, no por LoadBalancer (si no, un pico de errores de otro servicio te puede confundir). Y como los ALBs aparecen y desaparecen, AWS sugiere armar alarmas y dashboards seleccionando recursos por el tag del gateway, no por un ARN fijo.
Lo que conviene saber antes
No todo es magia. Las limitaciones que marca la documentación:
- Solo HTTPS en el 443. Sirve para aplicaciones web y APIs direccionadas por hostname. Ningún otro protocolo.
-
Solo
awsvpc. Servicios en modobridge,hostononeno se pueden conectar. - Una sola cuenta. Gateway y clusters tienen que estar en la misma cuenta y región.
- No funciona con servicios de Express Mode.
- Decisiones que no se cambian. Nombre, scheme, subnets, puerto, protocolo y tipo de IP quedan fijos al crear el gateway. Para cambiarlos, gateway nuevo y migrar servicios. Las subnets son la decisión clave: definen qué VPC y qué AZs cubre, y por lo tanto qué servicios pueden usarlo.
- No consolida load balancers. Si se van servicios, pueden quedar varios ALBs parcialmente llenos; ECS no reacomoda.
- No repara cambios hechos a mano. Si modificás o borrás un recurso administrado por fuera de ECS, no lo restaura, y el tráfico puede cortarse. La regla: los cambios se hacen a través del gateway.
- La URL es aleatoria. No se deriva del nombre del servicio. Si borrás y recreás el servicio, cambia.
- Capacidad. Si todos los ALBs están llenos y el gateway llegó a su máximo, el despliegue del servicio nuevo falla. Plataforma tiene que subir ese máximo antes de necesitarlo.
Disponibilidad y precio
- Disponible en todas las regiones comerciales de AWS donde está ECS.
- Funciona con ECS sobre EC2, Fargate y ECS Managed Instances.
- Se gestiona desde la consola, la CLI, los SDKs y CloudFormation.
- Sin costo adicional por el gateway: pagás la infraestructura subyacente.
Para cerrar
ECS Gateway no inventa nada nuevo en términos de recursos: sigue siendo un ALB con reglas por hostname, certificados de ACM y security groups. Lo nuevo es quién los crea y quién los mantiene. Plataforma define el estándar una vez, cada equipo de aplicación se suma con un parámetro, y AWS se encarga del resto del ciclo de vida.
Como Beanstalk en su momento, la propuesta es sacarte de encima el trabajo repetitivo para que te concentres en tu aplicación. Solo que acá el foco está puesto en una única cosa: que el tráfico llegue.
¿Lo vas a probar en tu cluster o seguís con tu ALB armado a mano? Te leo en los comentarios.
Fuentes
- Introducing Amazon ECS Gateway (AWS News Blog)
- Amazon ECS Gateway (overview, docs)
- Create and manage an Amazon ECS Gateway
- Connect Amazon ECS services to a gateway
- Monitor a gateway
- Troubleshoot a gateway
- What is AWS Elastic Beanstalk?
Seguime en más plataformas
Este tema también está resumido en un carrusel en Instagram, ideal para guardarlo y compartirlo con tu equipo.
- Instagram: @dev.luchops
- YouTube: @dev.luchops
- TikTok: @dev.luchops
- Medium: @lucianonicolasloyola
- LinkedIn: Luciano Nicolas Loyola
━━━━━━━━━━━━━━━━━━━━
🟧 dev.luchops
Cloud & DevOps, explicado sin vueltas.
▸ Medium → medium.com/@lucianonicolasloyola
▸ YouTube → youtube.com/@dev.luchops
▸ TikTok / Instagram → @dev.luchops
━━━━━━━━━━━━━━━━━━━━
Top comments (0)