Todavía no como reemplazo en bloque. ECS Gateway encaja en servicios que viven detrás de HTTPS en el puerto 443, con ruteo por host y hostname generado. Le pasa a ECS el ALB, los certificados y el DNS. Si tenés listeners propios o reglas de ALB afinadas, armá un piloto interno y compará facturas antes de apagar nada.
¿Qué es Amazon ECS Gateway?
Es una capa de ingress administrada para servicios de ECS, que AWS presentó como la forma de simplificar el networking de entrada de las aplicaciones en contenedores. ECS provisiona y opera por vos la infraestructura que lleva el tráfico a cada servicio. A medida que cada servicio se suma, ECS levanta el Application Load Balancer, los listeners, los target groups, los security groups, los certificados y los hostnames de DNS. La guía para desarrolladores de ECS documenta cómo funciona.
El modelo reparte la responsabilidad en dos. El equipo de plataforma crea el gateway, define su política de red, seguridad y operación, y lo asocia a uno o más clusters. La relación es de muchos a muchos: un gateway puede servir a varios clusters y un cluster puede usar varios gateways.
Después, el equipo de aplicación le agrega un gateway connector al servicio. El connector indica el puerto del contenedor que recibe tráfico y además puede fijar un filtro de tipo de acceso y health checks.
Crear el gateway no provisiona nada. ECS levanta el load balancer compartido recién cuando se conecta el primer servicio. A partir de ahí, por cada servicio conectado suma una listener rule, un target group, un certificado, un security group y un hostname. El ruteo entre servicios sobre el ALB compartido es por host, y cada uno recibe un hostname HTTPS generado bajo el dominio ecs.<region>.on.aws.
¿A quién le conviene reemplazar el ALB por ECS Gateway?
Al equipo que corre muchos servicios HTTPS chicos, cada uno con su ALB, sus reglas y sus certificados cableados a mano. Para ese equipo, el gateway saca la configuración repetida y centraliza la política: el web ACL de WAF, el security group de entrada, el destino de los access logs y la capacidad del load balancer. También define el header que identifica el tráfico de test durante los deploys progresivos, algo que importa si los usás en tu pipeline de release.
El encaje es más flojo si tu ingress usa otra cosa que HTTPS en el 443, porque el listener del gateway solo soporta ese protocolo y ese puerto. Si servís HTTP plano puertas adentro, necesitás otros puertos o dependés de reglas que miran algo más que el hostname, cotejá esos requisitos con la documentación antes de planear la mudanza.
El tráfico público con dominios propios necesita el mismo chequeo. La documentación describe un hostname generado por servicio, así que conviene resolver antes cómo se pararía un dominio propio delante de ese hostname.
Los permisos también cambian, y casi siempre para bien. Los permisos para crear load balancers están en un rol IAM de infraestructura que ECS asume, armado sobre una policy administrada de AWS para gateways con ALB compartido por host. El equipo de aplicación no necesita iam:PassRole ni acceso a la API del gateway para darle a su servicio un endpoint HTTPS. Solo el usuario o rol que crea o actualiza el gateway tiene que poder pasar ese rol.
¿ECS Gateway baja el costo de los load balancers?
Puede bajarlo, porque los servicios con la misma configuración de red comparten un único Application Load Balancer en lugar de tener uno cada uno. AWS presenta ese reparto como el beneficio de costo. El material de este análisis no trae precio del gateway ni precio unitario del ALB, así que el ahorro lo tenés que calcular con la página vigente de precios de Elastic Load Balancing y con tu propia factura.
La primera estimación es sencilla. Contá los ALB que hoy tenés delante de ECS, agrupalos por scheme, subnets y tipo de dirección IP, y fijate cuántos grupos quedan. Cada grupo equivale, más o menos, a un load balancer compartido del gateway. Si casi todos tus servicios ya están detrás de un solo ALB compartido, el argumento de costo es flaco y la decisión se apoya en la operación.
¿Qué riesgos tiene la migración a ECS Gateway?
El mayor riesgo es elegir mal los ajustes del gateway que después no se pueden cambiar. Nombre, subnets, tipo de dirección IP y scheme quedan fijos al crearlo. Cambiar uno implica crear un gateway nuevo, reconectar cada servicio y borrar el viejo.
Las subnets definen qué VPC y qué Availability Zones cubre el gateway, y un servicio solo se conecta a gateways que cubren donde corre. Por defecto el scheme es internet-facing, el direccionamiento es dualstack y las subnets son las de la VPC default, algo que puede no coincidir con tu red de producción.
El segundo riesgo es el drift con la infraestructura como código. ECS etiqueta todo lo que provisiona con AmazonECSManaged=true. Si alguien cambia o borra ese tag, ECS ya no puede actualizar ni limpiar el recurso. Un módulo de Terraform o CloudFormation que reescribe tags a lo bruto, o alguien que edita load balancers a mano, puede romper ese contrato sin que nadie se entere.
| Tema | Ingress con ALB armado a mano | ECS Gateway |
|---|---|---|
| Quién crea ALB, reglas, certificados y DNS | Tu equipo, servicio por servicio | ECS, a través de un rol de infraestructura |
| Protocolo y puerto del listener | Lo que configures | Solo HTTPS en el 443 |
| Ruteo a los servicios | Tus propias reglas | Por host, con hostname generado |
| Cambiar scheme o subnets | Editar o reemplazar el ALB | Gateway nuevo y reconectar servicios |
| Permisos del equipo de aplicación | Depende de tu esquema de IAM | Un connector en el servicio |
| Dónde viven los recursos | En tu AWS | En tu AWS, visibles en la consola y las APIs |
Hay dos detalles chicos que suelen trabar el primer intento. Un rol de infraestructura recién creado puede fallar en la primera llamada de creación porque IAM es eventualmente consistente, así que la automatización tiene que esperar alrededor de un minuto y reintentar. Una región sin VPC default necesita subnets explícitas al crear el gateway.
Qué revisar esta semana
Dedicale dos días al inventario. Listá cada ALB delante de ECS con sus listeners, puertos, protocolos, tipos de regla, dominios y WAF asociado. Señalá todo lo que no sea HTTPS en el 443 o que rutee por algo más que el host. Esos servicios se quedan en su ALB actual por ahora.
Dedicale un día al costo. Agrupá los servicios que quedan por scheme, subnets y tipo de dirección IP, y poné el resultado compartido al lado de las líneas de load balancer de la factura de hoy.
Los últimos dos días van al piloto, en un entorno que no sea producción. Creá el rol de infraestructura, creá un gateway internal con subnets explícitas y conectá un servicio de bajo riesgo. Revisá la gateway route, su estado, su URL y los recursos que provisionó ECS. Después corré tu pipeline de IaC y fijate cómo trata el próximo plan al tag AmazonECSManaged. Si el piloto aguanta y la agrupación muestra una consolidación real, dejá por escrito la decisión sobre los ajustes inmutables antes de que exista cualquier gateway de producción.
Fuentes
- docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-overview.html, consultada el 23 de octubre de 2026.
- docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-managing.html, consultada el 23 de octubre de 2026.