Azure Default Outbound Access Retirement: What You Need to Know

Microsoft is retiring default outbound internet access for Azure virtual machines starting September 30, 2025 — a change that might seem minor at first glance, but has significant impact on how outbound connectivity is handled in Azure environments.

Today, there are two main ways a virtual machine can connect to the internet in Azure:

1. Explicit outbound connectivity: This is when you assign a Public IP address directly to the VM’s network interface, or configure a NAT Gateway, Azure Load Balancer with outbound rules, or a Firewall. These methods allow outbound internet access through a known, managed public IP address.

2. Default Outbound Access IP (DOAI): If none of the above are configured, Azure provides internet access by assigning the VM a default outbound IP. This is implemented using Source Network Address Translation (SNAT), and the traffic is routed through a pool of shared Azure-managed public IPs. No setup is required, and the VM has full internet access by default.

The second method—default outbound access—is what’s being phased out. As of September 30, 2025, Azure will no longer assign default outbound access to new VMs created after this date, regardless of VNet creation date. The behaviour is determined at the VM level, not the subnet or VNet level.

Key clarifications:

• Existing VMs (created before cutoff) retain default outbound access

• New VMs (created after cutoff) won’t have outbound access unless explicitly configured

• This applies at VM creation time, not subnet/VNet level

• If you reimage or redeploy a VM after the cutoff, it may lose DOAI unless outbound access is explicitly set

So you are affected only if:

• You create a new VM after Sep 30, 2025

• And you don’t configure any outbound mechanism (NAT, public IP, etc.)

and not affected if:

• Your VM was created before the cutoff

• Or your VM has a public IP or NAT Gateway already configured

Official document: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access

Demonstrating the Behaviour

I have created a setup which shows this behaviour:

• First, a VM (testVM) with Public IP enabled (explicitly created)

  

• Second, a VM without a Public IP (testVM2 - to show that Azure provides a public IP even if we haven’t created/allocated one).

• 

Even without a configured public IP, we observed that the second VM (testVM2) still had outbound internet access via a public IP.

Why the Default Model Is Being Retired

The convenience of automatic internet access comes with trade-offs. Since the default outbound IP is:

• Shared across tenants

• Unpredictable (not assigned to your subscription)

• Unrestricted by default

It poses both security and governance risks. VMs can reach any external destination unless explicitly blocked, which makes it difficult to enforce strict egress controls or meet regulatory standards. There’s also limited visibility and no guarantee of IP stability for allowlisting purposes.

To promote secure design principles such as least privilege and zero trust, Azure is retiring this default behaviour.

What Will Change After September 30, 2025?

Starting with new VM deployments after this date, Azure will no longer automatically provide outbound internet access if you haven’t explicitly configured it.

That means:

• If you don’t attach a public IP, or configure a NAT Gateway or load balancer with outbound rules, your VM will not be able to reach the internet.

• Workloads that rely on outbound access (package downloads, OS updates, API calls, etc.) may fail silently unless the network is reconfigured.

Options for Enabling and Controlling Outbound Access

To maintain secure and controlled internet access, Microsoft recommends using one of the following:

1. NAT Gateway

A NAT Gateway provides outbound internet connectivity for resources in a subnet using a dedicated set of public IPs. It’s scalable, secure, and performs well for most outbound-only use cases. It also allows IP predictability and logging.

2. Azure Load Balancer (with outbound rules)

You can configure outbound SNAT via a Standard Load Balancer. It’s simpler than a NAT Gateway but slightly less flexible in terms of configuration and monitoring.

3. Public IP on the VM

Assigning a public IP directly to the NIC allows the VM to initiate outbound connections. However, this approach is not recommended at scale due to security and manageability concerns.

4. Azure Firewall

This is the most secure and feature-rich option. It supports full outbound filtering, FQDN-based rules, and traffic inspection. It’s ideal for enterprise environments with strict security requirements, but also comes with higher costs and complexity.

Recommendation

Azure recommends NAT Gateway or a Load Balancer. For most scenarios, these provide the right balance between simplicity, cost, performance, and control. Both work at network and transport layers (Layer 3/4) and can be easily integrated into existing VNet architectures. Azure recommends them over heavier options like firewalls or third-party appliances unless deep inspection or advanced filtering is needed.

Using NAT Gateway is straightforward. When you create a NAT Gateway, you can create a new public IP or attach an existing one, and assign it to the subnets you want to associate the gateway with.

In this example, I attached the testVM2 to the NAT Gateway.

When we check the public IP again, we can see the public IP that was associated with the NAT Gateway

Final Thoughts

This is an important change that encourages better security hygiene in Azure environments. While it does add a step to VM provisioning, the long-term benefit is tighter control over your infrastructure’s exposure to the internet. Planning ahead will help avoid last-minute surprises and ensure your workloads continue to function as expected.

If you're working in environments with strict compliance, or you just want to improve your network architecture, this is a good time to start evaluating how outbound access is handled across your VNets.