O exame AZ-700 avalia a sua capacidade de determinar qual caminho o tráfego escolhe e o que define essa prioridade. Em vez de memorizar listas de funcionalidades, é preciso saber, em cada cenário, qual ferramenta utilizar e onde aplicá-la. Controlar rotas estáticas com UDR, gerenciar rotas dinâmicas com BGP e Azure Route Server, e estruturar redes em grande escala com VNet Peering e Hub-Spoke são os pilares desta seção.
Rotas do sistema e prioridade de roteamento
Quando uma nova rodovia é inaugurada, os aplicativos de navegação a reconhecem imediatamente e começam a orientar os motoristas por ela. O Azure funciona da mesma forma: no momento em que você cria uma VNet, ele gera automaticamente rotas do sistema. O espaço de endereços da VNet recebe o next hop , aponta para e os intervalos privados RFC 1918 são configurados como (descarte).
A prioridade de rotas segue dois princípios. Primeiro, o prefixo mais específico sempre vence — é a regra de longest prefix match. Segundo, quando duas rotas competem com o mesmo prefixo, a ordem é .
Uma armadilha frequente no exame: se existir um UDR com e next hop , esse UDR supera qualquer anúncio BGP proveniente de um VPN Gateway. Para implementar force tunneling corretamente, o next hop deve ser , não .
UDR: direcionando o tráfego para onde você precisa
Imagine um centro de distribuição onde certos produtos devem obrigatoriamente passar por uma área de inspeção antes de serem despachados. Em vez de confiar que cada funcionário encontrará o caminho correto, são colocadas sinalizações que obrigam todos a passar por aquele ponto de verificação. Os User Defined Routes funcionam exatamente assim: substituem as rotas do sistema do Azure para direcionar o tráfego por um salto específico.
O caso de uso mais comum é forçar que todo o tráfego das sub-redes Spoke passe por uma NVA ou firewall no Hub. Basta associar uma tabela de rotas à sub-rede Spoke com a regra: .
Os UDR suportam cinco tipos de next hop:
: encaminha para um IP específico (NVA, firewall) : roteia para o gateway VPN ou ExpressRoute : mantém o tráfego dentro da VNet : envia o tráfego para a internet pública do Azure : descarta o pacote
BGP e Azure Route Server: o mundo do roteamento dinâmico
Assim como uma torre de controle aéreo, o BGP (Border Gateway Protocol) permite que os roteadores troquem e atualizem rotas dinamicamente, sem depender de tabelas estáticas.
No Azure, o BGP é usado nos VNet Gateways para trocar rotas com roteadores locais via VPN ou ExpressRoute. O VPN Gateway usa um ASN (padrão: 65515) que não deve coincidir com o ASN local.
O Azure Route Server vai além: quando uma NVA faz peering BGP com ele, as rotas da NVA são propagadas automaticamente pela VNet, sem precisar atualizar UDR manualmente.
| Atributo | UDR | Azure Route Server | |--|--|--| | Tipo de rota | Estática (manual) | Dinâmica (BGP) | | Gerenciamento | Atualização manual a cada mudança | NVA atualiza automaticamente | | Melhor uso | Topologias pequenas e fixas | Ambientes grandes com NVA |
VNet Peering: conectado mas isolado
Pense em dois edifícios com um corredor interno que os conecta diretamente, sem passar pela rua. O VNet Peering é esse corredor: o tráfego flui pelo backbone do Azure sem tocar a internet pública nem um gateway.
O peering é Regional (mesma região) ou Global (entre regiões). A regra mais importante: o peering é . VNet A em peering com B, e B com C, não garante que A chegue a C automaticamente.
Para comunicação Spoke-to-Spoke, roteie o tráfego pela NVA do Hub com UDR, ou use o Azure Virtual WAN para gerenciamento automático.
O Gateway Transit permite que as VNets Spoke compartilhem o gateway VPN ou ExpressRoute do Hub para conectividade local. Ambos os lados precisam ser configurados: no peering do Hub e no peering do Spoke.
Topologia Hub-Spoke: segurança centralizada por design
Imagine a sede de uma empresa que recebe toda a correspondência das filiais e encaminha ao setor correto. A topologia Hub-Spoke funciona assim: a VNet Hub hospeda firewall, VPN/ExpressRoute Gateway, DNS e Active Directory, enquanto cada VNet Spoke executa suas cargas de trabalho.
A principal vantagem é centralizar as políticas de segurança no Hub, sem replicar regras em cada Spoke.
O force tunneling usa UDR com apontando para a NVA do Hub. Configurar next hop como em vez de ignoraria o firewall — um erro grave.
VNet Peering vs VPN vs ExpressRoute: escolhendo a conexão certa
Escolher como conectar locais é como escolher um meio de transporte: corredor interno, rodovia pública ou via privada — cada um serve a necessidades diferentes de velocidade, custo e segurança.
| Atributo | VNet Peering | VPN Gateway | ExpressRoute | |--|--|--|--| | Caminho | Backbone do Azure | Internet pública (criptografada) | Circuito privado dedicado | | Latência | A mais baixa | Média | A mais baixa (linha privada) | | Transit | Não | Sim (BGP) | Sim (BGP) | | Base de custo | Volume de transferência de dados | SKU do Gateway + dados | Circuito + SKU do Gateway | | Uso principal | Interno Azure-para-Azure | Conexão local pequena | Alto volume e alta disponibilidade |
A não transitividade do VNet Peering é a distinção mais avaliada. Para o tráfego local chegar ao Spoke pelo Hub, são necessários um VPN Gateway no Hub e Gateway Transit configurado em ambos os lados.
Armadilhas do exame: três cenários que costumam confundir
No AZ-700, as questões de roteamento giram em torno de diferenças pequenas, mas significativas — como em um quiz onde duas respostas parecem idênticas.
Cenário um: um UDR no roteia tráfego local pela NVA, mas qualquer erro silenciosamente interrompe o link VPN ou ExpressRoute.
Cenário dois: é configurado no Hub; é configurado no Spoke. Ambos são necessários — sem qualquer um deles, o Spoke não tem gateway para usar.
Cenário três: se a NVA suporta BGP e rotas mudam com frequência, use Azure Route Server. Para topologias simples e estáveis, o UDR é suficiente.
Resumo do Exame
"Tráfego Spoke-to-Spoke falha" -- VNet Peering é não transitivo; rotear pela NVA do Hub com UDR "O Spoke precisa usar o gateway do Hub" -- Hub: Allow gateway transit ativado; Spoke: Use remote gateway ativado "UDR 0.0.0.0/0 next hop Internet + BGP de VPN" -- O UDR vence; o anúncio BGP é ignorado "Configuração de force tunneling" -- UDR 0.0.0.0/0, next hop: Virtual network gateway ou Virtual appliance "NVA injeta rotas dinamicamente na VNet" -- Azure Route Server com peering BGP "Roteamento Spoke-to-Spoke automático em Hub-Spoke" -- Azure Virtual WAN "A tenta chegar a C passando por B com VNet Peering" -- Não é possível; adicionar peering A-C ou usar Virtual WAN "Erro no UDR do GatewaySubnet" -- Pode interromper a conectividade VPN ou ExpressRoute completamente "Sobreposição de ASN entre rede local e Azure VPN Gateway" -- Erro de configuração; os ASNs devem ser únicos "Ordem de prioridade de rotas" -- UDR supera BGP, BGP supera rota do sistema (mesmo prefixo)
UDR = controle estático de tráfego, Azure Route Server = injeção dinâmica de rotas pela NVA, Hub-Spoke = gateway de segurança centralizado