O exame AZ-700 testa decisoes de design em cenarios de VNet, Sub-rede e NAT Gateway. Se os espacos de enderecos CIDR se sobrepoem, o Peering de VNet torna-se impossivel. Calcular mal os IPs reservados torna a sub-rede menor do que o esperado. Entender como o NAT Gateway resolve o esgotamento de SNAT em conexoes de saida de grande volume e outro ponto central do exame.
Limites da VNet: Regiao e Unidade de Isolamento
Quando uma empresa inaugura um novo escritorio, o projeto de cabeamento e definido antes de se mover qualquer mesa. No Azure, uma Virtual Network (VNet) precisa ser criada antes de praticamente qualquer recurso ser implantado. Uma VNet existe dentro de uma unica regiao, e recursos dentro da mesma VNet se comunicam sem configuracao adicional.
O trafego que cruza limites de regiao requer VNet Peering, um VPN Gateway ou ExpressRoute. Os nomes de VNet precisam ser unicos apenas dentro do grupo de recursos. Se uma VNet tem Peering ativo, move-la para outro grupo de recursos fica bloqueado ate que esse Peering seja removido.
Uma VNet pode ter varios blocos CIDR como Espaco de Enderecos. Adicionar mais e possivel, mas se ja existe Peering ativo, adicionar um CIDR sobrepondente sera rejeitado. Definir bem o espaco de enderecos desde o inicio evita redesenhos custosos.
Particionamento de Sub-redes e IPs Reservados
Pense nas sub-redes como andares de um predio — cada andar abriga um departamento com controles de acesso proprios. No Azure, sub-redes sao a principal unidade de isolamento de trafego. O Azure reserva 5 enderecos IP em cada sub-rede: os primeiros 4 e o ultimo.
Para uma sub-rede /27 (32 enderecos), apenas 27 IPs estao disponiveis. Para 15 VMs, /27 funciona, mas /26 (59 IPs utilizaveis) oferece margem mais confortavel.
Certos servicos do Azure exigem uma sub-rede dedicada:
: exclusiva para Azure Firewall, minimo /26 recomendado : exclusiva para VPN Gateway e ExpressRoute Gateway : exclusiva para Azure Bastion, minimo /26 obrigatorio
A Subnet Delegation permite que servicos PaaS do Azure injetem NICs diretamente nessa sub-rede. Apenas uma Delegation pode estar ativa por sub-rede de cada vez.
SKUs de IP Publico: Basic vs Standard
Assim como o numero de telefone de uma empresa precisa permanecer o mesmo para gerar confianca, algumas cargas de trabalho precisam de um IP publico estavel. O IP Publico do Azure esta disponivel em dois SKUs: Basic e Standard.
Basic suporta atribuicao estatica ou dinamica e deixa a entrada aberta por padrao. Standard suporta apenas atribuicao estatica, e a entrada e negada a menos que um NSG permita explicitamente. Zone-Redundant e Zonal estao disponiveis apenas com Standard. Basic funciona apenas com Basic Load Balancer; Standard funciona apenas com Standard Load Balancer.
O IP Publico Standard e redundante por zona por padrao, sobrevivendo a falhas de zona sem alterar o endereco IP. Para fixar em uma zona especifica, escolha Zonal. O SKU Basic sera desativado em 30 de setembro de 2025.
IPv6 e Dual-Stack tambem estao no escopo do AZ-700. Atribuir espacos IPv4 e IPv6 a uma VNet cria Dual-Stack. Para Peering com trafego IPv6, ambos os lados devem ter espaco IPv6 definido.
!SKU de IP público: Basic vs Standard
NAT Gateway: Expandindo o Pool de SNAT de Saida
Imagine uma sala de correspondencia onde dezenas de funcionarios enviam cartas usando o mesmo endereco da empresa. Quando o volume aumenta, o endereco fica sem combinacoes distinguiveis de portas — isso e o esgotamento de SNAT. O NAT Gateway resolve exatamente esse problema.
Um unico NAT Gateway pode ser associado a ate 16 IPs Publicos ou um Public IP Prefix. Cada IP fornece 64,512 portas SNAT, portanto 16 IPs suportam cerca de um milhao de conexoes de saida simultaneas.
O NAT Gateway e associado no nivel da sub-rede. Todo o trafego de saida passa pelo NAT Gateway; conexoes de entrada nao sao tratadas por ele. Os IPs associados ficam dedicados exclusivamente ao uso de saida.
Escolhendo um Metodo de Saida: NAT Gateway vs Regras de Saida do Load Balancer vs IP Publico de Instancia
Pense em tres formas de um restaurante processar pagamentos: o cliente vai a cozinha, paga no caixa, ou usa um terminal centralizado. O roteamento de saida no Azure funciona da mesma forma — ha tres caminhos distintos.
Veja como os tres metodos se comparam:
NAT Gateway: 64,512 portas por IP, apenas saida, aplicado no nivel da sub-rede, alocacao dinamica que torna o esgotamento quase impossivel Regras de Saida do Load Balancer: ate 64,512 portas por IP pre-alocadas entre VMs do backend, menos portas por VM a medida que o pool cresce, regras de LB de entrada configuradas separadamente IP Publico de Instancia: 64,512 portas por VM de forma independente, suporta entrada e saida, configurado por NIC de VM
Quando um NAT Gateway esta associado a uma sub-rede, ele tem precedencia sobre as Regras de Saida do Load Balancer.
Prevencao de Sobreposicao de IPs e Armadilhas no Design de Peering
Dois departamentos usando o mesmo endereco postal farao cada carta chegar ao lugar errado. Da mesma forma, duas VNets com blocos CIDR sobrepostos nao podem ser conectadas via Peering — o erro de design mais comum.
Se sua rede on-premises usa 10.0.0.0/8 e sua VNet do Azure tambem cai nesse intervalo, a conectividade hibrida via ExpressRoute ou VPN falhara. Reconcilie seu plano de enderecos com o IPAM corporativo antes de criar VNets.
O Peering nao e transitivo. Se VNet A faz Peering com VNet B e VNet B faz Peering com VNet C, o trafego entre A e C nao flui automaticamente. Crie um Peering direto entre A e C, ou configure uma VNet hub com 'Allow Gateway Transit' no hub e 'Use Remote Gateways' no spoke.
Em configuracao Dual-Stack, ambas as VNets devem ter espaco IPv6 atribuido. Se apenas um lado tiver IPv6, os pacotes nao atravessarao o Peering.
Cenarios Reais: Erros em Sub-redes e Esgotamento de Saida
Uma equipe tentou colocar 30 VMs em uma sub-rede /27. Com 5 IPs reservados subtraidos de 32, apenas 27 enderecos ficam disponiveis, deixando 3 VMs sem IP. A correcao exige recriar a sub-rede como /26 (59 IPs utilizaveis) do zero — nao existe redimensionamento em operacao.
Centenas de VMs compartilhando um unico IP publico comecaram a enfrentar esgotamento de SNAT porque as Regras de Saida pre-alocam portas fixas por VM. Adicionar um NAT Gateway a sub-rede resolve imediatamente: ele aloca portas de forma dinamica, tornando o esgotamento quase impossivel.
Quando uma questao menciona 'esgotamento de SNAT', 'limite de portas de saida' ou 'grande numero de VMs conectando-se a internet', a resposta correta e NAT Gateway.
Resumo do Exame
"IPs reservados sao 5 por sub-rede — calcular enderecos utilizaveis" -- Subtrair 5 do total (/27 = 32 - 5 = 27 utilizaveis) "Nome de sub-rede dedicada para Azure Firewall" -- AzureFirewallSubnet (minimo /26) "Sub-rede dedicada para gateways VPN e ExpressRoute" -- GatewaySubnet "Permitir que um servico PaaS injete sua NIC em uma sub-rede" -- Subnet Delegation "Prevenir esgotamento de portas SNAT para saida em larga escala" -- NAT Gateway "Portas SNAT por IP em um NAT Gateway" -- 64,512 por IP, ate 16 IPs associaveis "NAT Gateway vs Regras de Saida do Load Balancer, qual tem prioridade?" -- NAT Gateway tem precedencia "Comportamento de entrada padrao do Standard Public IP" -- Negado por padrao, NSG deve permitir explicitamente "Qual SKU suporta IP Publico redundante por zona?" -- Apenas SKU Standard "Blocos CIDR sobrepostos entre duas VNets causam o que?" -- Peering de VNet fica bloqueado "Peering nao transitivo, como resolver A-C sem Peering direto?" -- VNet hub com Gateway Transit e Use Remote Gateways "Requisito de Peering Dual-Stack" -- Ambas as VNets devem ter espaco de enderecos IPv6 atribuido
VNet = limite de isolamento regional, NAT Gateway = pool de SNAT de saida escalavel, Subnet Delegation = permissao de injecao de NIC para servicos PaaS