How a single subnet property is changing the way we design Azure networks, and why “explicit” is the new default.

/introduction

In our cloud environment, a virtual network (Vnet) is our private little piece of network resource – an isolated address space you can fully control and customize. Within a Vnet, subnets segment that address space into smaller ranges where you can place your workloads like virtual machines in, and to which you could attach controls like Network Security Groups and routing tables to.

For years, atleast in the Azure context, one behaviour of subnets was so quiet that most engineers never thought about it: Any VM you deployed could reach the public internet by default, with no configuration required. Microsoft has now reversed that default.
The mechanism is the Azure Private Subnet – a subnet where outbound internet access is switched off by default.

/traditional Azure subnets: how they worked

A conventional Azure subnet was by default, non-private. When you dropped a VM into it without configurating any outbound method, Azure silently assigned a default outbound access (DOA) IP. A DOA IP is a Microsoft owned public address used to SNAT the VMs outbound traffic to the internet. That existed without us engineers requesting it, it just simply appeared.

Engineers who wanted a controlled egress had some options:

• NAT Gateway – managed, scalable SNAT service attached to the subnet.
• Standard Load Balancers with outbound rules – egress is tied to a load balancers public frontend.
• machine level public IP – a Public IP (PIP) attached to the VMs Network Interface Card (NIC)
• Centralized Routing instance – like a Firewall/virtual appliance in HUB
• Load balancing rules, with DisableOutboundSnat = false

There is a waterfall-graph from Microsoft itself where it shows you how the access was granted (this is the updated version though, you see the last part with defaultOutboundAccess here):

If none of the above existed, previously, Microsoft used DOA for outbound traffic.

/challenges with traditional Outbound Connectivity

This was pretty convenient, but as much as it was convenient there was also real problems to that.

-> Security was a concern. Every VM could reach the internet an their “home” by default, contradicting Zero Trust principles. Malware or misconfigured agent had a readily available exfiltration path through the VM.
-> It was pretty unpredictable. The DOA IP is not customer-owned and it could change without the Engineers notice, possibly breaking allow-lists and partner integrations.
-> Compliance was also a reason, for some security frameworks, an unaudited outbound route is hard to justify.
-> Lack of control in general, because the internet path was implicit, difficult to log etc.

The Industry wanted deterministic egress, a known source IP, an auditable path and a single point for inspection.

Azure Private Subnet Explained

The Azure Private Subnet is simply a subnet where the property defaultOutboundAccess is set to false. With that flag off, Azure no longer assigns the implicit DOA IP, so a VM placed into that Subnet can’t reach the public internet or other public Microsoft endpoints by default, unless you explicitly allow and configure the egress path.

The two milestones that mattered here:

• In 2025, the capability to make your subnet private shipped into generally availability. The property defaultOutboundAccess was usable for everybody, and a lot of teams switched to the new capability right ahead. They switched because:
• After March 31 in 2026, it became the default configuration. From that point on, new Vnets and the Subnets created therefore were private by default – no implicit DOA IP anymore. Also was true for API calls, which then applies across ARM/Bicep, Powershell, CLI etc.

To clarify, existing Vnets are never modified automatically, only newly created Vnets are affected by this change. The “private” does not mean like a conventional “air-gapped” Network. A private subnet still allows intra-Vnet traffic, Vnet peering etc. Only the implicit outbound internet IP disappears with this change.

	Traditional subnet	Private subnet
defaultOutboundAccess	true	false
Outbound internet by default	Yes, with DOA IP	No
Internet egress requires config	No	Yes, through NAT Gateway, LB rules, public IP or Firewall
Aligns with Zero Trust	No	Yes
Intra-Vnet / Peering / priavte endpoints	Works	Works

/network flow comparison

//traditional subnet – implicit egress:

//private subnet – explicit egress via NAT Gateway:

/best practices with Azure Private Subnet

This change rewards an intentional Zero trust posture:

• Make Subnets private by default, treat internet egress as something you grant willingly, not implicitly
• Use a NAT Gateway, Firewalls etc. for outbound where workloads genuinely need internet. Centralize the egress in a hub and spoke topology. Route spoke traffic through Azure Firewall in the hub with user defined routes (UDRs)
• Reach Azure PaaS over Private Endpoints, traffic to storage, key vault, SQL and so on never touches the internet.
• Monitor egress with NSG Flow logs, NAT Gateway metrics, and Firewall logs so any malicious intent is visible

A common reference design: private spoke subnet wit DOA disabled, a default route 0.0.0.0/0 pointing to Azure Firewall in the hub, a NAT Gateway or the firewalls public IP providing the actual egress, private endpoints for every PaaS dependency.

/migration considerations

As previously mentioned, your environment will still keep on working, but new deployments behave differently. So we need to verify before we switch:

• Assess your situation, identifiy which VMs are silently relying on DOA today. These are the ones that will break in a fresh private subnet.
• Provision explicit egress first, create the NAT Gateway or firewall route before you deploy the private subnet.
• Watch your IaC. Older Terraform and ARM API versions still create non-private subnets unless you explicitly mention it. In Terraform use default_outbound_access_enabled = false on azurerm_subnet.
• Test in non-prod to validate if OS updates, agent check-ins and third party calls function as intended after the switch.

/conclusion

For most of Azure’s history, outbound internet “just worked” because every subnet quietly handed the VMs a Microsoft owned DOA IP. It was convenient, but it was implicit, unpredictable and it did bite some modern security expectations like Zero Trust.

Azure private subnets inverted that model, outbound internet is now something you design, not something you inherit by default. New Vnets are private by default, and reaching the internet requires one to deliberately configure it.

For architects, the guidance is straightforward. Treat private subnets as the baseline. Make every egress path explicit and monitored. Prefer Private Endpoints for Azure services. Centralize and inspect internet traffic through a hub. The result is a network that is more predictable, more compliant, and alignes with Zero Trust.

Keep you postet – bye bye, Casi.