Pare de criar um Load Balancer para cada app: Como o ALB compartilhado salva seu orçamento na AWS

Se você abrir o console da AWS agora e encontrar 10 Application Load Balancers (ALB) rodando para dez microsserviços diferentes, você está perdendo dinheiro. É um erro clássico de arquitetura: a conveniência de isolar tudo em “silos” gerando uma linha de custo fixo que não para de crescer.

O ALB não foi desenhado para ser um recurso 1:1 (um balanceador para uma aplicação). Ele é um orquestrador inteligente capaz de gerenciar dezenas de domínios e serviços sob um único DNS e um único custo fixo.

O Vilão: O Custo Fixo de “Estar Ligado”

Cada ALB na AWS custa aproximadamente $16.20/mês, mais as Unidades de Capacidade de Carga (LCU). Para uma startup ou uma empresa com muitos ambientes de homologação, ter 20 ALBs significa gastar mais de $320 por mês antes mesmo do primeiro byte de tráfego passar pela rede.

A Solução: Host-Based Routing (Roteamento por Host)

A estratégia correta é usar as Listener Rules (Regras de Escuta) do ALB. Em vez de criar novos balanceadores, você adiciona regras que direcionam o tráfego com base no cabeçalho Host da requisição HTTP.

  • api.suaempresa.com.br -> Direciona para o Target Group A (ECS/Fargate)
  • app.suaempresa.com.br -> Direciona para o Target Group B (EC2)
  • admin.suaempresa.com.br -> Direciona para o Target Group C (Lambda)

O Gancho Técnico: Certificados SSL (SNI)

Muitos arquitetos hesitam em centralizar no ALB por medo do SSL. No entanto, o ALB suporta Server Name Indication, permitindo que você anexe múltiplos certificados do AWS Certificate Manager (ACM) ao mesmo Listener. O balanceador identifica qual domínio o usuário chamou e entrega o certificado correto automaticamente.

Quando NÃO compartilhar o ALB?

Nem tudo são flores. Existem três cenários onde você deve, sim, separar os balanceadores:

  1. Isolamento Crítico: Se uma aplicação consome tantas LCUs que pode causar throttling nas outras (raro, mas acontece em escala massiva).
  2. Segurança e Compliance: Se um ambiente exige WAF com regras extremamente restritas que quebrariam as outras aplicações.
  3. Diferentes VPCs: Um ALB só pode enviar tráfego para Target Groups dentro da mesma VPC (ou via VPC Peering/Transit Gateway, mas a complexidade aumenta).

Conclusão: Menos é Mais (e Mais Barato)

Centralizar suas aplicações em um ALB compartilhado não é apenas uma medida de economia , é uma questão de higiene de infraestrutura. Menos recursos para monitorar, menos certificados para gerenciar e uma fatura da AWS muito mais próxima da realidade do seu negócio.

Sua arquitetura está inflada ou otimizada? Se você tem mais de 5 ALBs na mesma VPC, é hora de revisar suas Listener Rules.

Quer uma solução personalizada para seu negócio?

Nossos especialistas em cloud computing analisam seu caso e criam uma estratégia sob medida.

Compartilhe essa publicação
Sobre o autor
Foto de Luan Sousa

Luan Sousa

Atuo como Cloud Architect na KXC Tecnologia, empresa parceira da AWS, trabalhando diretamente na construção, evolução e sustentação de ambientes em nuvem voltados para alta disponibilidade, segurança e eficiência operacional.

Tenho atuação prática no desenho de arquiteturas AWS, automação de infraestrutura e suporte a workloads em produção.

No dia a dia, participo da implementação e melhoria contínua de ambientes cloud, apoiando desde a definição arquitetural até troubleshooting de cenários críticos, análise de desempenho e otimização de recursos. Minha atuação envolve serviços essenciais do ecossistema AWS, integração entre aplicações e adoção de boas práticas que garantem ambientes mais resilientes e previsíveis.

Tenho forte foco em resolver problemas reais de operação, automatizar processos e simplificar a gestão de infraestrutura, sempre buscando equilibrar performance, custo e segurança dentro dos ambientes dos clientes.

Precisa evoluir ou modernizar seu ambiente AWS? Vamos conversar sobre como a nuvem pode gerar mais eficiência e segurança para o seu negócio.

Ver perfil e posts