ECS Gateway: automatizar o ingress não elimina planejamento de capacidade

A AWS anunciou o Amazon ECS Gateway para provisionar e manter a infraestrutura de entrada de serviços ECS dentro da conta do cliente.[8] O recurso coordena componentes como ALBs, certificados, regras de roteamento e security groups, permitindo que até 25 serviços compartilhem um ALB.[8] A utilidade está em padronizar a entrada dos serviços, não em tornar essa infraestrutura gratuita.

O que muda para quem desenvolve

A divisão apresentada coloca gateways, rede, certificados, listeners e políticas sob responsabilidade da equipe de plataforma; a aplicação adiciona um conector ao serviço.[8] O primeiro ALB só é criado quando um serviço se conecta, e novos balanceadores são provisionados conforme a capacidade.[8]

Para a arquitetura, isso sugere separar o contrato de exposição da implementação de cada aplicação. Minha recomendação é definir quais serviços podem ser públicos, quais devem ser internos e quem pode modificar essas associações antes de oferecer o conector como conveniência.

O serviço exige modo de rede awsvpc e atende EC2, Fargate e ECS Managed Instances.[8] As zonas utilizadas pelo serviço precisam estar cobertas pelo gateway.[8] Portanto, a automação não deve ocultar dependências de rede na revisão do deploy.

Como aplicar

Escolha inicialmente um serviço não crítico e documente a configuração atual de entrada. Registre hostname, política de acesso, verificações de saúde, latência e erros antes de testar a nova associação.

A adoção gradual em serviços existentes pode manter temporariamente o ingresso antigo enquanto o gateway é validado.[8] Use essa possibilidade para comparar o comportamento e definir critérios de retirada do caminho anterior. Teste acesso esperado, rejeição de tráfego indevido e um novo deploy, sem considerar suficiente a primeira resposta HTTP bem-sucedida.

Faça uma projeção de custo que inclua os recursos compartilhados e a observabilidade. Compare também o esforço de manter regras e certificados manualmente. Só então decida se a redução de repetição compensa a mudança de operação.

Cuidados e limites

Nome, esquema público ou interno, VPC, sub-redes, tipo de IP e protocolo e porta do listener estão entre as propriedades que não podem ser alteradas após a criação do gateway.[8] Escolhas desse tipo precisam de revisão antes do provisionamento, não depois de conectar várias aplicações.

A quota padrão de maxAlbCount é 10; quando ela é atingida e não há ALB com capacidade, o deploy falha.[8] Configure alertas e um procedimento de capacidade em vez de presumir crescimento ilimitado.

Não há cobrança adicional pelo gateway em si, mas os recursos subjacentes aplicáveis continuam cobrados, incluindo balanceadores, certificados, logs, métricas e transferência de dados.[8] A análise correta é custo total e previsibilidade operacional. Um recurso gerenciado reduz tarefas; não transfere para o provedor a responsabilidade de entender sua aplicação.

Fonte

[8] Fonte: AWS News Blog