Microsoft AZ-700: Azure Virtual WAN e Hub-Spoke — 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.

Virtual WAN versus hub-and-spoke clássico: escolha o modelo de trânsito correto

Projetar o trânsito global exige a escolha entre a Azure Virtual WAN (vWAN) e um hub-and-spoke tradicional construído com VNets, NVAs e emparelhamento. A Virtual WAN fornece um backbone global gerenciado pela Microsoft com vHubs que hospedam nativamente conectividade de VPN, ExpressRoute e P2S e suportam propagação de rotas automatizada, escalabilidade site-to-site e integrações com parceiros de SD‑WAN. Para organizações que precisam de muitas conexões de filiais, roteamento global e um modelo operacional simples, a vWAN reduz o trabalho de orquestração e melhora a resiliência. Em contraste, um hub-and-spoke manual (uma VNet com um Azure Firewall ou NVA de terceiros em um hub central e spokes emparelhados) oferece controle máximo sobre o fluxo de pacotes, recursos de NVA personalizados e, frequentemente, um custo contínuo menor para implantações pequenas. As principais vantagens e desvantagens são vazão e previsibilidade versus controle granular: os hubs da vWAN abstraem muitos detalhes e oferecem escala quase global, mas adicionam custos de serviço gerenciado e uma personalização menos flexível do caminho dos pacotes. Armadilhas comuns incluem presumir que a vWAN fornece automaticamente emparelhamento transitivo para VNets não conectadas explicitamente; cada spoke ou VNet deve ser conectado e associado às tabelas de rotas do hub. Outro erro frequente é negligenciar as restrições de governança e de nomenclatura de sub-redes (por exemplo, a AzureFirewallSubnet exigida para o Azure Firewall) que quebram implantações automatizadas se não forem seguidas.

Hub virtual seguro, Azure Firewall e integração de NVA

O modelo de hub virtual seguro adiciona camadas de inspeção e política à vWAN, integrando o Azure Firewall (ou um NVA de terceiros) e o Firewall Manager para centralizar a segurança, o NAT e o roteamento para os spokes e sites on-prem. O Azure Firewall deve ser implantado na sub-rede dedicada AzureFirewallSubnet e você deve decidir entre os SKUs do Azure Firewall com base nos recursos. Planeje as tabelas de rotas com cuidado: as tabelas de rotas do hub controlam os fluxos para os spokes, sites VPN, P2S e a internet. Para forçar o tunelamento do tráfego para um NVA, você associa a conexão do spoke a uma tabela de rotas do hub que direciona 0.0.0.0/0 para o NVA/Firewall. Considere alta disponibilidade e vazão: o Azure Firewall é zonal e suporta autoescalonamento com os SKUs Standard e Premium, mas o Premium é necessário para inspeção de TLS e IDPS. Evite colocar endpoints do Application Gateway ou Private Link em sub-redes compartilhadas com a infraestrutura do firewall; eles precisam de suas próprias sub-redes. Fique atento ao esgotamento de portas NAT e SNAT para fluxos de saída em grande escala; implemente pool de SNAT, Azure Firewall com regras de DNAT ou use o NAT Gateway quando aplicável.

Azure Firewall Standard vs. Premium: O Standard suporta firewall stateful, filtragem de FQDN, SNAT/DNAT básico; o Premium adiciona inspeção de TLS, IDPS, filtragem de URL e exclusões de tags de nome de domínio totalmente qualificado (FQDN).
Load Balancer Basic vs. Standard: O Standard suporta redundância de zona, investigações de integridade do backend e é necessário para o ILB do serviço Private Link; o Basic não possui resiliência de zona e tem regras de segurança mais rígidas.
SKUs do VPN Gateway: VpnGw1/2/3 (aumentando a vazão e os túneis simultâneos); use níveis mais altos para mais túneis S2S ou maior vazão agregada.

Padrões de conectividade privada: Private Link, Private Endpoints e service endpoints

O Private Link e os private endpoints fornecem acesso de primeira classe a PaaS sem rotear o tráfego pela internet; os service endpoints protegem o acesso ao serviço, mas mantêm a saída pelo backbone do serviço público. Use um private endpoint quando precisar de IPs privados por recurso e integração de DNS; use service endpoints quando precisar de um controle de acesso mais simples no nível da sub-rede e estiver confortável em expor a saída do serviço para o backbone do serviço. Detalhes operacionais importantes incluem a resolução de DNS: private endpoints exigem a atualização do DNS on-prem ou das Zonas Privadas de DNS do Azure para que os clientes resolvam o IP privado; encaminhadores condicionais para servidores DNS on-prem são comuns para redes conectadas por S2S. Cenários de serviço Private Link entre assinaturas são suportados se os recursos estiverem no mesmo tenant do Azure AD; implante o serviço Private Link atrás de um Standard Internal Load Balancer (ILB) para escalabilidade e redundância de zona. Uma armadilha frequente é usar o Basic ILB ou um SKU incorreto, o que limita a integridade e a escalabilidade do backend. Para um serviço Private Link que suporta um alto volume de conexões, use o Standard ILB, backends de conjunto de dimensionamento e considere múltiplas NICs de endpoint por instância de backend. Considere também a proteção contra DDoS: habilite o DDoS Protection Standard para NICs voltadas para o público e planeje o escalonamento de portas SNAT e o NAT Gateway onde muitas conexões de saída se originam.

Tabelas de rotas do hub da vWAN e design prático de rotas

A vWAN usa tabelas de rotas do hub para direcionar o tráfego entre spokes conectados, sites on-premise e a internet. Cada conexão (site, VNet, P2S) pode ser associada a uma tabela de rotas do hub; as prioridades de rota e as regras de propagação determinam o encaminhamento final. Um bom design começa com uma tabela de rotas do hub padrão que encaminha o tráfego destinado à internet para o Azure Firewall ou um NVA, e tabelas de rotas especializadas para filiais que exigem breakout local (on-prem). O BGP de dispositivos VPN on-premise propaga prefixos para o hub, e você pode redistribuí-los para os spokes ou filtrá-los com tabelas de rotas. Uma armadilha comum são as rotas definidas pelo usuário (UDRs) conflitantes nas VNets spoke que tentam sobrepor a propagação do hub; na vWAN, as tabelas de rotas do hub têm precedência para interconexões, mas as UDRs nos spokes ainda afetam o egresso local. Para túnel forçado (forced tunneling), associe as conexões spoke a uma tabela de rotas do hub que direcione 0.0.0.0/0 para o seu dispositivo de inspeção escolhido. Monitore e planeje os limites de rota: os hubs da vWAN têm um número máximo de prefixos aprendidos e anunciados — projete a sumarização de prefixos e comunidades ou filtros BGP para permanecer dentro dos limites. Sempre teste a resolução de DNS e o split-DNS para private endpoints, e documente o comportamento de failover para designs multi-hub ativo/ativo para atender aos SLAs de resiliência.

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

Cenário: A Contoso Manufacturing opera uma presença global no Azure com uma arquitetura VNet hub-and-spoke existente em duas regiões, múltiplos sites on-premise conectados via SD-WAN e o requisito de centralizar a segurança e fornecer conectividade PaaS privada entre assinaturas (subscriptions).

Desafio: Eles precisam de um trânsito global gerenciado e escalável que centralize a inspeção (inspeção TLS, IDPS), suporte a muitas conexões de filiais via SD-WAN e exponha vários recursos PaaS de armazenamento e banco de dados de forma privada para os spokes e para o ambiente on-premise, sem expô-los publicamente.

Abordagem Recomendada:

Implante a Azure Virtual WAN (vWAN) e crie hubs virtuais seguros (secured virtual hubs) em cada região. Em cada hub, habilite o Azure Firewall Premium (para inspeção TLS e IDPS) e integre-o com o Firewall Manager. Associe o hub às conexões SD-WAN de parceiros da vWAN para um ponto de entrada (on-ramp) direto das filiais.
Configure as tabelas de rotas do hub para direcionar o tráfego destinado à internet e entre regiões para o Azure Firewall Premium; crie tabelas de rotas especializadas para filiais que devem ter egresso on-premise. Use o BGP da SD-WAN para anunciar prefixos on-premise na vWAN e aplique filtros de prefixo para evitar a inflação de rotas (route bloat).
Para serviços PaaS, provisione serviços Private Link em uma VNet dedicada por região, atrás de um Standard Internal Load Balancer, e exponha Private Endpoints nas VNets spoke e no ambiente on-premise por meio da conectividade da vWAN. Use Azure DNS Private Zones e encaminhadores condicionais (conditional forwarders) para garantir a resolução de nomes no ambiente on-premise.
Habilite o DDoS Protection Standard nos endpoints públicos, implante o NAT Gateway para grandes necessidades de SNAT de saída nos spokes e monitore as métricas de SNAT/DNAT. Use políticas do Firewall Manager para distribuição centralizada de regras e configure o envio de logs para um workspace central do Log Analytics.

Justificativa: Esta abordagem utiliza a vWAN para conectividade escalável de filiais e trânsito global, usa o Azure Firewall Premium para a inspeção avançada e centralizada exigida pela política de segurança, e o Private Link para acesso seguro a PaaS sem exposição pública — equilibrando capacidade de gerenciamento, segurança e escala operacional.

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

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