Redes é um dos domínios mais desafiadores do exame AZ-305. É necessário entender com precisão os limites entre os serviços: a diferença entre Front Door e Traffic Manager, as limitações do Application Gateway e por que o BGP é obrigatório com o ExpressRoute. Este artigo foca nos padrões essenciais extraídos da análise de 42 questões reais do exame.
---
Design de VNet e sub-redes
Uma VNet pertence a uma única região do Azure. Se você implantar infraestrutura em 3 regiões, o número mínimo de VNets é 3, e a separação por camadas (frontend/backend/banco de dados) é tratada no nível de sub-rede. Uma armadilha comum no exame é calcular número de regiões × número de camadas quando a pergunta é sobre o "número mínimo de VNets".
Em ambientes híbridos, conflitos de espaço de endereços IP são fatais. Se os endereços se sobrepõem, o roteamento se torna impossível e não há alternativa. O Azure reserva 5 endereços IP por sub-rede (endereço de rede, gateway, dois DNS e broadcast). Uma sub-rede /24 oferece 251 endereços utilizáveis, mais do que suficiente para 150 VMs.
Princípios de design do GatewaySubnet
A sub-rede de um VPN Gateway ou ExpressRoute Gateway deve se chamar exatamente . Três regras estritas se aplicam.
Sub-rede dedicada obrigatória: não é possível colocar cargas de trabalho como VMs junto com o gateway. NSG não deve ser aplicado: aplicar um NSG bloqueia o tráfego do plano de controle e causa falhas nos túneis. Tamanho recomendado: /27 ou maior. Um /27 é a escolha segura ao planejar uma migração para ExpressRoute ou coexistência de dois gateways.
O pré-requisito fundamental para VNet Peering é que os espaços de endereço das duas VNets não se sobreponham. Se houver sobreposição, é obrigatório redesenhar o espaço IP — não existe alternativa usando NAT Gateway ou VPN Gateway.
---
Conectividade híbrida: VPN Gateway e ExpressRoute
O ExpressRoute usa BGP (Border Gateway Protocol) como seu único protocolo de roteamento. Se você vir uma opção de roteamento estático em uma questão do exame, elimine-a imediatamente. Quando o site A falha, a sessão BGP é encerrada e o tráfego é automaticamente redirecionado para o site B em questão de segundos. Para distinguir caminhos primários de caminhos de backup em uma configuração redundante, usa-se AS Path Prepending: mantenha o AS Path curto para o caminho primário (site A) e longo para o backup (site B).
Quando as palavras-chave "failover automático + roteamento dinâmico" aparecerem, escolha BGP. Se o requisito é "fixar rotas manualmente", escolha UDR.
Seleção de SKU do Azure Virtual WAN
O Virtual WAN entra em cena quando você precisa gerenciar vários sites a partir de um hub central.
SKU Basic: suporta apenas VPN site a site. Não suporta ExpressRoute nem roteamento transitivo entre regiões. SKU Standard: suporta ExpressRoute, VPN S2S, VPN P2S e roteamento transitivo entre regiões.
Sempre que o exame mencionar ExpressRoute ou roteamento transitivo entre regiões, a resposta é SKU Standard. Para o posicionamento de hubs, se o requisito é "roteamento para o ponto mais próximo em N continentes", são necessários no mínimo N hubs. Um Secured Virtual Hub integra o Azure Firewall no hub. Quando as três palavras-chave P2S + roteamento transitivo + filtragem de FQDN aparecerem simultaneamente, selecione Virtual WAN Standard + Secured Virtual Hub.
---
Roteamento global de tráfego: Front Door, Traffic Manager, CDN
O Front Door é um proxy de camada 7 que opera via Anycast na rede de borda global da Microsoft. Ele aceita tráfego no PoP mais próximo do usuário e aplica políticas de WAF na borda. Oferece failover automático entre regiões (em segundos), WAF integrado (SQL Injection, XSS, bots, limitação de taxa), offload de SSL, roteamento baseado em caminho de URL e afinidade de sessão baseada em cookies — tudo como um único serviço.
O Front Door Premium suporta origens de Private Link. As VMs de backend nunca ficam expostas à internet; o Front Door se conecta por um caminho privado. Para permitir apenas o tráfego do Front Door em um NSG, use a service tag . A Microsoft a mantém automaticamente, então você nunca precisa gerenciar listas de IP.
O Traffic Manager é um serviço de entrega de tráfego baseado em DNS. Ele simplesmente retorna o IP do endpoint ideal ao cliente como uma resposta DNS — nenhum pacote de tráfego passa por ele. Por causa dessa arquitetura não-interceptora, ele não consegue realizar manipulação de cabeçalhos HTTP, limitação de taxa ou offload de SSL. Combiná-lo em camadas com Application Gateway WAF por região é um padrão poderoso: o Traffic Manager seleciona a região no nível de DNS, enquanto o Application Gateway trata o roteamento por cabeçalho HTTP e o WAF.
---
Balanceamento de carga: Application Gateway e Azure Load Balancer
O Application Gateway é um serviço de balanceamento de carga de camada 7 para uma única região. Ele não possui roteamento entre regiões nem capacidade de failover automático. Para atender múltiplas regiões, você implanta instâncias separadas em cada uma e coloca Traffic Manager ou Front Door acima delas. O SKU com WAF oferece proteção baseada em OWASP CRS contra SQL Injection e XSS, afinidade de sessão por cookies, roteamento baseado em caminho de URL e escalonamento automático. Quando o requisito for "WAF + afinidade de sessão + balanceamento de carga como um único serviço", o Application Gateway WAF é a resposta.
O padrão de combinar API Management (APIM) com Application Gateway também é avaliado. O tráfego externo entra pelo Application Gateway (WAF) e é encaminhado para o APIM dentro da VNet. O APIM no modo Internal recebe apenas um IP privado e não pode ser acessado diretamente pela internet, tornando-o adequado para cenários exclusivos de equipes internas.
O Azure Load Balancer é um serviço de camada 4 OSI (TCP/UDP) para uma única região. Ele não possui roteamento por cabeçalho HTTP, WAF nem failover entre regiões. O Gateway Load Balancer insere de forma transparente NVAs de terceiros em um balanceador de carga existente usando tunelamento VXLAN. Selecione-o quando vir a combinação de palavras-chave "NVA de terceiros + inserção transparente L4 + minimizar alterações na configuração existente".
!Application Gateway vs Azure Load Balancer
Tabela comparativa de serviços
| Característica | Front Door | Traffic Manager | Application Gateway | Azure Load Balancer | |---------------|-----------|----------------|---------------------|--------------------| | Camada | L7 (HTTP/HTTPS) | Baseado em DNS | L7 (HTTP/HTTPS) | L4 (TCP/UDP) | | Escopo | Global | Global | Região única | Região única | | WAF integrado | Sim | Não | Sim (SKU WAF) | Não | | Afinidade de sessão | Sim | Não | Sim (cookies) | Não | | Failover regional | Automático (segundos) | Baseado em TTL DNS | Nenhum | Nenhum | | Caso de uso principal | App L7 global | Geo-roteamento DNS | L7 + WAF regional | Balanceamento L4 regional |
---
Critérios de decisão que costumam confundir os candidatos
Quando um único serviço precisa cobrir HTTP/HTTPS global + terminação SSL + failover automático, escolha Front Door. O Traffic Manager não consegue terminar SSL, e o Application Gateway está limitado a uma única região.
Quando o requisito é roteamento ao ponto geográfico mais próximo + roteamento por cabeçalho HTTP por região + WAF, escolha o padrão em camadas de Traffic Manager + Application Gateway WAF. O Azure Load Balancer não suporta cabeçalhos HTTP nem WAF, então a combinação Front Door + Load Balancer é inadequada.
Quando um aplicativo local precisa ser exposto externamente, os servidores não devem ser expostos diretamente e a autenticação do Entra ID é exigida simultaneamente, escolha Microsoft Entra Application Proxy. Instalar apenas um agente conector no ambiente local permite o acesso externo sem alterar nenhuma regra de entrada do firewall, e o Conditional Access com MFA é suportado nativamente.
Quando você precisa resolver FQDNs de Private Endpoint a partir de DNS local via ExpressRoute, combine Azure Private DNS Zone com um endpoint de entrada do DNS Private Resolver. Configure o encaminhamento condicional no servidor DNS local para o domínio apontando para o IP do endpoint de entrada e você receberá respostas com IPs privados.
Quando você precisa verificar imediatamente se um NSG está bloqueando tráfego, escolha Network Watcher IP Flow Verify. Insira a 5-tupla e ele retorna o resultado de permissão/bloqueio do NSG e o nome da regra correspondente em segundos. O NSG Flow Logs é uma ferramenta de análise agregada posterior e não é adequada para diagnósticos imediatos.
---
Dicas de implementação prática
Em todo cenário que envolva Private Endpoint, você deve pensar também no design do DNS. Crie uma Azure Private DNS Zone e vincule-a à VNet para que os FQDNs sejam resolvidos automaticamente para IPs privados. Ao conectar App Service e SQL Database de forma privada, você precisa de pelo menos duas sub-redes separadas. A sub-rede de integração VNet do App Service (mínimo /28) e a sub-rede de Private Endpoint têm funções distintas e não podem ser compartilhadas.
Para validar centralmente tokens JWT no API Management, configure a política no nível do gateway. Isso permite aplicar a validação de tokens em todas as APIs sem modificar o código de nenhuma API de backend. Para configurar conectividade privada com serviços PaaS no Synapse Analytics, você deve habilitar a Managed Virtual Network ao criar o workspace. Essa configuração não pode ser alterada após a criação, portanto deve ser decidida na fase de design.
---
Resumo
Esses são os critérios de decisão que aparecem repetidamente nas questões de redes do AZ-305.
L7 global + WAF + failover automático como um único serviço → Front Door Geo-roteamento DNS + WAF L7 por região → Traffic Manager + Application Gateway em camadas Balanceamento L4 entre VMs em uma única região → Azure Load Balancer Failover automático com ExpressRoute → BGP + AS Path Prep