ALB versus NLB versus GLB: quando usar cada um

O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada da aplicação entre vários destinos—instâncias do EC2, contêineres, funções do Lambda ou endereços IP. O ELB é um serviço gerenciado, o que significa que a AWS cuida do provisionamento, do dimensionamento e da disponibilidade do próprio balanceador de carga em várias AZs.

A AWS oferece três tipos de balanceadores de carga sob a categoria ELB: Application Load Balancer (ALB), Network Load Balancer (NLB) e Gateway Load Balancer (GWLB). Cada um opera em uma camada diferente do modelo OSI e é otimizado para casos de uso distintos.

O ALB opera na camada 7 (HTTP/HTTPS) do modelo OSI. Ele pode inspecionar cabeçalhos HTTP, caminhos, cadeias de consulta, nomes de host e cookies para tomar decisões inteligentes de roteamento. O ALB é a opção principal para aplicações Web, microsserviços e endpoints de API que precisam de roteamento baseado em conteúdo.

Principais recursos do ALB: roteamento baseado em caminho (/api/* para um grupo de destinos e /static/* para outro), roteamento baseado em host (hosts virtuais diferentes para backends diferentes), roteamento por cabeçalho HTTP e cadeia de consulta, suporte a WebSocket e suporte a HTTP/2. O ALB pode encaminhar tráfego para instâncias do EC2, contêineres (ECS/EKS), funções do Lambda e endereços IP.

O NLB opera na camada 4 (TCP/UDP/TLS). Ele encaminha pacotes com base nos dados do protocolo IP sem inspecionar o conteúdo da aplicação. O NLB foi projetado para desempenho extremo: processa milhões de solicitações por segundo com latência ultrabaixa (normalmente inferior a 100 microssegundos).

Principais recursos do NLB: endereços IP estáticos por AZ (um Elastic IP por sub-rede), passagem direta de TLS (encaminhamento do tráfego criptografado sem descriptografá-lo), preservação do endereço IP do cliente e suporte a protocolos UDP (por exemplo, DNS, RADIUS e servidores de jogos). O NLB não pode realizar roteamento baseado em conteúdo nem inspecionar cabeçalhos HTTP.

O GWLB opera na camada 3 (camada de rede) e foi projetado exclusivamente para implantar, dimensionar e gerenciar dispositivos de rede virtuais de terceiros—firewalls, sistemas de detecção e prevenção de intrusões (IDS/IPS) e sistemas de inspeção profunda de pacotes.

O GWLB usa o protocolo GENEVE (porta 6081) para encapsular o tráfego e enviá-lo à sua frota de dispositivos. O dispositivo inspeciona o pacote e o devolve pelo mesmo endpoint do GWLB. O tráfego flui de forma transparente, sem exigir alterações de roteamento na VPC de origem. Esse é o padrão para inserir inspeção de segurança centralizada nos fluxos de tráfego de VPC da AWS.

Escolha o ALB quando:

• Você precisar de roteamento baseado em conteúdo HTTP/HTTPS (caminho, host, cabeçalho, cadeia de consulta)
• Seu backend incluir funções do Lambda ou contêineres do ECS
• Você precisar de conexões WebSocket ou HTTP/2
• Quiser integrar o serviço ao AWS WAF para obter segurança de aplicações Web na camada do balanceador de carga
• Estiver criando uma arquitetura de microsserviços com muitos serviços em caminhos de URL diferentes
• Precisar de terminação de SSL/TLS no balanceador de carga

O ALB é a resposta correta para a maioria das questões do exame SAA-C03 sobre balanceamento de carga de aplicações Web e APIs REST.

Escolha o NLB quando:

• Você precisar de desempenho extremo (milhões de solicitações por segundo, latência inferior a um milissegundo)
• Precisar de endereços IP estáticos que parceiros ou firewalls possam autorizar em listas de permissões
• Precisar processar tráfego UDP (jogos, DNS, RADIUS, IoT)
• Quiser usar a passagem direta de TLS sem descriptografia no balanceador de carga (criptografia de ponta a ponta até o destino)
• Precisar preservar nativamente o IP de origem do cliente no nível do TCP
• Estiver usando o AWS PrivateLink para expor serviços a outras VPCs ou contas (o NLB é obrigatório para o PrivateLink)

Escolha o GWLB quando precisar:

• Inserir dispositivos de firewall de terceiros (Palo Alto, Fortinet, Check Point) no fluxo de tráfego da rede
• Realizar inspeção profunda de pacotes no nível da VPC para todo o tráfego de entrada ou saída
• Dimensionar horizontalmente uma frota de dispositivos IDS/IPS com balanceamento de carga automático

Arquitetura: o tráfego flui da VPC de origem → endpoint do GWLB → VPC dos dispositivos (onde o GWLB distribui o tráfego entre as instâncias dos dispositivos) → o dispositivo devolve o tráfego ao GWLB → o GWLB encaminha o tráfego ao destino original. A origem e o destino não percebem a inspeção intermediária.

O balanceamento de carga entre zonas distribui o tráfego uniformemente entre todos os destinos registrados em todas as AZs habilitadas, independentemente da AZ em que o nó do balanceador de carga recebeu a solicitação. Sem o balanceamento entre zonas, o nó de cada AZ distribui o tráfego apenas para os destinos na própria AZ.

O ALB tem o balanceamento entre zonas habilitado por padrão, sem custo adicional. O NLB tem o balanceamento entre zonas desabilitado por padrão—habilitá-lo gera cobranças pela transferência de dados entre AZs. O GWLB também tem o balanceamento entre zonas desabilitado por padrão. Habilite o balanceamento entre zonas quando a quantidade de destinos for desigual entre as AZs, para evitar pontos de concentração.

Tabela de comparação rápida para o exame:

• Camada OSI: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protocolos: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = todos os protocolos IP via GENEVE
• IP estático: ALB = Não (use o padrão NLB + ALB); NLB = Sim (1 por AZ); GWLB = Não aplicável
• Integração com WAF: ALB = Sim; NLB = Não; GWLB = Não
• Destino Lambda: ALB = Sim; NLB = Não; GWLB = Não
• Drenagem de conexões: os três oferecem atraso de desregistro

O ALB integra-se nativamente ao AWS WAF para proteção regional (diferentemente do WAF no CloudFront, que oferece proteção global na borda). Ao associar uma ACL da Web do WAF a um ALB, você pode filtrar solicitações HTTP antes que elas cheguem à sua aplicação—bloqueando injeção de SQL, XSS, IPs mal-intencionados conhecidos e clientes que abusam da taxa de solicitações.

Use ALB + WAF quando quiser realizar a inspeção de segurança na camada do balanceador de carga (por exemplo, para proteger APIs que não são servidas pelo CloudFront). As ACLs da Web do WAF associadas a ALBs devem estar na mesma Região que o ALB e ter o escopo REGIONAL (diferentemente do WAF do CloudFront, que exige o escopo CLOUDFRONT em us-east-1).

O AWS PrivateLink usa o NLB para expor serviços em uma VPC a consumidores em outras VPCs ou contas da AWS, sem exigir emparelhamento de VPCs, um gateway da Internet ou NAT. O provedor de serviços cria um NLB na frente do serviço e cria um serviço de endpoint da VPC. Os consumidores criam um endpoint de VPC de interface na própria VPC, apontando para o serviço.

O tráfego flui pela rede privada da AWS e nunca atravessa a Internet. O PrivateLink é o padrão para provedores de SaaS na AWS e para expor serviços compartilhados (por exemplo, um serviço de segurança centralizado) a várias contas internas da AWS.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: o ALB faz o roteamento na camada 7 (HTTP) com regras baseadas em conteúdo, integração com WAF e destinos Lambda; o NLB faz o roteamento na camada 4 (TCP/UDP) com IPs estáticos e taxa de transferência extrema; e o GWLB implanta dispositivos de rede virtuais na camada 3 usando GENEVE. Associe o balanceador de carga aos requisitos de protocolo e recursos. A seguir, exploraremos grupos de destinos e verificações de integridade.