Microsoft AZ-700: ExpressRoute e Conectividade WAN — 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.

Fundamentos, modelos de emparelhamento e SKUs do ExpressRoute

O ExpressRoute fornece uma conexão privada de alta taxa de transferência entre suas redes locais (on-premises) e o backbone global da Microsoft. Existem dois modelos de implantação: circuitos fornecidos por um provedor de serviços (co-location em um ponto de troca de tráfego ou por meio de um parceiro) e o ExpressRoute Direct, no qual você solicita portas físicas da Microsoft (adequado para cenários de 10/100/400 Gbps). A conectividade lógica com o Azure usa emparelhamento (peering): emparelhamento privado para conectividade de VNet, emparelhamento da Microsoft para a plataforma Azure e endpoints de PaaS, e (onde suportado) migrações legadas de emparelhamento público. As escolhas de design dependem da largura de banda, do escopo geográfico e da escala de rotas anunciadas. Escolha o SKU do circuito com base no escopo e na escala de rotas, em vez da largura de banda pura, e combine-o com um gateway de rede virtual de tamanho apropriado ou um hub de Virtual WAN para terminar a conectividade.

• Local: emparelhamento limitado à metrópole/região do local de emparelhamento; custo mais baixo e menor ocupação na tabela de roteamento.
• Standard: conectividade com todas as regiões públicas do Azure na mesma geografia; custo e escala de rotas intermediários.
• Premium (add-on): expande o alcance para todas as regiões globais e aumenta a contagem de rotas suportadas e os anexos de VNet; necessário para topologias de trânsito global e muitas VNets emparelhadas.

Armadilhas comuns incluem presumir que o ExpressRoute equivale a rotas ilimitadas ou roteamento transitivo automático entre VNets; você deve avaliar explicitamente os limites de rota, os tipos de emparelhamento e se precisa do add-on Premium para alcance global ou prefixos extras.

Ciclo de vida do provisionamento, artefatos necessários e detalhes de configuração

O provisionamento de um circuito ExpressRoute é um exercício de coordenação entre sua equipe de rede e um provedor de conectividade. Depois de criar o circuito no Azure, você recebe uma chave de serviço (o ServiceKey/ID da Chave de Serviço) que o provedor usa para provisionar a conexão cruzada (cross-connect) física. Escolha o local de emparelhamento (metrópole/colocation) ao criar o circuito, selecione a largura de banda (de 50 Mbps até múltiplos Gbps, dependendo do provedor e do modelo) e configure o emparelhamento (privado e/ou da Microsoft) e as VLANs/sub-redes para BGP. Termine o ExpressRoute em uma VNet por meio de um Gateway de Rede Virtual (ou em um hub de Virtual WAN) ou use o ExpressRoute Direct para se conectar à borda da Microsoft para larguras de banda muito altas.

Sequência de provisionamento típica:

• Criar o circuito ExpressRoute no Azure e registrar a Chave de Serviço (Service Key).
• Compartilhar a Chave de Serviço com o provedor e coordenar a conexão cruzada (cross-connect) física e a VLAN.
• Configurar o emparelhamento (privado/da Microsoft), os IPs dos pares BGP e os ASNs em ambos os lados.
• Vincular o circuito à(s) VNet(s) por meio de uma conexão ExpressRoute a um gateway de rede virtual ou hub de Virtual WAN e validar as rotas BGP.

Esteja atento para planejar previamente as escolhas de ASN do BGP, os IPs dos roteadores pares, os espaços de IP sobrepostos e a capacidade do SKU do gateway que você precisará.

FastPath, Global Reach, SKUs de gateway e trade-offs de desempenho

O ExpressRoute FastPath reduz a latência e aumenta a taxa de transferência ao contornar (bypass) o host do gateway e encaminhar pacotes diretamente entre seu dispositivo local (on-premises) e as NICs da VM/instância no caminho de dados da VNet. É ideal para cargas de trabalho sensíveis à latência, mas possui requisitos e restrições: o FastPath exige emparelhamento privado, um circuito ExpressRoute que o suporte e um SKU de gateway de rede virtual que suporte explicitamente o FastPath (gateways Basic não são suportados). O FastPath também afeta a inspeção e o fluxo de tráfego: como os pacotes contornam o host do gateway, quaisquer dispositivos de segurança (appliances) ou inspeção centralizada que dependem do hairpinning hospedado no gateway podem não ver o tráfego, a menos que você arquitete o tráfego por meio de NVAs posicionados em linha (inline) ou via tunelamento forçado.

O ExpressRoute Global Reach permite interconectar dois ou mais sites locais (on-premises) usando o backbone da Microsoft — útil quando você deseja que a Microsoft transporte o tráfego privado entre sites em vez de roteá-lo por links de ISP. Para usar o Global Reach, você deve ter circuitos ExpressRoute em ambos os sites, habilitar o Global Reach nos circuitos e garantir que o provedor o suporte. As compensações entre desempenho e custo são diretas: use o ExpressRoute Direct ou múltiplos circuitos de alta largura de banda para taxa de transferência e resiliência; use circuitos Standard/Local para conectividade de menor custo apenas na metrópole; e use o FastPath onde ganhos de microssegundos são importantes, mas aceite mudanças no design para o posicionamento de NVAs e a inspeção de pacotes.

Padrões de arquitetura WAN: Virtual WAN, VPN vs. ExpressRoute, roteamento e armadilhas comuns de design

Ao projetar uma WAN para o Azure, três padrões dominantes surgem: hub-and-spoke usando Virtual Network Gateway(s), Virtual WAN (hub gerenciado) com conectividade integrada de SD-WAN/filiais e uma malha pura de ExpressRoute com VNet peering ou anexos do Virtual WAN. O Virtual WAN simplifica a conectividade de filiais e escala bem para muitos túneis S2S/VPN e integrações de SD-WAN, mas acarreta um custo contínuo mais alto e usa o modelo de roteamento do hub do Virtual WAN. Os Virtual Network Gateways tradicionais (famílias VpnGw1/2/3) são mais baratos para um número limitado de túneis, mas exigem gateways por VNet para cenários transitivos. O ExpressRoute oferece latência e throughput previsíveis e combina bem com o Virtual WAN quando você precisa tanto de conectividade de backbone privado quanto de agregação gerenciada de filiais.

As principais armadilhas operacionais e de roteamento incluem espaços de IP sobrepostos entre o ambiente on-premises e as VNets, configuração incorreta de BGP ASN ou IP de peer (você deve habilitar o BGP tanto no Virtual Network Gateway quanto no seu dispositivo de borda do cliente) e UDRs ou regras de NSG inadvertidas que bloqueiam prefixos aprendidos via BGP. Além disso, tenha clareza sobre a precedência de roteamento: rotas de sistema (BGP/conectadas) geralmente têm precedência sobre UDRs, a menos que você configure explicitamente os próximos saltos (next hops) de forma diferente; garanta que o tunelamento forçado/saídas para a Internet e os pontos de inspeção de NVA sejam testados ao combinar ExpressRoute e VPN, e verifique os limites de rotas suportados e a contagem de túneis do gateway de VPN para o SKU que você escolher.

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

Cenário: A Contoso Corp tem um data center principal em Washington, D.C. e uma presença existente no Azure com VNets em East US e East US 2. A Contoso já possui um circuito ExpressRoute intermediado por um provedor com peering na região metropolitana de Ashburn e precisa conectar um segundo data center na Virgínia e habilitar conectividade de baixa latência entre ambos os data centers e suas VNets.

Desafio: Eles precisam de conectividade resiliente e de baixa latência entre data centers para o Azure, desejam minimizar a exposição à internet pública e exigem trânsito pelo backbone da Microsoft entre os sites on-premises sem reconstruir o roteamento principal on-premises.

Abordagem Recomendada:

1. Provisione um segundo circuito ExpressRoute no segundo data center e solicite ao provedor que faça o peering no mesmo local (Ashburn). Use um circuito Standard inicialmente e planeje o uso do Premium se for necessário alcance global de VNet ou maior capacidade de rotas.
2. Forneça a Service Key de cada circuito ao provedor para concluir os cross-connects e, em seguida, habilite o ExpressRoute Global Reach entre os dois circuitos para que os sites on-premises possam trocar tráfego privado através do backbone da Microsoft.
3. Implante ou atualize o Virtual Network Gateway na VNet hub para um SKU compatível com ExpressRoute que suporte FastPath (evite o Basic); habilite o peering privado com BGP, defina ASNs locais e IPs de peer exclusivos e anuncie os prefixos on-premises.
4. Se existirem cargas de trabalho sensíveis à latência, habilite o ExpressRoute FastPath na conexão de peering privado após validar que os NVAs e os caminhos de inspeção foram rearquitetados para levar em conta o host do gateway que é contornado (bypassed).

Justificativa: Circuitos duplos com Global Reach fornecem trânsito resiliente e privado pelo backbone da Microsoft entre os data centers e o Azure sem expor o tráfego à internet pública; habilitar o FastPath melhora a latência para fluxos sensíveis, mas exige suporte do SKU do gateway e ajustes de design para inspeção de pacotes e NVAs.

Todos os domínios · Projeto de Azure Virtual Network →

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

Navegar Microsoft →