Azure default outbound access retirement: what changed, who's affected, and how to migrate

Azure has retired default outbound access for virtual machines — the implicit outbound connectivity that gave a VM a Microsoft-owned public IP it never asked for. The change is no longer an announcement to prepare for: it is live. New virtual networks now default to private subnets, and a VM in a private subnet cannot reach the internet until you add an explicit outbound method. Existing virtual networks are unaffected — which makes them the legacy estate you should now be migrating deliberately.

This guide covers what actually happened and when, exactly who is and isn’t affected, the symptoms when a new VM has no internet access, how to migrate existing VNets off default outbound, and how the replacement options compare — including the one thing most migration guides skip: security.

What actually happened, and when

The timeline matters because most of what ranks for this topic was written before the change landed:

• September 2023 — Microsoft announces “Default outbound access for VMs in Azure will be retired”, initially dated 30 September 2025.
• The retirement is postponed and re-mechanised: instead of a hard cut-off, it ships through Azure’s API versioning. Virtual networks created with API versions released after 31 March 2026 default to private subnets.
• 1 April 2026 — the Azure portal starts creating new subnets as private by default.
• API version 2025-07-01 — the first affected resource API version. VNets created with it (or newer) set the subnet property defaultOutboundAccess: false by default.

So as of today: create a virtual network in the portal, or with a current API version in your pipeline, and its subnets are private by default. A VM deployed there with no explicit outbound configuration cannot reach public endpoints — no package mirrors, no activation, no updates.

One nuance worth knowing: templates and tools pinned to older API versions still leave defaultOutboundAccess unset, which implicitly allows outbound access. That is an escape hatch for an unprepared deployment — not a strategy. Treat default outbound as gone for anything you build now.

Who is affected — and who isn’t

The single biggest point of confusion, judging by what people ask Microsoft Q&A, is whether existing workloads break. They don’t:

• Existing virtual networks: unchanged. Existing VMs — and new VMs deployed into existing VNets — continue to receive default outbound access unless you make the subnets private yourself. Nothing stops working. These are your legacy-to-be-migrated networks, not an outage.
• New VNets (portal since 1 April 2026, or API 2025-07-01+): private subnets by default. New VMs there have no internet until an explicit outbound method exists.
• Virtual Machine Scale Sets in Flexible orchestration: never had default outbound access — they have been “secure by default” all along.
• AKS: cluster egress was already explicit (outboundType of load balancer, NAT gateway or user-defined routing), so supported configurations need no action. From 31 March 2026 AKS no longer supports default outbound access for new managed-VNet clusters.
• PaaS services on delegated or managed subnets: not applicable — the service manages its own outbound connectivity.
• Known issue: load-balancer backend pools configured by IP address still use default outbound access.

”Action recommended: transition to a new method of internet access”

If you received that email or portal notification from Microsoft and are wondering whether your estate is about to break: it isn’t. The notification flags subnets where VMs still rely on default outbound access (surfaced by the NIC-level defaultOutboundConnectivityEnabled flag and Azure Advisor’s “Add explicit outbound method to disable default outbound” recommendation). It is a migration prompt for existing networks, not a breakage warning — but it is a prompt worth acting on, because Microsoft owns those implicit IPs, can change them without notice, and has retired the model for everything new.

New VM has no internet access? The symptoms

If a freshly deployed VM can’t reach the internet in 2026, suspect a private subnet before you suspect NSGs. The tell-tale symptoms:

• Windows activation fails — commonly error 0xC004F074 — because the VM cannot reach the KMS endpoint (azkms.core.windows.net:1688). Windows Update fails the same way. Microsoft documents both as services that don’t function in a private subnet without explicit egress.
• Package installs and outbound API calls time out on Linux VMs that worked identically in an older VNet.
• Routes to Azure Service Tags with next hop Internet stop providing access. The classic pattern of steering service-bound traffic around a firewall with a UDR no longer supplies outbound connectivity on its own in a private subnet.
• A pipeline-created VNet behaves differently from last month’s — check whether the template’s API version crossed 2025-07-01.

Two operational notes: same-region Azure Storage remains reachable from a private subnet even without explicit egress (worth an NSG if that surprises you), and switching an existing subnet to private only takes full effect after its VMs are stopped and deallocated.

Your options for explicit outbound

Microsoft lists four sanctioned methods. In its order:

1. Azure NAT Gateway

Centralises outbound connectivity for a subnet behind one public IP — and it is Microsoft’s recommended default, with the newer zone-redundant StandardV2 SKU positioned for the job.

Roughly: a fixed hourly charge per gateway, plus a per-GB data-processing charge.

Good for: keeping VMs private behind a single egress point, and avoiding the SNAT port exhaustion that dogs load-balancer outbound rules.

Watch out for: it provides connectivity only — no inspection, no firewalling, no hostname filtering — and it’s Azure-only.

2. Standard load balancer with outbound rules

Outbound translation tied to a load-balancer front end.

Good for: estates that already front workloads with a Standard load balancer.

Watch out for: SNAT port allocation is finite and shared; port exhaustion under connection-heavy workloads is a well-worn failure mode, and there is still no filtering.

3. Standard public IP on the NIC

Direct egress for an individual VM.

Roughly: a small fixed monthly charge per static IP, plus per-GB outbound data transfer.

Good for: simple, direct connectivity on small workloads.

Watch out for: it exposes VMs directly unless you wrap them in Network Security Groups, there’s no central management across many VMs, and there’s no traffic inspection or filtering.

4. A firewall or network virtual appliance via a user-defined route

Microsoft’s fourth listed method: route the subnet to an NVA with a UDR. This is where inspected egress lives — either Azure Firewall or a third-party appliance.

Azure Firewall, roughly: a fixed hourly deployment charge that adds up to a substantial monthly base, plus a per-GB data-processing charge on inspected traffic. Full L3/L4 control, FQDN filtering and threat intelligence — at platform prices, on Azure only.

Enforza runs as exactly this method — an NVA reached via a user-defined route — and combines the NAT and the firewall in one appliance at a flat per-firewall price:

• NAT for outbound connectivity
• L3/L4 firewalling for traffic control
• Hostname (SNI/FQDN) filtering for granular domain control
• Full traffic visibility and live log streaming to your own SIEM
• One console across the fleet, or policy-as-code through a GitOps pipeline
• The same firewall whichever cloud you run it on

The part most migration guides skip: the pipe is still unfiltered

Microsoft’s stated rationale for the retirement is security — implicit internet access contradicts Zero Trust principles, and explicit connectivity beats silent defaults. We agree; it’s the right change.

But look at what the standard migration does: it replaces an implicit unfiltered pipe with an explicit unfiltered pipe. A plain NAT gateway inspects nothing, filters nothing and logs no destinations. If a workload is compromised, it exfiltrates through your shiny new explicit egress exactly as it would have through the old implicit one — you’ve made the source IP static, and that’s all.

The migration itself is the cheapest moment you will ever get to fix that, because you are already touching the route tables. Routing the subnet through a secure NAT gateway — a NAT gateway with L3/L4 and FQDN filtering in one — gives you the explicit outbound method Microsoft requires and control over what leaves the network, in the same change window. Allow egress to your package mirrors and APIs by hostname; deny and log everything else.

Migrating legacy VNets deliberately

For the estate that predates the change — still working, still on default outbound — a sensible migration plan looks like:

1. Find the exposure. Azure Advisor flags VMs relying on default outbound (“Add explicit outbound method to disable default outbound”), and the NIC-level defaultOutboundConnectivityEnabled flag shows it per interface.
2. Choose the explicit method per subnet — connectivity-only (NAT gateway) or inspected (NVA via UDR). Decide the security question now, not after the second migration.
3. Make the subnet private as you cut over, so the implicit path is actually closed rather than lingering behind your new route:
   • Portal: subnet → “Default outbound access” → Disabled
   • CLI: az network vnet subnet update ... --default-outbound false
   • ARM/Bicep: defaultOutboundAccess: false on the subnet
   • Terraform: default_outbound_access_enabled = false — noting the provider currently plans this as a subnet replacement even though the underlying API updates in place, so review the plan carefully.
4. Stop and deallocate VMs for the subnet privacy change to take effect, and schedule accordingly.
5. Re-test the awkward cases: Windows activation and updates, service-tag UDRs with next hop Internet, and anything that hard-codes an outbound IP — the default outbound IP was never yours and never stable anyway.

Where the cost goes

The pattern across the cloud-native options is the same: a predictable base charge plus a per-GB data-processing tax that grows with every workload you put behind it. A dedicated public IP is the cheapest line item but gives you no security. NAT Gateway is moderate but inspects nothing. Azure Firewall gives you inspection but carries both a high base and the per-GB tax.

Capability	Standard public IP	Azure NAT Gateway	Azure Firewall	Enforza
Outbound connectivity	Yes	Yes	Yes	Yes
NAT included	No	Yes	Yes	Yes
L3/L4 firewalling	No	No	Yes	Yes
Hostname (FQDN) filtering	No	No	Yes	Yes
Traffic inspection & logging	No	No	Yes	Yes
Flat pricing (no per-GB tax)	Per-GB transfer	Per-GB processing	Per-GB processing	Yes

Enforza’s flat per-firewall model breaks the link between traffic volume and cost: the licence is the same whether you process a hundred gigabytes or a hundred terabytes. For egress-heavy workloads, that’s where the 60–80% saving against the cloud-native firewall comes from.

Common questions

Has Microsoft retired default outbound access, or was it postponed?

Both, in sequence. The original 30 September 2025 date was postponed, and the retirement then shipped through API versioning: virtual networks created with API versions released after 31 March 2026 (the first is 2025-07-01) — and anything created in the portal since 1 April 2026 — default to private subnets. For new deployments, the retirement has happened.

Will this affect VMs created before 31 March 2026?

No. Existing virtual networks are unchanged, and even new VMs deployed into existing VNets keep default outbound access until you make those subnets private. The pressure on existing estates is migration hygiene, not breakage.

Does the retirement affect AKS?

Supported AKS configurations already use an explicit outboundType (load balancer, NAT gateway or user-defined routing), so they need no action. New AKS-managed VNets follow the private-by-default model from 31 March 2026.

Can I just keep using an old API version?

For a while — older API versions still create subnets with implicit outbound allowed. But you’d be building new networks on a model Microsoft has retired, with an outbound IP Microsoft owns and can change without notice. Use the escape hatch to schedule a proper migration, not to avoid one.

Conclusion

The retirement of default outbound access is done deal for anything new, and a migration queue for everything old. Whether you land on a NAT gateway, a load balancer, the cloud-native firewall or an NVA, you now choose your egress path on purpose — and since you’re choosing anyway, it’s worth choosing one that can say no. If you want inspected, filtered egress without the per-GB tax, a secure NAT gateway at a flat per-firewall price is the lever.