Microsoft AZ-700: Balanceamento de Carga e Gerenciamento de Tráfego — Guia de estudos

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Network Engineer AZ-700 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Serviços Essenciais de Balanceamento de Carga e de Borda do Azure

O Azure fornece várias camadas com propósitos específicos para distribuir tráfego: Azure Load Balancer (Camada 4), Application Gateway (Camada 7), Front Door (entrega e roteamento de borda global) e Traffic Manager (roteamento baseado em DNS). Escolha o Azure Load Balancer Standard para cenários de produção TCP/UDP leste-oeste e norte-sul onde alta vazão, redundância de zona e comportamento de SNAT previsível são necessários; o SKU Basic é limitado e não é recomendado para cargas de trabalho críticas. O Application Gateway v2 suporta escalonamento automático, redundância de zona, WAF (WAF_v2) e roteamento nativo baseado em URL e host para tráfego HTTP/S, enquanto a v1 não possui escalonamento automático e tem uma sobrecarga de planejamento de capacidade. O Front Door (Standard/Premium) fornece Anycast global, terminação TLS na borda, failover rápido e um motor de regras para modificação de cabeçalhos e caminhos; o Premium adiciona WAF avançado e suporte a origens privadas. O Traffic Manager é baseado em DNS e útil para geo-roteamento, failover e distribuição ponderada, mas não pode fornecer terminação TLS, nem pode atuar como um proxy reverso HTTP. Ao combinar serviços, envie ativos estáticos para uma CDN e use o Front Door para roteamento global e o Application Gateway para políticas regionais de L7 e acesso a back-ends privados. Considere estas comparações de SKU ao selecionar componentes:

Azure Load Balancer: Basic vs Standard (escolha o Standard para produção: com redundância de zona, seguro por padrão).
Application Gateway: v1 vs v2 (v2 para escalonamento automático, atualizações de WAF mais rápidas).
Front Door: Standard vs Premium (Premium para WAF avançado e link privado para as origens).

Sondas de Integridade, Regras de Reescrita e Comportamento do Web Application Firewall

Sondas de integridade (health probes) e controles de WAF são centrais para operações resilientes na Camada 7. Configure as sondas de integridade com endpoints realistas que exercitem todo o caminho da requisição (incluindo cabeçalhos de autenticação, se necessário) e correspondam ao comportamento do back-end; defina o intervalo da sonda e os limites de falha (unhealthy thresholds) para equilibrar a velocidade de detecção com os falsos positivos. As sondas de integridade do Application Gateway podem substituir o cabeçalho do host e sondar um caminho específico; garanta que as configurações HTTP do back-end (afinidade baseada em cookies, drenagem de conexão, tempos limite de inatividade) correspondam às necessidades da aplicação. Regras de reescrita existem nos motores de regras tanto do Application Gateway quanto do Front Door e devem ser usadas para normalizar cabeçalhos, remover ou inserir prefixos, ou realizar reescrita de URL para o roteamento do back-end, mas lembre-se de que as reescritas podem quebrar heurísticas de cache e URLs assinadas. As políticas de WAF diferem por plataforma: o WAF do Application Gateway protege back-ends regionais com regras gerenciadas pela OWASP e exclusões personalizadas, enquanto o WAF do Front Door Premium protege na borda e suporta políticas globais, proteção contra bots e limitação de taxa avançada. Armadilhas comuns incluem sondar uma página de integridade estática que passa enquanto os endpoints da aplicação estão falhando, esquecer de permitir os intervalos de IP da sonda nos NSGs e configurar incorretamente os cabeçalhos de host para que os back-ends rejeitem as requisições da sonda.

Gerenciamento de Tráfego Global: Front Door, Traffic Manager e CDN

O Front Door e o Traffic Manager abordam a distribuição global, mas operam de maneiras diferentes. O Front Door funciona como um proxy HTTP/S global e stateful com terminação TLS na borda, roteamento inteligente (latência, prioridade e aceleração dinâmica de site), uma camada de cache de CDN integrada e um motor de regras para manipulação de cabeçalho/caminho. O Traffic Manager é um seletor baseado em DNS para endpoints que usa métodos de roteamento como prioridade, ponderado, desempenho e geográfico; ele se destaca para failover simples e roteamento de conformidade, mas não pode descarregar o TLS ou realizar reescritas na camada de aplicação. A Azure CDN (opções Standard Microsoft, Standard Verizon, Premium Verizon/Akamai) é otimizada para conteúdo estático e armazenável em cache e pode ser precedida pelo Front Door ou usada de forma independente; escolha a CDN Premium para motores de regras complexos, origin shield e opções avançadas de SSL. Para roteamento multi-site, use listeners baseados em host no Application Gateway para segregação regional e o Front Door para servir como front-end multi-site entre regiões com domínios personalizados. Esteja ciente de que o cache de DNS afeta a velocidade de failover do Traffic Manager, o Front Door fornece failover rápido na borda e a configuração de origem da CDN deve estar alinhada com as estratégias de purge e TTL para evitar conteúdo obsoleto. Para cenários de origem privada, o Front Door Premium suporta o Private Link para proteger as origens; caso contrário, considere o Application Gateway em um hub regional.

Trade-offs de Design, Armadilhas Operacionais e Monitoramento

As decisões de design ponderam desempenho, custo e resiliência. Priorize o Front Door ou a CDN para entrega global e menor latência para o cliente, o Application Gateway para controles de política L7 avançados perto do backend e o Azure Load Balancer Standard para throughput bruto de TCP/UDP e escalabilidade previsível. As compensações de custo incluem o Front Door Premium/WAF e o autoescalonamento do Application Gateway v2 versus alternativas v1 de menor custo e escalonamento manual; equilibre o custo consolidando o roteamento global na borda, mantendo gateways regionais para inspeção de tráfego privado. As armadilhas operacionais incluem o esgotamento de portas SNAT quando muitos backends iniciam conexões de saída a partir de um pequeno conjunto de endereços NAT — use o NAT Gateway ou ajuste as configurações de SNAT e evite o tráfego em “hairpin” através do mesmo NAT. Outro problema comum é esquecer de abrir os IPs de sonda nos NSGs ou configurar incorretamente domínios personalizados e certificados para o Front Door e o App Gateway. Para monitoramento, habilite logs de diagnóstico e métricas para cada serviço (Load Balancer, App Gateway, Front Door, CDN), envie para o Log Analytics e use o Traffic Analytics e o Connection Monitor do Network Watcher para visibilidade no nível do fluxo. Configure alertas sobre falhas de sonda, anomalias de throughput do backend e detecções do WAF, e teste o failover com tráfego controlado para validar runbooks e procedimentos de reversão.

Problema Prático: Cenário de Caso de Uso

Cenário: A Contoso Manufacturing opera um ambiente Azure multirregional com dois hubs regionais (EastUS e WestEurope), instâncias regionais do Application Gateway v2, um par de pools de aplicativos em VM-scale e uma CDN existente para ativos estáticos. Eles precisam apresentar um único endpoint global com WAF de borda e failover rápido, preservando a inspeção regional privada.

Desafio: Fornecer um endpoint HTTPS global com WAF de borda, failover rápido entre regiões e a capacidade de rotear o tráfego para backends regionais do Application Gateway (que são privados) sem expor as origens publicamente.

Abordagem Recomendada:

Implante o Azure Front Door Premium como o ponto de entrada global (SKU: Front Door Premium) com terminação TLS, habilite a política de WAF do Front Door (regras personalizadas + OWASP) e configure um pool de backend para cada região apontando para o IP público de um Application Gateway v2 regional com o Private Link habilitado para conectividade segura com a origem.
Configure a origem do Front Door como um Private Link para o frontend regional do Application Gateway e defina as sondas de saúde para um endpoint de saúde protegido que o Application Gateway expõe; defina intervalos de sonda baixos (ex: 10s) e um limiar agressivo de ‘unhealthy’ (ex: 3) para um failover rápido.
Mantenha o Application Gateway v2 em cada região para roteamento L7, reescrita de URL e regras de WAF locais adaptadas às políticas regionais; habilite o autoescalonamento e os logs de diagnóstico para o Log Analytics.
Use a Azure CDN (Standard Microsoft) para ativos estáticos armazenáveis em cache, com o Front Door à frente para controle otimizado de TTL e ‘purge’; implemente monitoramento e alertas sobre falhas de sonda do Front Door e taxas de bloqueio do WAF.

Justificativa: O Front Door Premium fornece WAF de borda e failover global rápido, enquanto o Private Link protege os gateways regionais como origens; o Application Gateway v2 regional permite controles L7 granulares e inspeção sem expor as VMs de backend, equilibrando desempenho, segurança e resiliência.

← Segurança de Rede · Todos os domínios · Monitoramento e Solução de Problemas de Rede →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →