O ponto não é “perder internet” no Azure. O ponto é que o outbound deixa de ser implícito em redes novas e passa a exigir desenho explícito de egress.
Durante muito tempo, muita VM em Azure saía para a internet sem que isso tivesse sido realmente desenhado. O ambiente funcionava porque o default outbound access resolvia o tráfego de saída de forma implícita. A partir de 31 de março de 2026, isso muda para novas VNets: o Azure passa a criar subnets privadas por padrão, e o outbound implícito deixa de ser fornecido automaticamente. A recomendação oficial passa a ser usar um método explícito de saída, como NAT Gateway.
O efeito prático dessa mudança é simples: em ambientes novos, o time de arquitetura precisa decidir como o workload sai, por onde sai e com qual controle isso acontece. O legado não é alterado automaticamente, mas o padrão para novos ambientes fica mais explícito e mais alinhado com governança.
- Em novas VNets pós-31/03/2026, o outbound deixa de ser implícito.
- NAT Gateway é a melhor resposta para muitos cenários de egress simples e previsível.
- Em arquiteturas com firewall centralizado, ele pode complementar o firewall, não substituí-lo.
- Em vWAN, o posicionamento muda.
Atenção operacional
Em subnets privadas, alguns serviços deixam de funcionar sem outbound explícito, como Ativação do Windows e Windows Update. Além disso, ao converter uma subnet existente para privada, as VMs precisam ser paradas e desalocadas para que a mudança entre em vigor nas interfaces de rede.
Onde o NAT Gateway entra
O NAT Gateway passa a ganhar mais importância porque ele é o método recomendado pela Microsoft para conectividade de saída para a internet. Ele opera no nível da subnet, não exige rota adicional para começar a funcionar, fornece IP público estático, suporta até 16 IPs públicos e pode atender várias subnets da mesma VNet. Além disso, ele permite apenas tráfego de retorno relacionado a conexões iniciadas de dentro para fora.
Esse ponto é importante em ambiente enterprise porque simplifica allowlists, integrações com parceiros, troubleshooting e previsibilidade de egress. Em vez de depender de um comportamento implícito da plataforma, a saída passa a ser um componente desenhado.
NAT Gateway como padrão de egress explícito para workloads privados em Azure.
Precisa de um NAT Gateway por subnet?
Não. A associação do NAT Gateway é feita na subnet, mas o mesmo NAT Gateway pode atender múltiplas subnets dentro da mesma VNet. Segundo a FAQ oficial, ele pode ser associado a até 800 subnets em uma única VNet. Por outro lado, ele não pode ser compartilhado entre múltiplas VNets, e cada subnet aceita apenas um NAT Gateway.
Então, em ambientes com dezenas ou centenas de subnets, a pergunta correta não é “quantos NAT Gateways por subnet”. A pergunta correta é: qual é o domínio de egress que faz sentido para cada VNet ou para cada arquitetura de hub-and-spoke? Em muitos casos, um único NAT Gateway por VNet já atende bem. Em outros, o padrão mais forte é centralizar o egress no hub.
E quando já existe firewall enterprise, como Palo Alto, Check Point ou Fortinet?
Se o firewall de mercado já é o ponto central de inspeção, roteamento e saída para internet, o NAT Gateway não é automaticamente obrigatório. Ele passa a ser uma decisão de arquitetura. Você usa NAT Gateway quando quer desacoplar o SNAT do firewall, ampliar a escala de saída, melhorar previsibilidade de IP público ou simplificar o tratamento de conexões de retorno. A arquitetura de alta disponibilidade com NVA da Microsoft mostra exatamente esse padrão: spokes enviam o tráfego ao NVA por UDR, o NVA sai para a internet via NAT Gateway, e o retorno volta para a mesma instância do NVA.
Ou seja:
firewall decide a política e faz a inspeção;
NAT Gateway pode assumir o papel de egress/SNAT em escala.
Para Palo Alto Cloud NGFW, a própria Microsoft documenta que ele suporta arquiteturas hub-and-spoke e Virtual WAN, o que reforça que o tema principal não é a marca do firewall, e sim o desenho de roteamento, inspeção e saída.
Se já tem firewall, ainda precisa de NAT Gateway?
Depende do papel do firewall.
Se o seu firewall já faz egress internet com SNAT próprio, IP público controlado e escala suficiente, você pode operar sem NAT Gateway. Mas, se o objetivo é aumentar escala de saída ou padronizar o egress com menos pressão sobre o firewall, o NAT Gateway passa a fazer sentido como complemento. Isso é particularmente útil em ambientes com alto volume de conexões outbound. A Microsoft destaca que o NAT Gateway é o método recomendado para outbound internet e que ele pode usar até 16 IPs públicos.
O cuidado aqui é de posicionamento. Se você coloca UDR 0.0.0.0/0 para uma appliance, o NAT Gateway na subnet da aplicação deixa de ser o caminho efetivo para internet. Em topologias centralizadas, o desenho correto normalmente é NAT Gateway na subnet de egress do firewall/NVA, e não em toda spoke.
Padrão enterprise: spoke → firewall/NVA no hub → NAT Gateway no subnet de egress → internet.
Como isso fica em landing zones e ambientes grandes
Em landing zones com muitas redes, o tema principal deixa de ser “colocar NAT Gateway em toda parte” e passa a ser padronizar domínios de saída.
Na prática, você tende a ver três modelos:
1. Egress distribuído por VNet
Cada VNet relevante tem seu próprio NAT Gateway associado às subnets que precisam sair para a internet. Funciona bem quando o ambiente quer autonomia por domínio de aplicação.
2. Egress centralizado com Azure Firewall
As spokes usam UDR para o hub, o Azure Firewall faz inspeção norte-sul e leste-oeste, e o NAT Gateway é associado à subnet do próprio firewall para dar escala ao outbound. Esse é um padrão oficialmente documentado.
3. Egress centralizado com NVA/firewall de terceiros
O raciocínio é o mesmo do Azure Firewall: o NVA/firewall concentra a inspeção e o NAT Gateway pode ser usado como camada de saída escalável atrás dele. A arquitetura de alta disponibilidade com NVA publicada pela Microsoft sustenta esse padrão.
Exceção importante para vWAN
O padrão hub-and-spoke com NAT Gateway na subnet do firewall funciona bem em topologias clássicas de hub VNet. Em arquiteturas baseadas em Virtual WAN, porém, o NAT Gateway não é suportado no hub virtual network e deve ser posicionado diretamente nas spoke VNets associadas ao secured virtual hub.
O que realmente muda para a arquitetura
A mudança de 31/03/2026 não obriga todo mundo a comprar NAT Gateway para cada subnet. O que ela obriga é algo mais importante: parar de depender de outbound implícito.
Em ambiente maduro, a decisão passa a ser:
- saída simples e previsível: NAT Gateway;
- saída com inspeção centralizada: firewall/NVA + NAT Gateway opcional como camada de egress;
- forced tunneling para on-premises: o NAT Gateway na subnet da aplicação pode nem participar do caminho.
Tabela rápida de decisão
Para facilitar a leitura, o resumo abaixo mostra onde o NAT Gateway costuma fazer sentido em cada padrão arquitetural.
Conclusão
O artigo não deve vender a ideia de que “todo ambiente com firewall precisa de NAT Gateway”. Isso não é verdade.
A tese mais precisa é outra:
no novo Azure, o outbound precisa ser explícito.
O NAT Gateway é a melhor resposta para muitos cenários.
Em arquiteturas enterprise com firewall centralizado, ele pode complementar o firewall — mas não substituí-lo.
A pergunta agora não é mais se sua rede “tem saída”. A pergunta é se o seu padrão de egress está realmente desenhado, governado e pronto para escalar em ambientes novos.
