Azure's Default Outbound Internet Is Going Away - What To Do Before March 31

If you deploy VMs in Azure today without any explicit outbound connectivity, they can still reach the internet. Azure quietly assigns them a default outbound IP address behind the scenes. It works, but you have no control over it.

That’s changing. After March 31, 2026, new virtual networks will default to private subnets. VMs deployed into those VNets won’t have any outbound internet access unless you explicitly configure it.

This isn’t a breaking change for existing infrastructure. But if you’re spinning up new environments after the deadline, things will break unless you’ve planned for it.

What actually changes

Today, when you create a VM in a VNet without configuring any outbound method, Azure assigns it a default outbound public IP. This IP is Microsoft-owned, can change without notice, and isn’t something you control. But it works for basic scenarios.

After March 31, new VNets created using API versions released after that date will have defaultOutboundAccess set to false by default. VMs in those subnets simply won’t have internet access unless you do something about it.

Existing VNets and subnets are unaffected. This only applies to newly created resources.

What breaks without outbound internet

If your VMs can’t reach the internet, a few things stop working:

Windows Activation - Windows VMs need to reach Microsoft’s activation servers. Without outbound access, activation fails and you get that lovely “Activate Windows” watermark (or worse, the VM becomes unusable after the grace period).

Windows Update - No outbound means no patches. Your VMs will fall behind on security updates.

Intune sync - If you’re managing devices through Intune, they need to reach Microsoft endpoints. No connectivity, no policy sync.

Package managers - Ubuntu’s apt, RHEL’s yum, anything that pulls packages from the internet won’t work.

Application telemetry - Application Insights, Log Analytics, anything that sends data to Azure services over public endpoints.

Your options for explicit outbound connectivity

Microsoft wants you to use one of these explicit methods instead of relying on the default:

1. NAT Gateway

This is Microsoft’s recommended approach for most scenarios. You attach a NAT Gateway to your subnet, and all outbound traffic flows through it using a dedicated public IP (or IP prefix) that you control.

Pros:

• Simple to set up
• Predictable, static outbound IP(s)
• Scales automatically
• No changes needed to VMs

Cons:

• Costs money (~$32/month plus data processing)
• One more resource to manage

When to use it: Most production workloads. It’s the cleanest solution.

2. Public IP on the VM

You can assign a public IP directly to the VM’s NIC. Outbound traffic uses that IP.

Pros:

• Simple
• No extra resources

Cons:

• VM is now directly exposed to the internet (inbound too, unless you lock down NSGs)
• Doesn’t scale well for multiple VMs
• Each VM needs its own public IP

When to use it: Jump boxes, dev VMs, single-server deployments.

3. Azure Firewall / NVA with route table

You can route all outbound traffic through Azure Firewall or a third-party network virtual appliance (Palo Alto, Fortinet, etc.) using a route table.

Pros:

• Full visibility and control over outbound traffic
• Can inspect, filter, and log everything
• Centralised egress for multiple VNets

Cons:

• Complex to set up
• Expensive (Azure Firewall Standard starts at ~$900/month)
• Adds latency

When to use it: Enterprise environments with security/compliance requirements.

4. Load Balancer with outbound rules

If your VMs are behind a Standard Load Balancer, you can configure outbound rules to provide internet access.

Pros:

• Often already in place for inbound traffic
• No extra resources if you’re already using an LB

Cons:

• Requires a load balancer (costs money if you don’t already have one)
• Configuration is less intuitive than NAT Gateway

When to use it: When you’re already using a Standard LB for other purposes.

How to check your current state

Want to see if your existing subnets are already private? Check the defaultOutboundAccess property:

Azure CLI:

az network vnet subnet show \
  --resource-group <rg-name> \
  --vnet-name <vnet-name> \
  --name <subnet-name> \
  --query defaultOutboundAccess

If it returns null or true, you’re using the default (soon-to-be-deprecated) behaviour. If it returns false, the subnet is already private.

How to prepare

1. Audit your deployment pipelines

Check your ARM templates, Bicep files, Terraform configs. Are they explicitly configuring outbound connectivity? If not, deployments after March 31 will create broken VMs.

2. Pick your outbound method

For most workloads, NAT Gateway is the right choice. It’s simple, reliable, and gives you a predictable outbound IP.

3. Update your IaC templates

Add NAT Gateway (or your chosen method) to your templates now. Don’t wait until something breaks in production.

4. Test with private subnets

You can opt in to private subnets today by setting defaultOutboundAccess: false on a subnet. Test your workloads to make sure they still function.

Bicep example: VNet with NAT Gateway

Here’s a minimal Bicep template that creates a VNet with a NAT Gateway attached:

param location string = resourceGroup().location
param vnetName string = 'vnet-main'
param subnetName string = 'snet-default'

resource publicIp 'Microsoft.Network/publicIPAddresses@2023-11-01' = {
  name: 'pip-natgw'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
  }
}

resource natGateway 'Microsoft.Network/natGateways@2023-11-01' = {
  name: 'natgw-main'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIpAddresses: [
      {
        id: publicIp.id
      }
    ]
  }
}

resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: '10.0.0.0/24'
          natGateway: {
            id: natGateway.id
          }
          defaultOutboundAccess: false
        }
      }
    ]
  }
}

The bottom line

This change is coming whether you’re ready or not. The good news is that it only affects new VNets created after March 31, so your existing infrastructure keeps working.

But if you’re deploying new environments - dev/test, new projects, disaster recovery sites - you need explicit outbound connectivity in your templates. NAT Gateway is the simplest answer for most cases.

Don’t wait for a production outage to remind you. Update your templates now.