Action recommended: Transition to a new method of internet access for your VMs in Azure

Question

You're receiving this notice because you're associated with one or more Azure subscriptions that use virtual machines (VMs) in Azure with default outbound access.

How to check which VM has default outbound access

Any VM that requires public endpoint access in a private subnet will need to use explicit outbound connectivity methods such as Azure NAT Gateway, Azure Load Balancer outbound rules, or a directly attached Azure public IP address. This change does not affect existing virtual networks, including any new virtual machines deployed within them.

You'll still be able to create subnets without the private setting by choosing the appropriate configuration option during creation. Please note this change only applies to the Azure public cloud**.**

How to get this sorted? Please advice

Cheers

Priya jayaraman

Answer 1

Hello @Priya Jayaraman,

You received this notification because there maybe one or more of your Virtual Machines (VMs) with your subscription/subscriptions who use Azure’s default outbound internet access. This means the VM connects to the internet automatically without an explicitly configured outbound method such as a NAT Gateway, Standard Load Balancer outbound rule, or a Public IP.

Does this impact all of your VMs in the subscription right away?

No, if your VM already has a Public IP, NAT Gateway, or Standard Load Balancer outbound rule, then nothing needs to be changed and if a VM is currently using the default outbound access, it will continue to work for existing VMs.

When to be concerned?

For newly created VMs on or after September 30, 2025, Azure is not providing default outbound internet access and for that Microsoft recommends switching to an explicit outbound connectivity option to ensure reliable and controlled internet access.

What you can do:

Check which VMs or network interfaces do not have: a Public IP a NAT Gateway a Standard Load Balancer outbound rule

For those VMs, plan for one of the below supported outbound options:

• Azure NAT Gateway (recommended when multiple VMs share a subnet
• Standard Load Balancer outbound rule
• Public IP attached directly to the VM

Once one of these is configured, your VMs will automatically stop using default outbound access and this will ensure your VMs continue to have reliable outbound connectivity and remain fully supported.

References:

• https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access?tabs=portal#how-can-i-disable-default-outbound-access
• https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-addresses#public-ip-addresses
• https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections#scenarios
• https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview

Answer 2

To sort this out, plan to move from default outbound access to an explicit outbound connectivity method and, where appropriate, make subnets private so new default outbound IPs are not created.

Recommended approach:

1. Understand what is changing
   • Today, if a VM is in a subnet without an explicit outbound method, Azure assigns a default outbound public IP automatically.
   • This default outbound access is not recommended for production workloads because the IP is Microsoft-owned, can change without notice, and offers limited control.
   • On March 31, 2026, new virtual networks will default to private subnets, where default outbound access is disabled. In those subnets, VMs must use an explicit outbound method to reach the internet or public Microsoft endpoints.
   • Existing virtual networks are not changed automatically; they continue to allow default outbound access unless subnets are manually made private.
2. Decide how each VM should reach public endpoints For each VM that needs outbound internet or public Microsoft service access, choose one of these explicit methods:
   • Azure NAT Gateway (recommended for most scenarios)
   • Standard Load Balancer with outbound rules
   • Directly attached Standard public IP on the VM NIC (recommended only for dev/test or tightly controlled scenarios)
   • Firewall/NVA + User Defined Routes (UDR) if central inspection is required
3. Check which VMs currently use default outbound access Use Azure Advisor in the portal:
   1. Search for “Advisor” in the Azure portal and open it.
   2. Go to Operational Excellence.
   3. Look for recommendations:
      • “Add explicit outbound method to disable default outbound” (for VMs)
      • “Add explicit outbound method to disable default outbound for Virtual Machine Scale Sets”
   4. Open each recommendation to see the NICs/VMs that currently have default outbound enabled.
4. Add an explicit outbound method For each flagged VM/subnet, implement one of the following:
   • NAT Gateway (preferred)
     1. Create a NAT Gateway and associate it with a public IP.
     2. Associate the NAT Gateway with the subnet that contains the VMs.
     3. Ensure there is no conflicting outbound path (for example, if using NAT Gateway, avoid direct public IPs on those VMs when you want all outbound to go via NAT).
   • Standard Load Balancer outbound rules
     1. Create/identify a Standard Load Balancer with a public frontend IP.
     2. Configure outbound rules for the backend pool that contains the VMs.
   • Direct public IP on VM NIC
     1. Attach a Standard public IP to the VM’s NIC.
     2. Use NSGs and firewalls to restrict outbound as needed.
   • Firewall/NVA with UDR
     1. Deploy an Azure Firewall or NVA in a dedicated subnet.
     2. Create a route table with a default route 0.0.0.0/0 pointing to the firewall/NVA (next hop type Virtual appliance).
     3. Associate the route table with the VM subnet.
5. Make subnets private to disable default outbound IPs Once an explicit outbound method is in place for a subnet, make it private so Azure no longer assigns default outbound IPs:
   • Portal
     1. Go to Virtual networks → select the VNet → Subnets.
     2. Select the subnet.
     3. Set Default outbound access to Disabled.
     4. Save.
   • Azure CLI

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

   This sets defaultOutboundAccess = false and prevents creation of new default outbound IPs for VMs in that subnet.
6. Stop/deallocate VMs so changes fully apply
   • When changing a subnet between non-private and private, existing VMs must be stopped and deallocated for the NIC-level parameter to update and for default outbound IPs to be removed or added.
   • This is required both when:
     • Moving from default outbound → private subnet, and
     • Moving from private subnet → default outbound (if ever needed).
7. Be aware of private subnet limitations
   • In a private subnet, default outbound access is not available. Any route with next hop type Internet will fail unless there is an explicit outbound method.
   • Certain services (for example, Windows Activation and Windows Updates) require outbound connectivity; ensure NAT Gateway or another explicit method is in place.
   • VMs in a private subnet can still reach Azure Storage in the same region without explicit outbound, but NSGs should be used to control egress.
8. Plan for the 2026 behavior change
   • For new VNets created after the API change (post–March 31, 2026), subnets will be private by default (defaultOutboundAccess = false).
   • If an environment still depends on default outbound IPs, subnets can be explicitly configured as non-private, but this is not recommended for production.

Summary of actions:

• Identify VMs using default outbound access via Azure Advisor.
• Choose and configure an explicit outbound method (NAT Gateway recommended).
• Set subnets to private (defaultOutboundAccess = false).
• Stop/deallocate existing VMs after subnet changes so NIC settings update.
• Validate that required services (updates, activation, external APIs) work through the new outbound path.

---

References:

• Default outbound access in Azure
• Design virtual networks with Azure NAT Gateway
• Use Source Network Address Translation (SNAT) for outbound connections
• Apply Zero Trust principles to discontinue legacy network security technology
• Create a simplified node communication pool without public IP addresses