Ainda não como troca em bloco. O ECS Gateway encaixa em serviços que vivem atrás de HTTPS na porta 443, com roteamento por host e hostname gerado. Ele passa para o ECS o trabalho de ALB, certificado e DNS. Se você tem listeners próprios ou regras de ALB afinadas, pilote um serviço interno e compare a conta primeiro.
O que é o Amazon ECS Gateway?
O Amazon ECS Gateway é uma camada de ingress gerenciada que cria e opera a infraestrutura de load balancing dos serviços ECS. Conforme cada serviço adere, o ECS provisiona o Application Load Balancer, os listeners, os target groups, os security groups, os certificados e os hostnames de DNS. O guia do desenvolvedor do ECS descreve o funcionamento.
O modelo divide a responsabilidade em dois times. O time de plataforma cria o gateway, define a política de rede, segurança e operação e associa o gateway a um ou mais clusters. A associação é muitos para muitos. Um gateway pode atender vários clusters, e um cluster pode usar vários gateways.
O time de aplicação, por sua vez, adiciona um gateway connector ao serviço. O connector indica a porta do container que recebe o tráfego. Ele também pode definir um filtro de tipo de acesso e health checks.
Criar o gateway não provisiona nada. O ECS só monta o load balancer compartilhado quando o primeiro serviço conecta. Depois disso, para cada serviço conectado, ele cria regra de listener, target group, certificado, security group e hostname. O roteamento no ALB compartilhado é por host, e cada serviço ganha um hostname HTTPS gerado sob o domínio ecs.<region>.on.aws.
Vale a pena trocar o ALB pelo ECS Gateway?
Vale mais para quem roda muitos serviços HTTPS pequenos, cada um com ALB, regras e certificados montados na mão. Para esse time, o gateway elimina configuração repetida e centraliza a política. Isso inclui o web ACL do WAF, o security group de entrada, o destino dos access logs e a capacidade do load balancer. O gateway também define o header que marca tráfego de teste em deploys progressivos, o que pesa se o seu pipeline de release usa esse recurso.
O encaixe piora quando o ingress depende de algo além de HTTPS na porta 443. O listener do gateway aceita só esse protocolo e essa porta. Um time que serve HTTP puro internamente, precisa de outras portas ou roteia por critérios além do hostname deve cruzar esses requisitos com a documentação antes de planejar a mudança.
Tráfego público em domínio próprio da marca pede a mesma checagem. A documentação fala em hostname gerado por serviço, então vale desenhar como um domínio customizado ficaria na frente dele.
As permissões também mudam, e quase sempre para melhor. O direito de criar load balancer fica numa role de infraestrutura que o ECS assume, com uma policy gerenciada pela AWS para gateways com ALB compartilhado por host. O time de aplicação não precisa de iam:PassRole nem de acesso à API do gateway para ter um endpoint HTTPS. Só quem cria ou atualiza o gateway precisa poder passar essa role.
O ECS Gateway reduz o custo com load balancer?
Pode reduzir, porque serviços com a mesma configuração de rede dividem um único Application Load Balancer em vez de cada um ter o seu. A AWS cita esse compartilhamento como o ganho de custo. O material desta análise não traz preço do gateway nem preço unitário de ALB. Faça a conta com a página atual de preços do Elastic Load Balancing e com a sua fatura.
A primeira estimativa é simples. Conte os ALBs que hoje ficam na frente do ECS. Agrupe por scheme, subnets e tipo de endereço IP e veja quantos grupos sobram. Cada grupo equivale, grosso modo, a um load balancer compartilhado do gateway. Se a maioria dos serviços já está atrás de um ALB compartilhado, o argumento de custo é fraco e a decisão passa a depender da operação.
Quais são os riscos de migrar para o ECS Gateway?
O maior risco é escolher configurações do gateway que não podem ser alteradas depois. Nome, subnets, tipo de endereço IP e scheme ficam fixos na criação. Para mudar um deles, você cria um gateway novo, reconecta todos os serviços e apaga o antigo.
As subnets definem qual VPC e quais Availability Zones o gateway cobre. Um serviço só conecta a gateways que cobrem o lugar onde ele roda. Os defaults são scheme internet-facing, endereçamento dualstack e as subnets da VPC padrão. Isso pode não bater com a sua rede de produção.
O segundo risco é drift com infraestrutura como código. O ECS marca tudo o que cria com a tag AmazonECSManaged=true. Se essa tag for alterada ou removida, o ECS perde a capacidade de atualizar ou limpar o recurso. Módulos de Terraform ou CloudFormation que reescrevem tags em massa podem quebrar esse contrato sem ninguém perceber. Quem edita ou apaga essa tag à mão no console corre o mesmo risco.
| Ponto | Ingress com ALB feito na mão | ECS Gateway |
|---|---|---|
| Quem cria ALB, regras, certificados e DNS | Seu time, serviço por serviço | O ECS, por meio de uma role de infraestrutura |
| Protocolo e porta do listener | O que você configurar | Só HTTPS na 443 |
| Roteamento até os serviços | Regras próprias | Por host, com hostname gerado |
| Mudar scheme ou subnets | Editar ou trocar o ALB | Gateway novo e reconexão dos serviços |
| Permissão do time de aplicação | Depende do seu IAM | Um connector no serviço |
| Onde ficam os recursos | Na sua conta | Na sua conta, visíveis no console e nas APIs |
Dois detalhes costumam travar a primeira tentativa. Uma role de infraestrutura recém-criada pode falhar na primeira chamada de criação, porque o IAM tem consistência eventual. A automação deve esperar cerca de um minuto e tentar de novo. Em Region sem VPC padrão, você precisa informar as subnets ao criar o gateway.
O que verificar esta semana
Reserve dois dias para o inventário. Liste cada ALB na frente do ECS com listeners, portas, protocolos, tipos de regra, domínios e WAF associado. Marque tudo o que não for HTTPS na 443 ou que roteie por mais do que o host. Esses serviços ficam no ALB atual por enquanto.
Use um dia para o custo. Agrupe os serviços restantes por scheme, subnets e tipo de endereço IP. Depois compare o resultado compartilhado com as linhas de load balancer da fatura atual.
Nos dois últimos dias, rode um piloto numa conta fora de produção. Crie a role de infraestrutura, crie um gateway internal com subnets explícitas e conecte um serviço de baixo risco. Confira a rota do gateway, o status, a URL e os recursos que o ECS criou. Em seguida rode o pipeline de IaC e veja como o próximo plan trata a tag AmazonECSManaged. Se o piloto se sustentar e o agrupamento mostrar consolidação real, registre as configurações imutáveis como decisão escrita antes de existir qualquer gateway de produção.
Fontes
- docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-overview.html, consultada em 23 de outubro de 2026.
- docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-managing.html, consultada em 23 de outubro de 2026.