Private subnets by default in Azure Virtual Networks: What changed and how to use NAT Gateway

Azure is evolving to better support secure‑by‑default cloud architectures.     

Starting with API version 2025‑07‑01 (released after March 31, 2026), newly created virtual networks now default to using private subnets. This change removes the long‑standing platform behavior of automatically enabling outbound internet access through implicit public IPs, also known as default outbound access (DOA). 

As a result: newly deployed virtual machines will not have public outbound connectivity unless explicitly configured. 

What changed?

Previously, Azure automatically assigned a hidden Microsoft‑owned public IP to virtual machines deployed without an explicit outbound method (such as NAT Gateway, Load Balancer outbound rules, or instance‑level public IPs). This allowed public outbound connectivity without requiring customer configuration. 

While convenient, this model introduced challenges: 

• Security – Implicit internet access conflicts with Zero Trust principles. 

• Reliability – Platform‑managed outbound IPs can change unexpectedly. 

• Operational consistency – VMSS instances or multi‑NIC VMs may egress using different default outbound IPs.

With API version 2025‑07‑01 and later: 

• Subnets in newly created VNets are private by default. 

• The subnet property `defaultOutboundAccess` is set to false. 

• Azure no longer assigns implicit outbound public IPs.

This applies across deployment methods including Portal, ARM/Bicep, CLI, and PowerShell. Portal has started using the new model as of April 1, 2026. 

Note: This change has not yet applied to Terraform. 

Am I impacted by this change?

Existing workloads are not impacted. 

If required, you can still create new subnets without the private setting by choosing the appropriate configuration option during creation. See the FAQ section of this blog for more information. However, we strongly recommend transitioning to an explicit outbound method so that: 

• Your workloads won’t be affected by public IP address changes. 

• You have greater control over how your VMs connect to public endpoints. 

• Your VMs use traceable IP resources that you own. 

When is outbound connectivity required?

If your virtual network contains virtual machines, you must configure explicit outbound connectivity. Here are common scenarios that require it: 

• Virtual machine operating system activation and updates, such as Windows or Linux. 

• Pulling container images from public registries (Docker Hub or Microsoft Container Registry). 

• Accessing 3rd party SaaS or public APIs 

• Virtual machine scale sets using flexible orchestration mode are always secure by default and therefore require an explicit outbound method. 

Private subnets don’t apply to delegated or managed subnets that host PaaS services. In these cases, the service handles outbound connectivity—see the service-specific documentation for details. 

Recommended outbound connectivity method: StandardV2 NAT Gateway

Azure now recommends using an explicit outbound connectivity method such as: 

• NAT Gateway 

• Load Balancer outbound rules 

• Public IP assigned to the VM 

• Network Virtual Appliance (NVA) / Firewall 

Among these, Azure StandardV2 NAT Gateway is the recommended method for outbound connectivity for scalable and resilient outbound connectivity. 

StandardV2 NAT Gateway:

• Provides zone‑redundancy by default in supported regions 

• Supports up to 100 Gbps throughput 

• Provides dual-stack support with IPv4 and IPv6 public IPs 

• Uses customer‑owned static public IPs 

• Enables outbound connectivity without allowing inbound internet access 

• Requires no route table configuration when associated to a subnet 

When configured, NAT Gateway automatically becomes the subnet’s default outbound path and takes precedence over: 

• Load Balancer outbound rules 
• VM instance‑level public IPs 

Note: UDRs for 0.0.0.0/0 traffic directed to virtual appliances/Firewall takes precedence over NAT gateway. 

Flow chart showing priority order for different outbound methods

Migrate from Default Outbound Access to NAT Gateway

To transition from DOA to Azure’s recommended method of outbound, StandardV2 NAT Gateway: 

1. Go to your virtual network in the portal, and select the subnet you want to modify. 
2. In the Edit subnet menu, select the ‘Enable private subnet’ checkbox under the Private subnet section

         Enabling private subnet can also be done through other supported clients, below is an example for CLI, in which the default-outbound parameter             is set to false: 

az network vnet subnet update \ --resource-group rgname \ --name subnetname \ --vnet-name vnetname \ --default-outbound false

     3. Deploy a StandardV2 NAT gateway resource. 

     4. Associate one or more StandardV2 public IP addresses or prefixes.

     5. Attach the NAT gateway to the target subnet.

Once associated: 

• All new outbound traffic from that subnet uses NAT Gateway automatically 

• VM‑level public IPs are no longer required 

• Existing outbound connections are not interrupted 

Note: Enabling private subnet on an existing subnet will not affect any VMs already using default outbound IPs. Private subnet ensures that only new VMs don’t receive a default outbound public IP. 

For step-by-step guidance, see migrate default outbound access to NAT Gateway.

FAQ

1. Will my existing workloads lose outbound connectivity?

No. Workloads currently using default outbound IPs are not impacted by this change. The private subnet by default update only affects:

• Newly created VNets 

• New subnets created using the updated API, 2025-07-01 

• New virtual machines deployed into those subnets using the updated API 

• VMs and subnets using an explicit outbound connectivity method like a NAT gateway, NVA / Firewall, a VM instance level public IP or Load balancer outbound rules is not impacted by this change. 

2. Why can’t my new VM reach the internet or other public endpoints within Microsoft (e.g. VM activation, updates)? 

New subnets are private by default. If your deployment does not include an explicit outbound method — such as a NAT Gateway, Public IP, Load              Balancer outbound rule, or NVA/Firewall— outbound connectivity is not automatically enabled. 

3. My workload has a dependency on default outbound IPs and isn’t ready to move to private subnets, what should I do? 

You can opt-out of the default private subnet setting by disabling the private subnet feature. You can do this in the portal by unselecting the private subnet checkbox: 

Disabling private subnet can also be done through other supported clients, below is an example for CLI, in which the default-outbound parameter            is set to true: 

az network vnet subnet update \ --resource-group rgname \ --name subnetname \ --vnet-name vnetname \ --default-outbound true

4. Why do I see an alert showing that I have a default outbound IP on my VM? 

There's a NIC-level parameter `defaultOutboundConnectivityEnabled` that tracks whether a default outbound IP is allocated to a VM/Virtual                      Machine Scale Set instance. If detected, the Azure portal displays a notification banner and will generate Azure Advisor recommendations about                disabling default outbound connectivity for your VMs / VMSS. 

5. How do I clear this alert?

To remove the default outbound IP and clear the alert:

1. Configure a StandardV2 NAT gateway (or other explicit outbound method).
2. Set your subnet to be private or by setting the subnet property defaultOutboundAccess = false using one of the supported clients.
3. Stop and deallocate any applicable virtual machines (this will remove the default outbound IP currently associated with the VM).  

6. I have a NAT gateway (or UDR pointing to an NVA) configured for my private subnet, why do I still see this alert? 

In some cases, a default outbound IP is still assigned to virtual machines in a non-private subnet, even when an explicit outbound method—such as a NAT gateway or a UDR directing traffic to an NVA/firewall—is configured.  

This does not mean that the default outbound IP is used for egress traffic. 

To fully remove the assignment (and clear the alert): 

• Set the subnet to private 

• Stop and deallocate the affected virtual machines 

Summary

The move to private subnets by default improves the security posture of Azure networking deployments by removing implicit outbound internet access. 

Customers deploying new workloads must now explicitly configure outbound connectivity. 
StandardV2 NAT Gateway provides a scalable, resilient method for enabling outbound internet access without exposing workloads to inbound connections or relying on platform‑managed IPs. 

Learn more 

• Default Outbound Access 

• StandardV2 NAT Gateway 

• Migrate Default Outbound Access to StandardV2 NAT Gateway