O exame AZ-700 avalia a capacidade de decidir qual serviço de balanceamento de carga pertence a qual camada de rede. O Azure Load Balancer opera em L4 e encaminha o tráfego com base em IP e porta. O Application Gateway opera em L7 e lê cabeçalhos HTTP, caminhos de URL e cookies antes de tomar decisões de roteamento. Os dois serviços têm propósitos distintos e são frequentemente implantados juntos.
Azure Load Balancer: A Esteira Classificadora dos Correios
Imagine a esteira de uma agência dos correios. Uma câmera lê o CEP de cada encomenda e a empurra para a calha da região correspondente — ninguém abre a caixa. O Azure Load Balancer funciona exatamente assim. Ele calcula um hash de cinco valores — IP de origem, porta de origem, IP de destino, porta de destino e protocolo (5-tuple hash) — e encaminha cada conexão para uma das VMs do Backend Pool.
Os quatro componentes são , , e . O IP de Frontend é o ponto de entrada: um IP público para um Public Load Balancer ou um IP privado na VNet para um Internal Load Balancer. Load Balancing Rules mapeiam uma porta de frontend para uma porta de backend. Os Health Probes verificam periodicamente cada VM e removem automaticamente as instâncias não saudáveis.
A escolha de SKU é Basic ou Standard. O Basic não suporta Availability Zones. O Standard suporta redundância de zona, Health Probes HTTPS e HA Ports — o padrão para produção. Sempre que um cenário mencionar alta disponibilidade ou Availability Zones, a resposta é Standard. HA Ports é exclusivo do Standard Internal Load Balancer: definir a porta como 0 faz uma regra cobrir todas as portas de 0 a 65535, ideal para NVA.
Application Gateway: O Balcão de Informações de um Shopping
Imagine o balcão de informações no piso térreo de um shopping. Um visitante diz 'estou procurando eletrônicos' e a atendente o direciona para o quinto andar; outra pessoa pergunta sobre alimentação e é enviada para o subsolo. A atendente escuta o que você diz. O Application Gateway funciona da mesma forma. Ele lê o cabeçalho Host do HTTP, o caminho da URL, a string de consulta e até os cookies antes de decidir qual Backend Pool receberá a solicitação.
O fluxo principal é . Um Basic Listener gerencia um único domínio; um Multi-site Listener distingue vários domínios no mesmo IP, roteando cada um para um Backend Pool diferente. As Routing Rules são Basic (todas as solicitações para um pool) ou Path-based ( para Pool A, para Pool B).
As opções de SKU são Standard_v2 e WAF_v2. O Standard_v2 suporta Autoscale e redundância de zona. O WAF_v2 adiciona Web Application Firewall com regras OWASP para bloquear SQL injection, XSS e outros ataques web. Quando o cenário exige defesa contra ataques web, WAF_v2 é a resposta.
Health Probe: O Porteiro do Hotel
O porteiro de um hotel verifica periodicamente se cada quarto está pronto e redireciona os clientes quando necessário. Os Health Probes do Application Gateway fazem o mesmo: enviam solicitações HTTP ou HTTPS periódicas a cada servidor do Backend Pool e verificam se a resposta tem um código no intervalo esperado (2xx ou 3xx). Se um servidor parar de responder, é removido do pool automaticamente.
Os Health Probes do Azure Load Balancer suportam TCP, HTTP e HTTPS, com intervalo padrão de 15 segundos e limite de dois falhas. Os Health Probes do Application Gateway permitem especificar o caminho e os códigos de resposta esperados. Em ambos os serviços, instâncias não saudáveis são excluídas do tráfego e reincorporadas automaticamente após recuperação.
SSL Termination e End-to-End TLS
Imagine uma transportadora que reembala pacotes para distribuição interna e os entrega ao destinatário em nova embalagem. O SSL Termination do Application Gateway funciona assim. O tráfego HTTPS é criptografado entre o cliente e o gateway; o gateway descriptografa e encaminha HTTP simples para as VMs do backend, reduzindo a carga de TLS nos servidores.
O End-to-End TLS vai além. Após descriptografar o HTTPS do cliente, o Application Gateway recriptografa e encaminha via HTTPS para os servidores backend. Isso é obrigatório quando as regulamentações exigem criptografia de todo o tráfego. Sempre que um cenário mencionar 'criptografia em todo o percurso', End-to-End TLS é a resposta. O Azure Load Balancer não pode terminar TLS — ele passa o tráfego da porta 443 diretamente para as VMs.
AGIC e Integração com AKS
Imagine um robô de armazém que lê um pedido e leva os itens para a zona correta da prateleira. O AGIC (Application Gateway Ingress Controller) faz o mesmo para o AKS (Azure Kubernetes Service). Quando os objetos Ingress do Kubernetes são anotados com as anotações do AGIC, o controlador cria e atualiza automaticamente Listeners, Routing Rules e Backend Pools no Application Gateway.
Os recursos de WAF e SSL Termination do Application Gateway se estendem ao Ingress do AKS sem a necessidade de um NGINX Ingress Controller separado. O Autoscale do Application Gateway responde automaticamente ao crescimento do tráfego. Se uma questão AZ-700 combinar AKS, WAF e Ingress, a resposta é AGIC com WAF_v2. A Cookie-based affinity emite um cookie de sessão para sempre enviar o mesmo cliente para o mesmo servidor backend — útil para aplicações legadas com estado local.
L4 vs L7: Critérios de Seleção
Pense na diferença entre uma cabine de pedágio e o controle de imigração de um aeroporto. A cabine de pedágio lê a placa e libera em segundos. O controle de imigração abre o passaporte e direciona para um portão. O Azure Load Balancer é a cabine de pedágio; o Application Gateway é o controle de imigração.
Escolher L4 (Load Balancer): qualquer protocolo TCP/UDP, sem inspeção HTTP, NVA front-end, distribuição interna entre VMs Escolher L7 (Application Gateway): roteamento por caminho URL, múltiplos domínios, WAF, SSL Termination, Ingress do AKS
As Outbound Rules controlam como as VMs usam SNAT em um Standard Public Load Balancer. Se a alocação de portas SNAT se esgotar, as Outbound Rules permitem aumentar o número — recurso exclusivo do Standard SKU. As NAT Rules mapeiam uma porta de frontend para a porta de uma VM específica, útil para acesso SSH.
!L4 vs L7: Load Balancer vs App Gateway
Padrões de Implantação e Armadilhas Comuns
Application Gateway (com WAF) gerencia o tráfego HTTP da internet enquanto um Internal Load Balancer distribui o tráfego entre VMs na VNet — duas camadas de distribuição trabalhando juntas. Essa combinação é comum em arquiteturas Azure de produção.
O erro mais comum é escolher o Azure Load Balancer para cenários externos que exigem roteamento por URL ou WAF. Lembre-se: HA Ports é exclusivo do Standard Internal Load Balancer e não existe no Public Load Balancer.
Resumo do Exame
'Todas as portas TCP/UDP, na frente de um NVA' -- Azure Load Balancer Standard + HA Ports 'Rotear por caminho URL para pools diferentes' -- Application Gateway Path-based Routing 'Vários domínios em um único IP' -- Application Gateway Multi-site Listener 'Bloquear injeção de SQL e XSS' -- Application Gateway WAF_v2 'AKS + Ingress + WAF' -- AGIC + WAF_v2 'Criptografia em todo o percurso' -- Application Gateway End-to-End TLS 'Reduzir a carga de TLS no backend' -- Application Gateway SSL Termination 'Sessões persistentes, mesmo cliente para o mesmo servidor' -- Cookie-based affinity 'Load Balancer com redundância de zona' -- Standard SKU 'Esgotamento de portas SNAT, controle de saída' -- Standard Load Balancer Outbound Rules 'Mapeamento direto de porta para uma VM específica' -- Load Balancer NAT Rules 'Regra única cobrindo todas as portas, NVA interno' -- HA Ports (apenas Standard Internal LB)
Azure Load Balancer = distribuição L4 por IP e porta, Application Gateway = roteamento de políticas L7 por conteúdo HTTP + WAF