Resumo

Imagine um restaurante com uma única fila de espera e várias mesas atendendo. Se todo cliente for direcionado sempre para a mesma mesa, ela lota enquanto as outras ficam vazias — e se aquela mesa "quebrar" (o garçom passar mal), ninguém mais é atendido. Elastic Load Balancing (ELB) é o "maître" que distribui os clientes (requisições) entre as mesas disponíveis (instâncias/targets saudáveis), redirecionando automaticamente para longe de quem está indisponível.

• ALB (Application Load Balancer): opera na camada de aplicação (HTTP/HTTPS), entende URLs, headers, cookies — ideal para aplicações web.
• NLB (Network Load Balancer): opera na camada de transporte (TCP/UDP), altíssima performance, preserva o IP de origem, suporta IP estático.
• Gateway Load Balancer (GWLB): opera na camada de rede (IP), usado para inserir appliances de terceiros (firewalls, IDS/IPS) de forma transparente no caminho do tráfego.
• Classic Load Balancer (CLB): geração legada, cobre HTTP e TCP básico — evite em novos projetos.

---

1. Anatomia de um Load Balancer: listener, regra e target group

Antes de comparar os tipos, entenda as três peças que todo load balancer da AWS usa:

• Listener: "escuta" uma porta e protocolo específicos (ex: porta 443, HTTPS). É o ponto de entrada do tráfego.
• Regra (rule): dentro de um listener, decide para onde mandar o tráfego, com base em condições (ex: se o path começa com /api, mande para o target group X).
• Target Group: o conjunto de destinos reais (instâncias EC2, IPs, containers, funções Lambda) que recebem o tráfego roteado. É o target group que tem o health check configurado — não o load balancer diretamente.

Cliente → Listener (porta 443) → Regra (path/host) → Target Group → Targets (EC2/IP/Lambda)

---

2. ALB — Application Load Balancer

Opera na camada 7 (aplicação): entende o conteúdo da requisição HTTP/HTTPS — path, host, headers, método, cookies. Isso permite:

• Path-based routing: /api/* vai para um target group, /imagens/* vai para outro — mesmo domínio, backends diferentes.
• Host-based routing: loja.site.com vai para um target group, blog.site.com vai para outro, no mesmo ALB.
• Suporte nativo a WebSockets e HTTP/2.
• Integração com AWS WAF (Web Application Firewall) — proteção contra ataques comuns na camada de aplicação (SQL injection, XSS) é possível apenas em ALB (e CloudFront/API Gateway), não em NLB.

Tipos de target suportados pelo ALB: instância EC2, endereço IP (dentro ou fora da VPC, via peering/VPN), e função Lambda — permitindo expor uma Lambda por trás de um ALB com URL amigável e regras de roteamento HTTP, sem precisar de API Gateway.

---

3. NLB — Network Load Balancer

Opera na camada 4 (transporte): lida com TCP/UDP puro, sem entender o conteúdo da aplicação. Por isso:

• Consegue lidar com volumes altíssimos de conexões, com latência mínima — usado quando performance bruta é o requisito principal.
• Preserva o IP de origem do cliente por padrão até o target — útil quando a aplicação precisa saber o IP real de quem conectou (auditoria, regras de firewall internas), sem depender de headers como X-Forwarded-For.
• Suporta Elastic IP estático por AZ — diferente do ALB, que sempre tem um DNS com IP variável. Isso importa quando um sistema legado ou uma regra de firewall de terceiros exige uma lista fixa de IPs para whitelisting.
• Também suporta terminação TLS (é um mito comum achar que NLB só faz TCP puro sem TLS) — ele pode terminar TLS na camada 4, útil quando você quer performance de NLB mas ainda precisa descarregar a criptografia antes do target.

💡 Regra para a prova: precisa de IP estático para whitelisting de firewall de terceiros → NLB. precisa preservar IP de origem sem configurar nada extra → NLB. precisa de roteamento por URL/host → ALB.

---

4. Gateway Load Balancer (GWLB)

Opera na camada 3/4 com um propósito diferente dos outros dois: não é para distribuir tráfego entre réplicas da sua aplicação, mas para inserir appliances de segurança de terceiros (firewalls de próxima geração, sistemas de detecção/prevenção de intrusão) de forma transparente no meio do caminho do tráfego, sem que a aplicação precise saber que esse appliance existe.

Usa o protocolo GENEVE na porta 6081 para encapsular o tráfego original e enviá-lo à frota de appliances, que inspeciona e devolve o tráfego para seguir seu caminho normal.

💡 Para a prova: se o cenário menciona "inspecionar todo tráfego através de um firewall de terceiros de forma transparente e escalável", pense em Gateway Load Balancer — não em ALB/NLB.

---

5. Tabela comparativa

---

6. Health checks — o que decide quem recebe tráfego

O target group monitora a saúde de cada target periodicamente (ex: fazendo GET /health a cada N segundos). Parâmetros principais:

• Interval: de quanto em quanto tempo o check é feito.
• Healthy threshold: quantas respostas de sucesso seguidas são necessárias para considerar o target saudável (voltar a receber tráfego).
• Unhealthy threshold: quantas falhas seguidas são necessárias para tirar o target de circulação.
• Timeout: quanto tempo esperar por uma resposta antes de considerar falha.

Um target considerado "unhealthy" para de receber novo tráfego imediatamente, mas conexões já em andamento não são cortadas abruptamente — ver seção seguinte.

---

7. Deregistration delay (connection draining)

Quando um target é removido do target group (por health check falho, por scale-in do ASG, ou remoção manual), o load balancer não corta as conexões já em andamento na hora. Ele entra num período de deregistration delay (padrão: 300 segundos, configurável): para de mandar tráfego novo para aquele target, mas espera as requisições já em curso terminarem (até o limite do delay) antes de finalizar a remoção.

Isso evita que um usuário no meio de uma operação tenha a conexão cortada abruptamente só porque a instância está sendo substituída (ex: durante um scale-in do ASG ou um deploy).

---

8. TLS e segurança

• Terminação TLS no ALB (ou NLB) é o padrão mais comum: o certificado fica no load balancer (gerenciado via ACM — AWS Certificate Manager, com renovação automática), e o tráfego entre o load balancer e os targets pode seguir em HTTP simples dentro da rede privada — reduzindo overhead de criptografia em cada instância.
• Alternativa: TLS passthrough/end-to-end, onde a criptografia só é decifrada no target final — usado quando há requisito de compliance exigindo que o tráfego nunca trafegue em texto claro em nenhum ponto, nem dentro da VPC.
• AWS WAF se conecta ao ALB (não ao NLB) para filtrar requisições maliciosas na borda, antes de chegarem à aplicação.

---

9. Sticky sessions e cross-zone load balancing

9.1 Sticky sessions

Mantêm um cliente sempre roteado para o mesmo target, via cookie. Útil quando a aplicação guarda estado de sessão em memória local — mas é uma solução de curto prazo: o ideal arquitetural é externalizar o estado (ex: Redis, DynamoDB) para que qualquer target possa atender qualquer cliente, permitindo escalar e substituir instâncias livremente sem depender de afinidade.

9.2 Cross-zone load balancing

Distribui tráfego igualmente entre todos os targets de todas as AZs habilitadas, em vez de balancear apenas entre os targets da AZ que recebeu a conexão.

⚠️ Detalhe que a prova gosta de cobrar: o comportamento padrão é diferente entre ALB e NLB. No ALB, cross-zone load balancing vem habilitado por padrão e sem custo extra. No NLB, vem desabilitado por padrão, e quando habilitado manualmente, pode gerar custo de transferência de dados entre AZs.

Sem cross-zone habilitado, se uma AZ tem poucos targets e outra tem muitos, a distribuição de carga por target pode ficar desbalanceada (cada AZ recebe a mesma fatia de conexões, independente de quantos targets ela tem dentro).

---

9.3 Slow Start

Quando um target novo é registrado (ex: uma instância recém-lançada pelo ASG), ele pode ser imediatamente inundado com sua fatia total de tráfego, mesmo ainda "esquentando" (JIT warm-up, cache local vazio, conexões de banco sendo abertas). O Slow Start faz o ALB aumentar gradualmente a quantidade de tráfego enviada a um target recém-registrado, ao longo de uma janela configurável, em vez de mandar a carga completa de uma vez — reduzindo o risco de o target novo ficar sobrecarregado logo no início e falhar health checks por sobrecarga, não por estar de fato indisponível.

💡 Diferente do deregistration delay (que trata da saída de um target), Slow Start trata da entrada de um target novo no grupo.

---

9.4 Security Groups no NLB

Por muito tempo, uma diferença marcante entre ALB e NLB era que o NLB não suportava Security Group diretamente (por operar na camada de transporte, sem terminar conexões da mesma forma que o ALB). Isso mudou: hoje o NLB suporta Security Groups associados diretamente a ele, simplificando o controle de tráfego de entrada sem depender só das regras dos Security Groups dos targets.

⚠️ Se você encontrar material mais antigo dizendo que "NLB não suporta Security Group", saiba que isso está desatualizado — vale conferir a documentação oficial para o comportamento mais recente.

---

10. Boas práticas

• Use health checks alinhados com o comportamento real da aplicação (endpoint de readiness, não apenas "porta aberta").
• Configure múltiplas AZs para distribuição de targets e tolerância a falhas de zona.
• Para serviços sensíveis a IP de origem ou que exigem IP estático, prefira NLB.
• Prefira estado externo (cache/banco compartilhado) a sticky sessions sempre que possível.
• Ajuste o deregistration delay considerando a duração típica das requisições da aplicação — muito curto pode cortar requisições legítimas, muito longo atrasa deploys/scale-in.

---

11. Como cai na certificação

• Cenário "roteamento por URL/path ou por domínio" → ALB.
• Cenário "altíssima performance TCP/UDP, preservar IP de origem" → NLB.
• Cenário "IP estático para whitelisting de firewall de parceiro" → NLB (Elastic IP por AZ).
• Cenário "inserir firewall de terceiros de forma transparente e escalável" → Gateway Load Balancer.
• Cenário "proteção contra SQL injection/XSS na borda" → WAF + ALB.
• Cenário "aplicação Lambda exposta via load balancer com roteamento HTTP" → ALB com target Lambda.
• Cenário "instância removida no meio de requisições em andamento, sem cortar abruptamente" → deregistration delay (connection draining).
• Cenário "distribuição desigual entre AZs com número diferente de targets" → avaliar cross-zone load balancing (lembrando: padrão difere entre ALB e NLB).

---

12. Exercícios e revisão

1. Escolha entre ALB e NLB para uma API de baixa latência que precisa manter IP de origem para auditoria. Justifique.
2. Explique como o ALB realiza roteamento por host e por path, com um exemplo de regra.
3. Descreva um cenário onde Gateway Load Balancer é a escolha certa e nem ALB nem NLB resolveriam.
4. Explique a diferença de comportamento padrão de cross-zone load balancing entre ALB e NLB, e o impacto de custo.
5. Um deploy está cortando requisições de usuários no meio de uma operação longa durante o scale-in do ASG. Qual configuração do target group ajudaria e como você ajustaria o valor?

---

13. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Laboratório Prático

Objetivo: criar um ALB com roteamento por path para dois target groups diferentes, e observar o deregistration delay em ação.

Pré-requisitos: uma VPC com subnets públicas em pelo menos 2 AZs; duas instâncias EC2 (ou dois grupos) simulando serviços diferentes (ex: uma respondendo em /app1, outra em /app2).

Tempo estimado: 25 minutos

Possíveis custos: ALB cobra por hora e por LCU (unidade de capacidade) — custo baixo para teste rápido, lembre-se de deletar ao final.

Passos:

1. Crie dois Target Groups, cada um apontando para uma instância/serviço diferente, com health check em /health.
2. Crie um Application Load Balancer em subnets públicas de pelo menos 2 AZs.
3. Configure um Listener HTTP na porta 80, com duas regras: path /app1/* → target group 1, path /app2/* → target group 2.
4. Acesse o DNS do ALB em /app1/... e depois /app2/..., confirmando que cada rota chega ao backend correto.
5. Configure o deregistration delay de um dos target groups para 120 segundos.
6. Inicie uma requisição de longa duração (ex: um endpoint que demora alguns segundos para responder) e, durante a requisição, remova manualmente aquela instância do target group — observe que a requisição em andamento consegue terminar antes da remoção efetiva, respeitando o delay configurado.

Resultado esperado: tráfego roteado corretamente por path, e confirmação visual de que o deregistration delay evita corte abrupto de conexões ativas.

Limpeza dos recursos: delete o Load Balancer, os Target Groups, e termine as instâncias de teste.

---

Referências:

• Elastic Load Balancing: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
• Application Load Balancer: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
• Network Load Balancer: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
• Gateway Load Balancer: https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html