Microsoft AZ-900: Rede — Guia de estudos

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

A rede do Azure fornece a base para conectar com segurança cargas de trabalho, usuários e serviços entre regiões e entre ambientes locais (on-premises) e na nuvem. Ela abrange redes privadas definidas por software, conectividade híbrida, distribuição de tráfego global e defesas em camadas contra ameaças. Projetos sólidos começam com um planejamento de endereçamento claro, limites de isolamento e resolução de nomes, e então adicionam a combinação certa de conectividade e proteção para atender às metas de desempenho e conformidade.

Rede virtual principal: VNets, sub-redes, endereçamento IP e DNS

Uma rede virtual (VNet) é o limite de isolamento para a rede privada no Azure. As VNets abrangem uma única região, são vinculadas a uma assinatura e usam os espaços de endereço RFC1918 que você define. Dentro de uma VNet, as sub-redes segmentam o espaço de endereço em camadas lógicas (por exemplo, web, app e dados). As sub-redes suportam políticas de rede, como grupos de segurança de rede (NSGs), tabelas de rotas, pontos de extremidade de serviço e delegação para serviços PaaS específicos. Um planejamento CIDR cuidadoso evita sobreposições com redes locais e outras VNets com as quais você possa fazer emparelhamento no futuro. O endereçamento IP no Azure inclui endereços privados e públicos. IPs privados são anexados a NICs em máquinas virtuais e outros recursos para tráfego leste-oeste dentro de uma VNet ou através de emparelhamento e VPN/ExpressRoute. IPs privados podem ser dinâmicos ou estáticos dentro de uma sub-rede. IPs públicos expõem recursos à internet ou fornecem conectividade de saída usando NAT. IPs públicos Standard são redundantes entre zonas onde disponível, são fechados para entrada por padrão e devem ser combinados com balanceadores de carga, Application Gateways ou Azure Firewall, em vez de serem atribuídos diretamente a VMs, a menos que haja uma forte justificativa. A resolução de nomes é tratada por padrão pelo resolvedor de DNS fornecido pelo Azure (168.63.129.16), que resolve nomes de host dentro de uma VNet. Para pontos de extremidade privados e resolução de nomes híbrida, as zonas de DNS Privado do Azure mapeiam FQDNs privados (por exemplo, privatelink.database.windows.net) para endereços IP privados. Você pode vincular zonas de DNS Privado a várias VNets. Se você usar servidores DNS personalizados, garanta que o encaminhamento condicional cubra as zonas de DNS Privado do Azure para que os recursos resolvam os pontos de extremidade privados em vez dos pontos de extremidade de serviço públicos.

• Escopo
  • IP Privado: Dentro de redes VNet/emparelhadas/híbridas
  • IP Público: Voltado para a internet
• Atribuição
  • IP Privado: Dinâmico ou estático por NIC/sub-rede
  • IP Público: Dinâmico ou estático; SKU Standard recomendado
• Usos comuns
  • IP Privado: VM para VM, Private Link, balanceamento de carga interno
  • IP Público: Entrada via LB/App Gateway; saída via SNAT/NAT Gateway
• Postura de segurança
  • IP Privado: Controlado por NSGs, UDRs
  • IP Público: Fechado por padrão (Standard); restringir com NSGs/Firewall

Conectividade híbrida e privada: VPN Gateway, ExpressRoute, VNet peering e Private Link

O Azure VPN Gateway estabelece túneis criptografados usando IPsec/IKE para conexões site-to-site (S2S), point-to-site (P2S) e VNet-to-VNet. É uma forma econômica de estender sua rede local (on-premises) para o Azure pela internet pública, mantendo os dados criptografados em trânsito. A taxa de transferência (throughput) e o número de túneis escalam com o SKU do VpnGw, e a alta disponibilidade é alcançada por padrão com instâncias ativo/standby. O suporte a configurações ativo-ativo e BGP permite roteamento dinâmico e uma taxa de transferência agregada maior. O ExpressRoute fornece conectividade privada de Camada 3 (Layer 3) com SLA para a Microsoft por meio da borda de um parceiro ou peering direto. O tráfego permanece fora da internet pública, oferecendo latência previsível e opções de largura de banda mais altas. Os circuitos do ExpressRoute suportam múltiplos peerings (Azure private, Microsoft e Microsoft 365, quando aplicável) e usam conexões duplas redundantes. É a opção preferencial para cenários de missão crítica e alta taxa de transferência, frequentemente combinada com uma topologia hub-and-spoke, onde a VNet hub hospeda o ExpressRoute ou o VPN Gateway. O VNet peering conecta VNets pela espinha dorsal (backbone) da Microsoft com baixa latência e alta largura de banda, permitindo que os recursos se comuniquem usando IPs privados como se estivessem na mesma rede. O peering não é transitivo: o tráfego não é roteado automaticamente através de uma VNet emparelhada (peered) para uma terceira VNet. O trânsito de gateway (Gateway transit) pode ser habilitado para que as VNets spoke usem o gateway VPN ou ExpressRoute do hub. Para acessar PaaS por IP privado, o Private Link cria um ponto de extremidade privado (private endpoint) — uma NIC em sua sub-rede — que mapeia para uma instância de serviço específica, como Azure Storage, SQL Database ou um serviço privado que você publica. O tráfego flui inteiramente no backbone do Azure, e o DNS é fundamental para garantir que os clientes resolvam para o ponto de extremidade privado. A escolha entre essas opções depende dos requisitos: VPN Gateway para conectividade criptografada pela internet, ExpressRoute para circuitos privados de alto desempenho, VNet peering para conectividade privada intra-Azure e Private Link para acesso privado a serviços PaaS ou de parceiros sem expor pontos de extremidade públicos.

• VPN Gateway
  • Camada de conectividade: L3 (IPsec/IKE)
  • Escopo: On-prem <-> Azure; VNet <-> VNet
  • Largura de banda típica: Centenas de Mbps a múltiplos Gbps (por SKU)
  • Criptografia: Sim (IPsec)
  • Principais pontos fortes: Custo-benefício, flexível, P2S/S2S
  • Casos de uso primários: Extensão híbrida, dev/test, habilitação rápida
• ExpressRoute
  • Camada de conectividade: Circuito privado L3
  • Escopo: On-prem <-> Azure (via parceiro)
  • Largura de banda típica: 50 Mbps–100 Gbps (por circuito)
  • Criptografia: Circuito privado (não requer IPsec)
  • Principais pontos fortes: Latência previsível, alta taxa de transferência, SLA
  • Casos de uso primários: Híbrido de missão crítica, replicação de dados, conformidade (compliance)
• VNet Peering
  • Camada de conectividade: Backbone do Azure
  • Escopo: VNet <-> VNet (mesma região ou global)
  • Largura de banda típica: Limitada pela NIC/host da VM; baixa latência
  • Criptografia: Não (backbone privado)
  • Principais pontos fortes: Simples, rápido, suporte entre tenants
  • Casos de uso primários: Hub-spoke, malha de VNets regional/global
• Private Link
  • Camada de conectividade: Ponto de extremidade L7 via NIC privada
  • Escopo: VNet do cliente <-> Serviço PaaS/Privado
  • Largura de banda típica: Dependente da aplicação; limitada pela NIC
  • Criptografia: Isolamento no backbone
  • Principais pontos fortes: Elimina exposição pública, granular
  • Casos de uso primários: Acesso privado ao Storage, SQL, Key Vault, aplicações de parceiros

Distribuição e aceleração de tráfego: Load Balancer, Application Gateway, Front Door, Traffic Manager e CDN

O Azure Load Balancer opera na Camada 4 para TCP/UDP e fornece balanceamento de carga de alto desempenho e baixa latência dentro de uma região. Ele suporta cenários de entrada (inbound) e saída (outbound), regras de NAT de entrada e sondas de integridade (health probes). O Standard Load Balancer é ciente de zona (zone-aware) e pode abranger zonas em uma região para resiliência. É a escolha certa para protocolos não HTTP, back-ends de jogos e cenários que exigem portas de alta disponibilidade (HA ports) ou SNAT para conectividade de saída em escala por meio de regras de saída (outbound rules) ou NAT Gateway. O Application Gateway fornece roteamento HTTP/HTTPS na Camada 7 com recursos como roteamento baseado em caminho de URL e em host, afinidade de cookie (cookie affinity) e descarregamento de SSL (SSL offload). Quando habilitado com o SKU de Web Application Firewall (WAF), ele oferece conjuntos de regras OWASP gerenciadas para ajudar a proteger contra exploits e bots comuns. O Application Gateway é regional e frequentemente usado na frente de VM Scale Sets, Containers ou App Services em configurações de rede privada, especialmente onde são necessários roteamento HTTP rico e inspeção de WAF. O Azure Front Door é um ponto de entrada global, anycast e de Camada 7 que acelera e protege aplicações web voltadas para a internet. Ele fornece balanceamento de carga global com failover instantâneo, roteamento inteligente (smart pathing) e WAF integrado. O Front Door Standard/Premium integra recursos de CDN para aceleração de conteúdo estático e dinâmico na borda (edge) e pode ter como origem (origin) Application Gateways, App Services ou Storage. O Traffic Manager complementa esses serviços realizando distribuição global baseada em DNS entre quaisquer endpoints (HTTP ou não HTTP), usando métodos como roteamento por prioridade, desempenho, ponderado (weighted), geográfico, por sub-rede e de múltiplos valores (multi-value). Para descarregamento de conteúdo estático, a Azure CDN (incluindo Front Door Standard/Premium ou Azure CDN da Microsoft/Verizon/Akamai) armazena em cache o conteúdo mais perto dos usuários, reduz a carga na origem e melhora o desempenho. A combinação de serviços é comum. Um design típico voltado para a internet usa o Azure Front Door com WAF para entrada (ingress) global, com origem em Application Gateways regionais (com ou sem WAF) que roteiam para cargas de trabalho internas. Para protocolos que não sejam HTTP/HTTPS, combine o Traffic Manager para failover de DNS com Load Balancers regionais. Coloque IPs públicos apenas nessas bordas gerenciadas, mantendo as VMs da aplicação privadas.

• Azure Load Balancer
  • Camada: L4
  • Escopo: Regional
  • Protocolos: TCP/UDP
  • Suporte a WAF: Não
  • Afinidade de sessão: Não (na L7)
  • Casos de uso comuns: Cargas de trabalho não HTTP, balanceamento de carga interno, SNAT de saída
• Application Gateway
  • Camada: L7
  • Escopo: Regional
  • Protocolos: HTTP/HTTPS
  • Suporte a WAF: Sim (WAF v2)
  • Afinidade de sessão: Sim (baseada em cookie)
  • Casos de uso comuns: Aplicações web em VNets, descarregamento de SSL, roteamento por caminho/host
• Azure Front Door
  • Camada: L7
  • Escopo: Global
  • Protocolos: HTTP/HTTPS
  • Suporte a WAF: Sim (WAF)
  • Afinidade de sessão: Sim (cookie de afinidade)
  • Casos de uso comuns: Ponto de entrada global, aceleração na borda, failover instantâneo
• Traffic Manager
  • Camada: DNS
  • Escopo: Global
  • Protocolos: Qualquer (baseado em DNS)
  • Suporte a WAF: Não
  • Afinidade de sessão: Não
  • Casos de uso comuns: Failover/distribuição de carga entre regiões para qualquer endpoint
• Azure CDN
  • Camada: Cache L7
  • Escopo: Global
  • Protocolos: HTTP/HTTPS
  • Suporte a WAF: Não (use o WAF do Front Door)
  • Afinidade de sessão: N/A
  • Casos de uso comuns: Cache de conteúdo estático, descarregamento da origem, desempenho

Segurança de rede e acesso seguro: NSGs, Azure Firewall, DDoS Protection, Bastion e Just-in-Time

Os Network Security Groups (NSGs) aplicam filtragem stateful de Camada 3/4 a sub-redes e NICs. As regras permitem ou negam tráfego com base em parâmetros de 5-tuplas, com suporte para service tags e application security groups para simplificar o gerenciamento. Os NSGs são ideais para segmentar camadas (tiers), restringir portas de gerenciamento e impor o princípio de privilégio mínimo entre sub-redes. Eles são rápidos e distribuídos, mas não fornecem filtragem na camada de aplicação, prevenção de intrusão ou DNAT/SNAT centralizado. O Azure Firewall é um serviço de firewall e segurança de rede gerenciado e stateful que fornece tanto regras de rede quanto regras de aplicação (filtragem de FQDN). O SKU Premium adiciona inspeção de TLS, IDPS e filtragem de URL. Ele suporta DNAT/SNAT, filtragem baseada em threat intelligence e se integra com route tables para um ponto de controle de egresso central em topologias hub-and-spoke. O Azure Firewall complementa os NSGs: os NSGs impõem a microssegmentação leste-oeste local, enquanto o firewall impõe políticas centralizadas de tráfego norte-sul e de egresso para a internet. O Azure DDoS Protection vem nas ofertas Basic e Standard. A oferta Basic é uma proteção no nível da plataforma, aplicada automaticamente aos serviços do Azure sem necessidade de configuração pelo cliente. A Standard adiciona ajuste adaptativo, telemetria, alertas e mitigação rápida para recursos com IPs públicos dentro de uma VNet protegida, além de créditos de proteção de custos durante ataques documentados. Para acesso administrativo sem IPs públicos, o Azure Bastion fornece RDP/SSH sobre TLS diretamente do portal do Azure (e clientes nativos suportados no Bastion Standard), eliminando a exposição de entrada (inbound). O acesso Just-in-Time (JIT) a VMs, habilitado através do Microsoft Defender for Cloud, mantém as portas de gerenciamento fechadas nos NSGs e abre o acesso por tempo limitado apenas para usuários e IPs de origem aprovados, minimizando a superfície de ataque enquanto preserva o acesso operacional.

Problema Prático: Lançamento global de varejo para a Contoso Outdoors: rede segura, privada e de alta disponibilidade

Cenário: A Contoso Outdoors está lançando uma nova plataforma de e-commerce sustentada por microsserviços executados no Azure nas regiões East US e West Europe. A empresa deve manter todas as VMs de aplicação privadas, fornecer acesso administrativo seguro e permitir que parceiros façam upload de arquivos de inventário para o Azure Storage sem trafegar pela internet pública. O ERP on-premises em Chicago precisa de conectividade privada de baixa latência com os serviços em East US. O front-end web deve ser resiliente a uma falha de uma única região e proteger contra exploits web comuns e ataques volumétricos.

Desafio: Projetar uma rede que combine espaços de endereço privados, conectividade híbrida, distribuição HTTP global, acesso privado a PaaS e segurança em camadas sem expor IPs públicos de VMs.

Abordagem Recomendada:

1. Crie uma arquitetura hub-and-spoke em cada região. Implante uma VNet hub com o espaço de endereço 10.0.0.0/16 e spokes para as camadas web, de aplicação e de dados, usando sub-redes /24 que não se sobreponham. Associe NSGs a cada sub-rede para impor o princípio do menor privilégio entre as camadas.
2. Implante o Azure Firewall Premium em cada hub. Configure UDRs nos spokes para rotear todo o tráfego destinado à internet para o firewall, para controle de saída (egress), inspeção de TLS e filtragem de inteligência contra ameaças.
3. Estabeleça conectividade híbrida do datacenter de Chicago para o hub de East US com o ExpressRoute (private peering). Habilite conexões duplas para redundância e BGP para roteamento dinâmico. Use temporariamente uma VPN site-to-site como failover, se necessário.
4. Faça o emparelhamento (peering) dos spokes regionais com suas VNets hub locais usando o VNet peering. Habilite o trânsito de gateway (gateway transit) para que os spokes consumam o gateway ExpressRoute/VPN do hub. Use o global VNet peering para conectar os hubs de East US e West Europe para o tráfego de plano de controle e replicação.
5. Publique o site de e-commerce com o Azure Front Door Premium e WAF. Configure duas origens: os Application Gateways de East US e West Europe. Habilite as políticas de WAF gerenciadas do Front Door e a proteção contra bots. Ative o cache do Front Door para ativos estáticos.
6. Em cada região, implante o Application Gateway WAF v2 no spoke da web, terminando o TLS e realizando o roteamento baseado em caminho e host para os pools de backend (VM Scale Sets ou App Services) em sub-redes privadas. Use Standard Load Balancers internamente para microsserviços não-HTTP.
7. Para acesso privado de parceiros e entre serviços, crie Private Endpoints para o Azure Storage e o Azure SQL Database nos spokes de dados. Vincule as zonas de DNS Privado do Azure (Azure Private DNS zones) apropriadas a todos os spokes e hubs, e configure o DNS on-premises para encaminhar as zonas privatelink para o Azure para uma resolução de nomes consistente.
8. Proteja as superfícies expostas publicamente com o Azure DDoS Protection Standard, habilitando-o nas VNets hub que contêm os recursos de IP público para as origens do Application Gateway e do Front Door. Monitore as métricas de ataque e configure alertas.
9. Forneça administração segura implantando o Azure Bastion Standard em cada VNet hub. Remova todos os IPs públicos das VMs. Habilite o acesso Just-in-Time (JIT) a VMs no Defender for Cloud para que o acesso RDP/SSH seja limitado por tempo e restrito por origem ao ser tunelado através do Bastion.
10. Instrumente a rede com logs de fluxo de NSG (NSG flow logs), logs do Azure Firewall e logs de acesso do Front Door/Application Gateway para o Log Analytics. Configure sondas de integridade (health probes) e testes sintéticos para validar a disponibilidade de ponta a ponta e o comportamento de failover.

Justificativa da Solução Azure: Este design mantém os planos de aplicação privados e controlados, ao mesmo tempo que apresenta uma borda global reforçada (hardened). O ExpressRoute oferece conectividade privada e previsível para o sistema ERP, com o VNet peering e o gateway transit estendendo o acesso a todos os spokes. O Azure Front Door com WAF fornece distribuição HTTP global, failover instantâneo e segurança de borda, enquanto os Application Gateways regionais lidam com o roteamento L7 e o WAF próximo às cargas de trabalho. O Private Link elimina a exposição pública para o Storage e o SQL, apoiado por DNS privado para resolução de nomes transparente a partir do Azure e on-premises. Os NSGs impõem a microssegmentação; o Azure Firewall centraliza a saída (egress), DNAT/SNAT e inspeção avançada; o DDoS Protection Standard mitiga ataques volumétricos contra endpoints públicos. O Azure Bastion e o JIT oferecem acesso administrativo seguro e auditável sem abrir portas de gerenciamento ou atribuir IPs públicos a VMs, atendendo aos objetivos de segurança e conformidade sem sacrificar a operacionalidade.

← Serviços de Computação e Aplicativos · Todos os domínios · Armazenamento e Bancos de Dados →

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

Navegar Microsoft →