A arquitetura de nuvem está passando por uma mudança de paradigma rumo a padrões de segurança mais rigorosos. A partir da API version 2025-07-01, o Azure adotou uma postura secure-by-default: novas subnets em Virtual Networks (VNets) são agora privadas por padrão.
Historicamente, o Azure oferecia o comportamento de Default Outbound Access (DOA), que concedia, de forma implícita, acesso à internet via um IP público gerenciado pela própria plataforma, caso nenhum outro método fosse configurado. Esse "atalho" de conectividade, embora facilitasse o deployment rápido, entrava em conflito direto com os princípios de Zero Trust e criava imprecisões no controle de tráfego.
O que mudou na prática?
Com a atualização, o modelo padrão foi removido. Novos deployments de Virtual Machines (VMs) dentro de novas subnets não terão conectividade outbound com a internet a menos que você configure explicitamente uma solução. O Azure não atribui mais IPs públicos implícitos para o tráfego de saída.
As implicações técnicas são claras:
- Segurança: Garante que apenas recursos autorizados tenham saída para a internet.
- Confiabilidade: Elimina a dependência de IPs de saída gerenciados pela plataforma, que podiam sofrer mudanças inesperadas, prejudicando integrações e whitelisting em firewalls de terceiros.
- Consistência Operacional: Evita que instâncias dentro de um Virtual Machine Scale Set (VMSS) ou VMs multi-NIC utilizem IPs de saída diferentes, simplificando a governança de rede.
Este cenário aplica-se a quase todos os métodos de deployment, incluindo Portal, ARM/Bicep, CLI e PowerShell. Uma observação importante para as equipes de SRE e Infraestrutura: esta mudança ainda não reflete no comportamento padrão do Terraform.
Sou afetado por essa mudança?
É importante destacar que workloads existentes não sofrem impacto. O comportamento default antigo permanece inalterado para VNets já criadas antes da implementação. A mudança afeta:
- Novas VNets criadas com a API 2025-07-01 ou posterior.
- Novas subnets criadas dentro de VNets existentes através dessa versão da API.
- Qualquer VM provisionada nessas novas subnets sem uma configuração outbound explícita.
Por que configurar a conectividade explicitamente?
Se você gerencia VMs, precisará garantir o outbound traffic para tarefas triviais como o patching do SO (Windows Update/Linux repos), pulling de container images de registries públicas como Docker Hub ou o consumo de APIs externas e SaaS. O Azure recomenda, para casos de alta escala e resiliência, o uso de StandardV2 NAT Gateway.
O StandardV2 NAT Gateway entrega:
- Zone-redundancy por padrão (em regiões suportadas).
- Throughput de até 100 Gbps.
- Suporte dual-stack (IPv4 e IPv6).
- Uso de IPs estáticos próprios, permitindo previsibilidade em regras de firewall de destino.
Fluxo de Prioridade
Ao configurar o NAT Gateway, ele se torna o caminho de saída padrão da subnet, superando Load Balancer outbound rules e IPs públicos de nível de instância. A única exceção de prioridade são as User Defined Routes (UDRs) com next hop direcionado a Network Virtual Appliances (NVAs) ou instâncias de Firewall.
Próximos Passos
Para migrar, o processo é direto:
- Certifique-se de que sua infraestrutura IaC prepare o resource de StandardV2 NAT Gateway.
- Associe os IPs públicos (ou prefixos) ao Gateway.
- Aplique a associação à subnet alvo.
Se o seu ambiente possui regras rígidas e você precisa de mais tempo para essa transição, é possível desativar (opt-out) o comportamento de private by default alterando o parâmetro da subnet (default-outbound true), mas recomendamos que o faça apenas como uma medida paliativa temporária. A segurança de network é um dos pilares de uma operação eficiente e resiliente. Mantenha sua arquitetura clean e documentada para evitar downtime desnecessário em futuros deployments.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
