Azure retires default outbound access and your VMs need explicit egress

I've lost count of how often I've found Azure VMs with internet access nobody knew about, mostly in dev, test and quick-migration setups. The cause is nearly always default outbound access. Any VM in a VNet without an explicit outbound configuration quietly gets a public IP for internet egress, even if there's no NAT Gateway, no public IP, no Load Balancer and no firewall in place. That is going to change. Microsoft has announced that default outbound access will be retired for new VNets from 30 September 2025. After the retirement, Azure will no longer hand VMs internet access in the background unless you configure it explicitly.

Default outbound access quietly gives your VMs a public IP

Until now, if you deployed a VM to a subnet in Azure without a defined outbound path, Azure assigned it a dynamic public IP for outbound connections without you ever having to think about it. Convenient, yes, but it causes real trouble. You can't control which egress IPs are used, they can change without notice, and anyone maintaining firewall allowlists or API whitelisting ends up seeing random source IPs. The official docs cover the details.

I run into this all the time, in small test VNets, in migration projects and occasionally in production. Teams often have no idea they depend on default outbound access until something breaks or an audit turns up an unexpected IP. Once the cutoff date has passed, new VNets won't get this implicit internet access at all. If your workloads need to reach the outside world, start planning now.

Azure supports four explicit outbound methods

From now on, any VM or app that needs internet access has to use one of four supported methods, and you have to configure it yourself:

• Assign a public IP directly to the VM's NIC (only for niche scenarios)
• Attach a NAT Gateway to the subnet, which is the best way to get stable, static egress IPs
• Set up a Standard Load Balancer with outbound rules (Outbound Rules)
• Route outbound traffic through Azure Firewall or a Network Virtual Appliance (NVA) using a user-defined route (UDR)

The right choice depends on your security, network and cost requirements. In most production environments I'd go with NAT Gateway or Azure Firewall. Keep in mind that a NAT Gateway isn't done once it's attached to a subnet. You also have to check NSGs and route tables so that outbound traffic is allowed where you need it. For the details, the NAT Gateway overview is very helpful.

If you need fixed egress IPs for firewall allowlists, SaaS APIs or partners, you have to move off default outbound access anyway. Start going through your subnets and writing down your outbound dependencies now.

Azure Advisor and Resource Graph show which subnets still rely on it

First you need to know where the problem is. Microsoft gives you two ways to find out. Azure Advisor flags resources that rely on default outbound access, but Azure Resource Graph Explorer gives you a much fuller view. This sample query lists subnets that still use default outbound access:

Resources
| where type == "microsoft.network/virtualnetworks/subnets"
| extend props = properties
| where isnull(props.privateEndpointNetworkPolicies) or props.privateEndpointNetworkPolicies != "Disabled"
| where isnull(props.natGateway.id)
| where isnull(props.routeTable.id)
| project name, id, properties

Run this in Azure Resource Graph Explorer (requires at least Reader permissions on subscriptions).

You might have to adjust the query to your environment, particularly if you use Load Balancers or Firewalls for outbound traffic. Even so, it quickly shows you which subnets haven't switched to explicit outbound yet.

Practical tip: If you use Azure Policy, create a custom audit rule that flags every subnet without a NAT Gateway or a firewall. That way you catch problems before they turn into incidents.

A new subnet property disables default outbound access

Along with the retirement announcement, Azure is adding a defaultOutboundAccess property for subnets. Setting it to false means the subnet gets no implicit internet egress, even in older VNets. I like it as a way to rule out surprises ahead of time. Include the setting in your ARM or Bicep templates when you define subnets:

{
  "name": "app-subnet",
  "properties": {
    "defaultOutboundAccess": false
  }
}

Example ARM template snippet for a private subnet.

Azure checks the subnet configuration to decide how traffic leaves

This diagram shows the logic Azure follows for outbound flows:

flowchart TD
    VM["VM sends traffic"] --> Subnet["Subnet checks outbound method"]
    Subnet -->|"NAT Gateway present"| NAT["NAT Gateway handles egress"]
    Subnet -->|"Public IP on VM"| PublicIP["Public IP handles egress"]
    Subnet -->|"Load Balancer outbound rule"| LB["Load Balancer handles egress"]
    Subnet -->|"UDR to firewall/NVA"| FW["Firewall/NVA handles egress"]
    Subnet -->|"No method"| Default["Default outbound access (retiring)"]

Figure: Outbound flow decision for Azure subnets depending on configuration.

If none of the explicit methods is configured, outbound traffic simply stops working. After 2025 there's nothing to fall back on.

I would not wait until the deadline to fix this

In most tenants I review, nobody has noticed this yet. It only comes up when a new VNet is deployed and internet access suddenly fails, or when a partner complains about changing egress IPs. I see the retirement of default outbound access as a good reason to take stock and update your documentation. My advice is to audit your subnets now, document your outbound flows and start moving to NAT Gateway or a firewall wherever you need external connectivity. That saves you hectic troubleshooting next year, and your Azure workloads end up more secure and more predictable.