Amazon ECS Gateway automatiza ALB, certificado e WAF para serviços no ECS

O Amazon ECS Gateway provisiona ALB, certificado ACM, security group e DNS para cada serviço automaticamente, tirando do time de plataforma o trabalho manual de configurar ingress um por um.

O Amazon ECS Gateway provisiona ALB, certificado ACM, security group e DNS para cada serviço automaticamente, tirando do time de plataforma o trabalho manual de configurar ingress um por um.

A AWS anunciou o Amazon ECS Gateway, um recurso de nível de conta que assume o trabalho de montar ingress para serviços do Amazon ECS. Até aqui, cada novo serviço exigia provisionar e manter sincronizados um Application Load Balancer (ALB), certificado no AWS Certificate Manager (ACM), web ACL do AWS WAF e security groups. Multiplicado por dezenas de serviços, isso vira trabalho manual repetitivo e abre espaço para drift de configuração entre ambientes.

O ECS Gateway ataca justamente esse gargalo operacional. Quem administra cluster ECS no dia a dia, seja no EC2, no Fargate ou nas ECS Managed Instances, conhece a rotina: criar ALB, apontar listener, gerar certificado, abrir security group, repetir para o próximo serviço. O gateway tira essa etapa manual de cima do time de plataforma e devolve só o essencial para quem sobe aplicação: um parâmetro na definição do serviço.

Separação de responsabilidades entre plataforma e aplicação

A ideia central do ECS Gateway é dividir o trabalho em duas camadas claras. O time de plataforma cria o gateway e define os padrões de rede da organização: subnets, security groups, certificados TLS, configuração de listener e web ACL do WAF, tudo num único lugar. Depois, associa esse gateway a um ou mais clusters ECS, tornando-o disponível para os serviços que rodam ali.

Já o time de aplicação só precisa adicionar um gateway connector na definição do serviço, seja no CreateService seja no UpdateService. A partir daí, o ECS provisiona sozinho tudo que o serviço precisa: certificado ACM, hostname DNS exclusivo, regras de listener, target group e um security group que só libera tráfego vindo do ALB. Não é preciso conhecimento de rede para subir um serviço com ingress funcionando.

Como fica na prática: criar o gateway e associar ao cluster

No console do ECS, criar um gateway pede um nome, uma infrastructure role (a IAM role que o ECS assume para provisionar ALB, security group e certificado na conta) e, opcionalmente, os clusters a associar. É possível escolher entre esquema público (internet-facing) ou roteamento interno de VPC, além de listener, porta, quantidade máxima de load balancers e web ACL de proteção.

Via AWS CLI, o fluxo passa por CreateGateway com nome, role e um objeto de configuração:

aws ecs create-gateway \
--name my-team-gateway \
--infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole \
--configuration '{
"HostSharedAlb": {
"networkConfiguration": {
"subnets": [
"subnet-080779f9bd887757a",
"subnet-03d5b2fead6bc6258",
"subnet-0861210a397d31252",
"subnet-06539e194023cb77a"
],
"ipAddressType": "ipv4"
},
"scheme": "internet-facing"
}
}'

Nenhuma infraestrutura é provisionada nesse momento: o ALB só nasce quando o primeiro serviço se conecta ao gateway. O passo seguinte é associar o gateway a um ou mais clusters com AssociateGatewayWithCluster:

aws ecs associate-gateway-with-cluster \
--gateway my-team-gateway \
--cluster arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster

Do lado da aplicação, basta incluir gateway-connectors na chamada de create-service, apontando a porta e os filtros de acesso (público ou interno), além do health check do serviço.

O que acontece por baixo do capô

No momento do deploy, o ECS avalia os gateways associados ao cluster e conecta o serviço a cada gateway compatível. Um gateway é compatível quando o tipo de acesso bate com o filtro do connector do serviço, ambos estão na mesma VPC e o gateway cobre todas as Availability Zones usadas pelas subnets configuradas no serviço. A AWS recomenda manter gateway e serviço com o mesmo conjunto de AZs justamente para evitar esse tipo de incompatibilidade silenciosa.

Para cada conexão, o ECS escolhe um ALB com capacidade disponível e provisiona os recursos por serviço: certificado ACM, hostname DNS exclusivo, regra de listener roteando para o target group do serviço e um security group liberando só o tráfego do ALB. Se nenhum ALB tiver capacidade, o ECS cria um novo, até o limite de maxAlbCount. Cada ALB compartilhado suporta até 25 serviços, o que ajuda a diluir custo de infraestrutura em organizações com muitos microsserviços pequenos.

O ciclo de vida é automático nos dois sentidos: em redeploys, o ECS reavalia as associações de gateway e conecta ou desconecta o serviço conforme a configuração atual do cluster; na exclusão do serviço, ele desfaz todas as rotas, limpa os recursos por serviço e, se aquele ALB ficou sem nenhuma rota, o remove também.

Migração incremental, sem big bang

Quem já tem serviço ECS com ALB próprio não precisa trocar tudo de uma vez. Dá para chamar UpdateService e adicionar um gateway connector mantendo o load balancer antigo ativo em paralelo, validar que o gateway está roteando certo e só depois remover a configuração antiga. Essa é a diferença prática entre testar em produção com rede de segurança e um corte seco que pode derrubar tráfego.

Limites que entram no planejamento de capacidade

Algumas configurações do gateway não podem ser alteradas depois de criadas: nome, esquema, VPC, subnets, tipo de endereço IP, protocolo e porta do listener. Vale desenhar isso com cuidado antes de rodar create-gateway em produção. Outros limites numéricos também pesam no desenho da arquitetura:

Se o maxAlbCount for atingido e nenhum ALB tiver capacidade, o deploy falha. Times que esperam conectar muitos serviços a um mesmo gateway precisam ajustar essa cota com antecedência, não depois do primeiro incidente de deploy travado.

Observabilidade: nada novo, mas nada automático além do ALB

Para monitorar, o ECS Gateway não inventa um novo pipeline de métricas: usa o que o ALB já expõe no CloudWatch. A dimensão TargetGroup serve para acompanhar tráfego por serviço, e LoadBalancer para o ALB compartilhado como um todo. Vale configurar alarmes em HealthyHostCount, TargetResponseTime e HTTPCode_Target_5XX_Count, usando tags baseadas no ARN do gateway para que o monitoramento escale junto com o maxAlbCount. Checagem de estado em tempo real continua via describe-target-health.

Quando vale a pena e quando não

ECS Gateway só funciona com serviços em modo de rede awsvpc, disponível nos três tipos de execução (EC2, Fargate e ECS Managed Instances). Serviço em modo bridge ou host fica de fora.

Faz sentido para quem já sofre com o padrão de "um ALB por serviço" espalhado em Terraform ou CloudFormation, com times de plataforma cansados de revisar pull request de rede toda vez que uma equipe sobe um serviço novo. Para quem opera dois ou três serviços estáveis com ingress simples, o ganho é menor, já que o gateway oferece roteamento por host via ALB compartilhado.

O recurso está disponível sem custo adicional em todas as regiões comerciais da AWS onde o ECS roda. A cobrança continua sendo pela infraestrutura provisionada: ALB, logs e métricas no CloudWatch, certificados ACM e transferência de dados, exatamente como seria numa configuração manual. A AWS também cita suporte via MCP Server para quem usa ferramentas de codificação com IA, o que facilita automatizar a criação de gateways e a consulta à documentação a partir do editor.

Fonte: AWS News Blog