Microsoft AZ-104: Balanceamento de Carga do Azure e Gerenciamento de Tráfego — Guia de estudos

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Visão Geral

O Azure oferece um portfólio em camadas para distribuir e proteger o tráfego: Azure Load Balancer (Camada 4, TCP/UDP), Application Gateway (Camada 7, HTTP/S), Azure Front Door (borda global de Camada 7), Azure Traffic Manager (baseado em DNS) e Azure CDN (cache de borda). Cada um visa um segmento específico do caminho da requisição — desde a tomada de decisão de DNS global e POPs de borda até o roteamento HTTP regional e o tráfego privado leste-oeste (east-west). A maestria vem da seleção do serviço certo para o protocolo e o público, compondo-os adequadamente e configurando sondas de integridade (health probes) e regras que impulsionam um failover confiável.

Azure Load Balancer (L4): SKUs, componentes, NAT/saída e IP flutuante

O Standard Load Balancer é o balanceador de carga L4 de nível de produção. Ele é ciente de zona/redundante entre zonas (zone-aware/zone-redundant), suporta HA Ports, diagnósticos/métricas avançadas, é seguro por padrão (sem tráfego de entrada a menos que você defina regras), possui regras de saída configuráveis e grande escala de backend. O Basic é um SKU legado com escala/recursos limitados e sem redundância de zona; ele está em processo de descontinuação e não deve ser escolhido para novas cargas de trabalho.

Os componentes principais definem como o tráfego flui:

Frontend IP: O VIP exposto aos clientes. LBs externos usam um Public IP ou Public IP Prefix; LBs internos usam um IP estático privado de uma sub-rede. O Standard suporta múltiplos frontends e IPs públicos com redundância de zona.
Backend pool: NICs, configurações de IP em NICs ou instâncias de VM scale set na mesma região/VNet. Um único pool pode atender a muitas regras. O Standard suporta backends entre zonas (cross-zone) dentro de uma região.
Health probes: Determinam quais instâncias do backend estão íntegras. Sondas TCP completam um handshake; sondas HTTP/HTTPS fazem um GET para um caminho e consideram 200–399 como sucesso. Você controla o protocolo, a porta, o caminho (para HTTP/S), o intervalo e o limite de não integridade (falhas consecutivas antes de marcar como inativo).
Load balancing rules: Vinculam um frontend (IP/porta/protocolo) a um backend pool e a uma health probe. As configurações da regra incluem porta do backend, protocolo (TCP/UDP), persistência de sessão, tempo limite de inatividade (idle timeout) e Floating IP (Direct Server Return).

As Inbound NAT rules são traduções por VM que encaminham uma porta de frontend específica para uma única NIC/porta de backend (por exemplo, para expor RDP ou SSH a uma VM sem balanceamento de carga). Elas não usam a health probe e não são um mecanismo de scale-out.

As Outbound rules definem o comportamento de SNAT para backends do Standard Load Balancer que iniciam conexões com a internet através dos frontends públicos do LB. Elas permitem que você controle qual(is) frontend(s) fornecem portas SNAT e quantas portas por instância de backend são alocadas, ajudando a evitar o esgotamento de portas SNAT sob alta concorrência de saída. Se um NAT Gateway estiver anexado à sub-rede, ele substitui o SNAT do LB; prefira o NAT Gateway para uma saída consistente e escalável.

O Floating IP (Direct Server Return) é uma opção de regra usada quando o IP/porta de destino deve ser preservado de ponta a ponta. É necessário para cenários em cluster, como os listeners de grupos de disponibilidade do SQL Server Always On. Para um SQL AG, use um Standard Load Balancer interno com uma sonda TCP (não HTTP) para a porta de sonda do cluster e habilite o Floating IP na regra do LB; não sonde a porta 1433 com HTTP, pois o SQL não é uma carga de trabalho HTTP.

A escolha entre balanceadores de carga internos e externos depende do público e da fronteira de segurança. Use um LB interno ao expor um VIP privado dentro de uma VNet ou via conectividade privada (VPN/ExpressRoute) para aplicativos de linha de negócios (line-of-business), bancos de dados e NVAs. Use um LB externo para serviços L4 voltados para a internet. Para LBs internos, atribua um frontend privado estático na sub-rede de destino; para LBs externos, vincule um Standard Public IP e, opcionalmente, use múltiplos frontends.

O Cross-region Load Balancer fornece balanceamento de carga global de Camada 4 com anycast entre regiões. Você implanta Standard Public Load Balancers em cada região (camada regional) e coloca seus frontends públicos no backend de um único Load Balancer global (camada global). O LB global usa health probes para cada LB regional e direciona os clientes para a região íntegra mais próxima (por latência) com simetria de fluxo baseada em hashing de 5 tuplas. Ele é apenas TCP/UDP — sem terminação TLS — e complementa os gateways L7 regionais.

Opções de design, integração entre regiões e comportamento da sonda de integridade

A escolha entre balanceadores de carga internos e externos é determinada pelo público e pela exposição da rota. Se os consumidores estiverem apenas em redes privadas, use LBs internos para evitar a exposição pública e simplificar o controle de NSGs. Para usuários da internet ou parceiros, use frontends públicos. Para conectividade de saída em escala, prefira o NAT Gateway em vez do SNAT do LB; reserve as regras de saída para casos em que o frontend do LB precise fornecer SNAT.

O Cross-region Load Balancer se integra com os Standard Public Load Balancers regionais para alcançar resiliência global ativa-ativa de Camada 4 para serviços TCP/UDP. Coloque os frontends públicos dos LBs regionais no pool de backend do LB global. As sondas de integridade na camada global refletem a disponibilidade regional; o roteamento direciona para a região íntegra de menor latência e faz o failover automaticamente se uma região inteira (ou seu LB regional) se tornar indisponível. Combine isso com o Front Door quando você precisar de suporte a ambos os protocolos (por exemplo, serviços TCP via Cross-region LB e HTTP/S via Front Door) sob VIPs separados.

As sondas de integridade são a fonte da verdade para o failover:

Sondas TCP: Funcionam para qualquer serviço TCP. Um handshake de três vias concluído marca o sucesso. Adequadas para SQL, SMTP ou protocolos TCP personalizados.
Sondas HTTP/HTTPS: Validam a integridade no nível da aplicação solicitando um caminho e esperando uma resposta 200–399. Elas permitem a personalização de host/caminho e podem discriminar falhas parciais da aplicação. As sondas HTTPS verificam a negociação TLS, mas não a validade do certificado além do handshake; use cabeçalhos de host corretos para aplicações hospedadas virtualmente.
Limiares de não integridade: O Azure Load Balancer marca um backend como indisponível após N falhas consecutivas da sonda (configurável; os intervalos padrão são curtos para acelerar o failover). O Application Gateway e o Front Door sondam de múltiplos pontos de observação e consideram uma origem como indisponível quando falhas consecutivas suficientes se acumulam em seu conjunto de sondas. A recuperação exige sucessos consecutivos. Ajuste o intervalo e o limiar para equilibrar a sensibilidade e o “flapping”; garanta que as sondas alcancem um endpoint leve e ciente de dependências.

Cenário de Problema Prático

A Adobe precisa expor globalmente um SaaS multirregional composto por front-ends web, microsserviços e um grupo de disponibilidade Always On do SQL Server, com segurança rigorosa, failover rápido e baixa latência para usuários em todo o mundo. Eles também expõem um serviço legado de ingestão de telemetria baseado em TCP.

Posicione o Azure Front Door Standard na borda com uma política de WAF e rotas para www.adobe.com e api.adobe.com. As origens são Application Gateways em East US e West Europe, agrupados com roteamento baseado em latência e failover por prioridade.

Por quê: O Front Door oferece anycast global, WAF na borda e cache opcional para acelerar e proteger o tráfego HTTP/S da internet; ele escolhe automaticamente a região íntegra mais próxima.

Implante um Application Gateway v2 com WAF em cada região. Configure listeners multi-site com SNI para ambos os hostnames, roteamento baseado em caminho de URL para os microsserviços e sondas de integridade personalizadas para /healthz em cada serviço. Habilite SSL de ponta a ponta com substituição do host de backend para os FQDNs do serviço.

Por quê: O Application Gateway oferece roteamento L7 regional, inspeção WAF próxima à aplicação, fanout baseado em caminho e políticas por rota; ele se conecta de forma segura a backends privados e lida com reescritas/redirecionamentos de cabeçalho.

Implante um Standard Load Balancer interno em cada região para o listener do AG do SQL. Configure um frontend privado estático, uma sonda de integridade TCP para a porta da sonda do Windows Failover Cluster e uma regra de balanceamento de carga com Floating IP habilitado para a porta do listener.

Por quê: O listener do SQL requer L4 com retorno direto do servidor. O Floating IP preserva a semântica de destino, e uma sonda TCP reflete com precisão a propriedade do AG. Isso espelha o requisito conhecido de que a sondagem HTTP na porta 1433 é inválida.

Apoie os ativos estáticos da web com regras de cache do Azure Front Door para /static/* com um TTL longo e revalidação, e também crie um perfil e um endpoint do Azure CDN para downloads de mídia grandes em downloads.adobe.com com cache específico por caminho e variação por query-string.

Por quê: O cache do Front Door reduz a latência para o conteúdo estático principal da web em linha com o roteamento de borda, enquanto um endpoint de CDN dedicado otimiza a entrega de objetos grandes e a independência da política de cache para downloads.

Publique a ingestão de telemetria TCP legada por meio de um Standard Public Load Balancer regional em cada região e, em seguida, coloque um Cross-region Load Balancer na frente deles como o único VIP público. Configure sondas globais para cada LB regional e use roteamento por latência.

Por quê: O serviço é TCP, não HTTP; o Cross-region Load Balancer oferece L4 global ativo-ativo com failover automático e seleção de região de baixa latência.

Adicione o Azure Traffic Manager com política de Prioridade apenas para um endpoint SFTP de parceiro externo hospedado fora do Azure, listando o endpoint principal do parceiro e um endpoint de backup hospedado no Azure.

Por quê: O Traffic Manager é baseado em DNS e pode incluir endpoints externos; ele oferece failover ativo/passivo simples para alvos não-HTTP e de terceiros onde o proxy não é desejado.

Para conectividade de saída das sub-redes da aplicação, anexe um NAT Gateway e remova a dependência do SNAT de saída do LB. Monitore os resultados das sondas e as métricas do LB/App Gateway/Front Door no Azure Monitor e ajuste os intervalos das sondas/limiares de não integridade para eliminar o “flapping”.

Por quê: O NAT Gateway escala a conectividade de saída de forma confiável sem esgotamento de portas SNAT; o ajuste preciso da sonda de integridade resulta em um comportamento de failover mais rápido e estável em todas as camadas.

← Rede Virtual do Azure · Todos os domínios · Armazenamento do Azure →

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