VM Default Outbound Access - What's Changing and How to Prepare
Hello guys!
After a period of silence I want to provide you with fresh content out of Azure. Today we're going to talk about the topic "VM Default Outbound Access".
What's changing?
By default, Azure virtual machines (VMs) can currently reach the Internet without you explicitly configuring outbound connectivity. This is called default outbound access and is implemented through a system-managed public IP address.
Microsoft has announced that default outbound access will be retired for new VNets and subnets created using API versions released after March 31, 2026. Instead, those VNets will create private subnets by default — meaning no Internet access unless you configure it explicitly.
Existing VNets and subnets are not affected (for now), but I would strongly recommend planning for migration, as the long-term goal - removing default outbound connectivity entirely - is obviously.
This model is very similar to AWS VPCs, which also support “private subnets” that require explicit outbound connectivity (typically via a NAT Gateway).
- All new VNets created with API versions after March 31, 2026 will have defaultOutboundAccess = false on their subnets (private subnets).
- VMs in these subnets will not have Internet connectivity unless you configure an explicit outbound method.
- Existing VNets and subnets keep their current behavior until you change them.
How I can react on this?
First of all, most customers with a working hub-spoke-design will not have many tasks on this. This regards unconnected scenarios in a hub-spoke-infrastructure (vNets whose are not connected to the hub)
If you don't operate a hub-spoke design or do operate disconnected vNets - with Azure VMs - an explicit outbound connectivity method is required to reach the Internet. This can be one of the following options:
Let's talk a little about these three options:
- Assign a Public IP to a VM's NIC
I (and Microsoft according Cloud Security Benchmark) would not recommend this option. It effectively places your VM directly on the Internet, potentially with only an NSG as protection.
NVAs are a different topic regarding this. They of course are using directly assigned PIPs and also can and should use them for outbound connectivity.
- Load Balancer (Docs)
Even if built as a inbound resource, Load Balancers can also handle outbound traffic.But there are some limitations like:
- The maximum number of usable ephemeral ports per frontend IP address is 64,000.
- The range of the configurable outbound idle timeout is 4 to 120 minutes (240 to 7200 seconds).
- Load balancer doesn't support ICMP for outbound NAT, the only supported protocols are TCP and UDP.
- [...]
It also comes with a higher complexity for configuration, as there are many parameters for SNAT port allocation, session timeout, use of associated PIPs.
- NAT Gateway (Docs)
This is Microsoft's best solution for providing private subnets with a outbound internet access.
NAT Gateways exclusively handles outbound traffic and cannot forward or receive inbound packets (except of responses to outbound connections)
They allow you to SNAT your traffic via a dedicated PIP or a Public IP Prefix.
You can assign up to 16 PIPs via a Public IP Prefix and reach up to 50 Gbps bandwidth.
What happens to my connected vNets?
Nothing. This only affects direct internet access from vNets without any outbound route. If you're using a classic hub spoke design and UDRs are configured to route your traffic through an NVA or Azure Firewall, you'll not face any issues.
1. UDR to next hop Virtual appliance or virtual network gateway
2. NAT Gateway
3. Instance-level public IP address on a virtual machine
4. Load Balancer outbound rules
5. System default outbound rule (= blackhole for private subnets)
Ensure your either configure your Azure Firewall/NVA to handle the entire traffic (inspection) or you need to deploy a outbound access device (NAT GW, LB, PIP) to access these resources.
How can I check if I have affected vNets?
I wrote a PowerShell script to check whether your VNets contain subnets that meet the following criteria:
- No dedicated outbound device (NAT-GW, LB) AND
- VM-NICs included without directly attached PIP
noplacelikecloud
After you have identified all VNets with active default outbound access, plan to migrate them.
Also remember to update your Terraform or Bicep templates, used to deploy new spokes in your infrastructure:
resource "azurerm_virtual_network" "example" {
name = "example-network"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
address_space = ["10.0.0.0/16"]
dns_servers = ["10.0.0.4", "10.0.0.5"]
subnet {
name = "subnet1"
address_prefixes = ["10.0.1.0/24"]
default_outbound_access_enabled = false
}
subnet {
name = "subnet2"
address_prefixes = ["10.0.2.0/24"]
security_group = azurerm_network_security_group.example.id
default_outbound_access_enabled = false
}
tags = {
environment = "Production"
}
}
resource symbolicname 'Microsoft.Network/virtualNetworks@2024-10-01' = {
extendedLocation: {
name: 'string'
type: 'string'
}
location: 'string'
name: 'string'
properties: {
addressSpace: {
addressPrefixes: [
'string'
]
}
subnets: [
{
id: 'string'
name: 'string'
properties: {
addressPrefix: 'string'
addressPrefixes: [
'string'
]
defaultOutboundAccess: bool
natGateway: {
id: 'string'
}
]
}
}
mumian
