AWS ELB (ALB, NLB, GLB)

O Elastic Load Balancing é o serviço gerenciado de balanceamento da AWS, com três tipos de balanceador projetados para camadas distintas: o ALB atua na camada de aplicação, o NLB na camada de transporte e o GLB na camada de gateway. A relevância para produção é dupla: o serviço é gerenciado, sem nós para patchear nem par para dimensionar, e é nativamente distribuído em múltiplas zonas de disponibilidade, o que elimina boa parte dos problemas de alta disponibilidade que balanceadores auto-hospedados enfrentam. A escolha correta entre os três não é detalhe de implementação: ALB, NLB e GLB têm modelos de endereçamento, de cobrança, de performance e de integração diferentes, e a escolha errada gera custo desperdiçado, latência desnecessária ou limitação de funcionalidade. Em arquiteturas AWS maduras, os três coexistem em camadas distintas da rede, e o domínio de listener rules, target groups e health checks é o vocabulário básico de qualquer desenho de tráfego.

Os três tipos e suas camadas

O ALB, Application Load Balancer, opera na camada 7 e entende HTTP e HTTPS, com WebSocket e gRPC sobre HTTP/2 suportados. Ele termina o TLS, inspeciona a requisição e roteia por regras de listener: host, path, header, query string, método HTTP e origem. É o balanceador padrão para APIs, microsserviços e aplicações web, e é o único dos três que se integra a ações de autenticação no próprio balanceador, validando tokens OIDC e redirecionando antes de tocar o backend.

O NLB, Network Load Balancer, opera na camada 4 sobre TCP, UDP e TLS passthrough, com IP estático por zona e envelope de throughput na casa de milhões de requisições por segundo e latência de dezenas de microssegundos. Ele pode preservar o IP de origem do cliente até o destino, algo fundamental para quem precisa registrar auditoria por endereço real ou aplicar regra de firewall no destino. Fluxos ultra longos, de minutos a semanas, são suportados por design, e cada conexão é roteada por hash de fluxo, não por requisição.

O GLB, Gateway Load Balancer, é o mais recente e menos conhecido: opera na camada 3, no ponto de entrada e saída do tráfego da VPC, e encaminha pacotes de forma transparente para appliances virtuais de terceiros, como firewalls, sistemas de detecção de intrusão e inspecionadores de pacote. O padrão de uso é centralizar a inspeção de tráfego east-west e norte-sul em uma VPC dedicada, e o GLB usa encapsulamento GENEEVE para manter o fluxo transparente ao destino.

ALB em profundidade

A anatomia do ALB é listener, regra e target group, e essa estrutura é o modelo mental correto para qualquer desenho.

O listener escuta uma porta com um protocolo, tipicamente 443 com TLS, e carrega uma lista ordenada de regras. Cada regra tem prioridade, condição e ação, e a primeira regra que casa define o destino; se nenhuma casa, aplica-se a regra default. As ações possíveis vão além do encaminhamento: redirecionar de HTTP para HTTPS, responder fixo com código e corpo, autenticar via OIDC, e encaminhar com ponderação, o que viabiliza canary no próprio balanceador.

O target group é o pool de destinos com sua política de health check, e os destinos podem ser instâncias EC2, IPs, Lambda ou serviços ECS. É no target group que se define algoritmo, intervalo de verificação, thresholds e drenagem de conexões, e é por target group que se mede a saúde de cada rota.

A distribuição entre zonas é o ajuste fino que muitos esquecem: com cross-zone habilitado, o balanceador distribui igualmente entre todos os destinos saudáveis de todas as zonas, e desabilitado, cada nó do balanceador distribui apenas dentro da própria zona, o que desequilibra quando as zonas têm quantidades diferentes de destinos. Em ALB, o atributo vem habilitado por padrão, enquanto em NLB é desabilitado por padrão e precisa de decisão explícita, sempre com justificativa registrada, porque a habilitação implica custo de transferência entre zonas.

A cobrança também difere e afeta o desenho: o ALB cobra por hora mais unidades LCU, que medem conexões novas, conexões ativas, bytes processados e regras de listener avaliadas, enquanto o NLB cobra por hora e por NLCU, baseada em bytes e conexões novas. Regras de listener excessivas no ALB têm custo direto, e a revisão periódica de regras mortas é prática de FinOps legítima nessa camada.

# Listener e regras de um ALB declarados em CloudFormation (trecho)
Resources:
  ListenerApi:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref AlbApi
      Port: 443
      Protocol: HTTPS
      SslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06   # política TLS moderna
      Certificates:
        - CertificateArn: !Ref CertificadoAcm
      DefaultActions:
        - Type: fixed-response                          # respostas de rota desconhecida
          FixedResponseConfig:
            StatusCode: "404"
            ContentType: application/json
            MessageBody: '{"erro": "rota nao encontrada"}'

  RulePedidos:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      ListenerArn: !Ref ListenerApi
      Priority: 10
      Conditions:
        - Field: path-pattern
          PathPatternConfig:
            Values: ["/v1/pedidos/*"]
      Actions:
        - Type: forward
          ForwardConfig:
            TargetGroups:
              - TargetGroupArn: !Ref TgPedidosEstavel
                Weight: 95                              # canary no balanceador
              - TargetGroupArn: !Ref TgPedidosNovo
                Weight: 5

  TgPedidosEstavel:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      VpcId: !Ref VpcPrincipal
      Protocol: HTTP
      Port: 8080
      TargetType: instance
      HealthCheckPath: /healthz                         # sonda de aplicação real
      HealthCheckIntervalSeconds: 15
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 3
      HealthCheckTimeoutSeconds: 5
      DeregistrationDelay: 30                           # drenagem em segundos
      Matcher:
        HttpCode: "200"

NLB em profundidade

O NLB existe para dois cenários: performance extrema e requisitos de endereçamento. O IP estático por zona permite apontar registros A diretos, regras de firewall corporativas que exigem endereço fixo e integrações que não sabem resolver CNAME. O tráfego passa pelo NLB com latência de microssegundos, e a escala é elástica sem pré-provisionamento, absorvendo picos de conexão que derrubariam balanceadores por software.

A preservação do IP de origem tem consequências operacionais importantes. Como o destino vê o cliente real, o security group do destino precisa aceitar o range de IP do cliente, o que muda o desenho de rede; quando o NLB encadeia com instâncias em sub-rede sem IP público, a regra correta é permitir o CIDR da VPC ou usar target group com IP. A alternativa é desligar a preservação e trabalhar com proxy protocol v2, que carrega o endereço real no header do fluxo.

O health check do NLB é TCP por padrão, com opção HTTP e HTTPS quando o protocolo do listener é TLS. O check TCP tem o falso positivo clássico de porta aberta sem aplicação saudável, e a mitigação em arquitetura NLB é encadear com um ALB na frente do pool quando a verificação de aplicação é essencial, ou usar listener TLS com check HTTP.

O padrão composto NLB mais ALB é recorrente em produção madura: o NLB recebe na borda com IP estático e throughput extremo, e encaminha o TCP ao ALB como target, que aplica camada 7. Esse desenho entrega IP fixo, absorção de picos e inteligência de roteamento, ao custo de duas camadas de cobrança.

GLB e o padrão de inspeção centralizada

O GLB resolve um problema arquitetural que antes exigia reescrita de rotas manual: inserir appliances de segurança no caminho do tráfego sem que as aplicações saibam. A VPC de inspeção hospeda o GLB e o pool de appliances, e o target group aponta para instâncias de firewall virtual com health check. O endpoint do GLB publicado nas VPCs de aplicação captura o tráfego, encaminha ao appliance e devolve o pacote ao destino.

O caso de uso dominante é compliance em ambientes regulados: todo tráfego entre VPCs e para a internet passa pela inspeção, com logging centralizado e política de segurança uniforme. O custo aparece em duas camadas, processamento do appliance e throughput do GLB, e o desenho precisa dimensionar o pool para o pico, porque inspeção de pacote é operação cara por natureza.

Métricas e monitoramento do ELB

O ELB publica métricas no CloudWatch por balanceador e por target group, e o conjunto mínimo de um painel de produção cobre quatro grupos. A requisição e a resposta aparecem em RequestCount, HTTPCode_Target_2XX_Count e nas séries de 4XX e 5XX, onde o 5XX do target distingue falha da aplicação do 5XX do balanceador, que indica pool vazio ou limite atingido. A latência aparece em TargetResponseTime, medida do ponto de vista do balanceador, e o p99 real do usuário inclui a fila no balanceador, que não está nessa métrica.

A saúde dos destinos aparece em HealthyHostCount e UnhealthyHostCount por zona, e o alarme correto dispara na soma de insalubres acima de zero sustentado, e não apenas na média. Flutuação de conectividade aparece em ActiveConnectionCount para NLB e em NewConnectionCount para ALB, e picos anômalos de novas conexões são o sintoma típico de cliente mal configurado sem pool de conexões ou de reconnection em cascata.

Os access logs do balanceador, despejados em S3, são a fonte definitiva para investigação: cada requisição registra o destino escolhido, os tempos de processamento divididos por fase, o código de resposta e o trace id de erro do ELB, que o suporte da AWS usa para localizar o evento interno. Habilitar access log em produção com ciclo de vida no bucket é prática padrão, e o custo de armazenamento é irrisório perto do valor forense.

Health checks, drenagem e segurança

Os health checks são a espinha dorsal da disponibilidade do ELB, e os erros de configuração são recorrentes. O path escolhido deve exercer a aplicação sem depender de serviços opcionais, porque depender de dependência periférica derruba o target de um pool funcional. O intervalo e os thresholds definem o tempo de detecção: intervalo de 10 a 15 segundos com threshold de 2 a 3 falhas detecta indisponibilidade em menos de um minuto, enquanto intervalos longos deixam o cliente exposto ao erro real por mais tempo.

A drenagem de conexões, o deregistration delay, determina quanto tempo o ELB espera requisições em voo terminarem ao retirar um destino, e precisa ser calibrado com o graceful shutdown da aplicação: se a aplicação encerra em 20 segundos, o delay de 30 segundos funciona; se ela processa requisições de 2 minutos, o drain de 30 segundos interrompe trabalho. Fluxos longos em NLB exigem tratamento à parte, com drenagem no cliente e reconnection.

A segurança no ELB tem três eixos: política TLS atualizada e certificados no ACM, security groups que só aceitam tráfego do próprio balanceador nos destinos, e integração com AWS WAF disponível no ALB. O grupo de segurança do destino deve referenciar o grupo do balanceador como origem, e não o CIDR da VPC inteira, para garantir que o caminho obrigatório passe pelo balanceador.

Erros comuns e boas práticas

• Usar NLB onde é preciso rotear por path: NLB não lê HTTP, e tentativa de roteamento por aplicação dentro do destino desperdiça a camada; se existe path, é ALB.
• Health check de TCP em target de aplicação: porta aberta não garante serviço; use check HTTP quando o protocolo do listener permitir.
• Esquecer X-Forwarded-For: aplicações atrás de ALB veem o IP do balanceador; configure o header de encaminhamento e confie nele para rate limiting e auditoria.
• Cross-zone desligado sem propósito: sem distribuição entre zonas, uma zona pode concentrar tráfego; hoje o default é habilitado, e desligar exige justificativa.
• Deregistration delay incompatível com shutdown: medir o tempo real de graceful shutdown e alinhar o drain evita erro 502 em deploy.
• ALB público servindo tudo: expor apenas o necessário no ALB público e manter APIs internas em ALB privado reduz superfície de ataque e custo de WAF.

A boa prática de desenho é começar pelo requisito: roteamento por conteúdo e autenticação no edge apontam para ALB, IP estático e throughput extremo apontam para NLB, e inserção transparente de segurança aponta para GLB. Versione a configuração em IaC, teste as regras de listener em pipeline e trate os health checks como contrato entre plataforma e aplicação, porque é deles que depende a percepção de disponibilidade do sistema inteiro.