Azure has retired default outbound internet access for virtual machines. The change took effect on 31 March 2026 — VMs no longer get implicit outbound connectivity, and any VM that needs to reach the internet now requires an explicit outbound method. This guide explains what changed, the options for replacing default outbound, and how the costs compare.
Timeline note. Microsoft first announced this retirement for 30 September 2025, then postponed it. It applies to VMs created with API versions released after 31 March 2026; existing default-outbound connectivity on older deployments is being wound down. Treat default outbound as gone for anything you build now.
What changed
Azure used to assign a default outbound public IP that gave a VM implicit internet egress. That implicit path is gone. Now:
- New VMs receive no default outbound IP
- Outbound traffic requires an explicit method — NAT Gateway, Azure Firewall, Load Balancer, or a dedicated public IP
The shift affects both cost and operational simplicity, especially for workloads that depend on outbound connectivity.
Why Microsoft made this change
This is a security improvement. Default outbound made accidental exposure easy: a test VM stood up without proper restrictions, a forgotten database reachable on a public IP, SSH or RDP open to brute-force attempts, or “zombie” resources left running with internet exposure. Requiring an explicit outbound path makes exposure a deliberate choice rather than an automatic default.
Why we support it
Cloud environments should be secure by design. Making internet egress something you opt into — and configure on purpose — reduces mistakes and pushes teams toward deliberate architecture. It’s the right default.
Your options
1. Standard public IP
Assign a Standard SKU public IP to individual VMs for direct egress.
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.
2. Azure NAT Gateway
Centralises outbound connectivity for the VMs in a private subnet behind one public IP.
Roughly: a fixed monthly charge per gateway, plus a per-GB data-processing charge.
Good for: keeping VMs private behind a single egress point.
Watch out for: it provides connectivity only — no inspection, no firewalling, no hostname filtering — and it’s Azure-only.
3. Azure Firewall
The cloud-native firewall: L3/L4 control, hostname (FQDN) filtering, and threat intelligence.
Roughly: a fixed hourly deployment charge that adds up to a substantial monthly base, plus a per-GB data-processing charge on inspected traffic.
Good for: centralised, inspected egress when you’re committed to the Azure platform.
Watch out for: the base charge is high for smaller deployments, the per-GB data-processing tax grows with every workload behind it, and it’s Azure-only.
4. Enforza
Combines outbound connectivity with inspection and visibility, on flat per-firewall pricing. You get NAT and firewalling in one place, without the metered data-processing model.
Roughly: a flat per-firewall subscription plus the VM you run it on — and the price doesn’t change with how much traffic you push, how big the VM is, or how many IPs or devices you protect.
You get:
- NAT for outbound connectivity
- L3/L4 firewalling for traffic control
- Identity-aware 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
Capability comparison
| 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 |
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.
Enforza’s flat per-firewall model breaks that 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.
Planning your approach
Before you pick, work through:
- Security requirements. Do you need inspection, hostname filtering, or logging — or just connectivity?
- Traffic volume. How much data crosses the egress point, and how does that interact with per-GB pricing?
- Multi-cloud. Do you need the same control beyond Azure?
- Operations. Console-driven, or policy-as-code through a pipeline?
Conclusion
Retiring default outbound is a meaningful shift, but it’s also a prompt to look hard at your egress architecture. Whether you land on a dedicated public IP, NAT Gateway, the cloud-native firewall, or Enforza, understanding the trade-offs — and especially how each one prices traffic — is what leads to a sensible decision. If you want inspected, filtered egress without the per-GB tax, flat per-firewall pricing is the lever.
