- Christos Panagiotidis
- Aug 27
- 4 min read
Azure has been nudging us toward explicit egress for years, and now the nudge becomes a rule. After September 30, 2025, newly created virtual networks will default to private subnets. That means no more implicit, Microsoft-owned ephemeral egress IP for virtual machines that didn’t get a public IP, load balancer outbound rule, or NAT gateway. In other words, your new default is “no internet unless you choose it.” For security purists, that’s the right default. For everyone else, it’s a breaking change if you keep building with the assumption that things will “just reach out.” The official guidance is unambiguous: if you want outbound, select an explicit method—NAT Gateway, Standard Load Balancer with outbound rules, a directly associated public IP on a NIC, or a firewall/NVA via UDR—and treat that choice as part of your architecture, not an afterthought.
There are two critical subtleties in the documentation that deserve attention. The first is scope and timing. Existing virtual networks are not retroactively changed, and virtual machines inside those existing VNets continue to use the legacy behavior unless you explicitly flip them to private subnets, so you won’t wake up to a surprise outage in a mature production network. The behavior change applies to VNets created with API versions after the date. If you pin very old API versions in ARM or use older Terraform providers, you can still get the previous default, but that isn’t a strategy—it’s a debt you’ll pay later with interest. The second subtlety is operational. Some configurations quietly relied on default egress, such as a load balancer backend pool configured by IP rather than by NIC, or a UDR pattern that used “Internet” as a next hop for service tag exceptions while a firewall handles 0.0.0.0/0. The doc calls out that these will not work in private subnets unless you also provide an explicit egress method, and it even notes a known issue with LB backend-by-IP using default outbound access. If you have those patterns, redesign now, not at 2 a.m. during a patch window.
The enterprise-grade fix is simple and boring: associate a NAT Gateway to any subnet that needs outbound to Microsoft services or the public internet, and make that the only path. NAT Gateway gives you stable, customer-owned egress IPs that you can share across subnets and can put on partner allow-lists. It also scales port SNAT well for high-connection workloads, which makes it safer than leaning on a load balancer’s outbound rule for anything but small traffic volumes. When you deploy NAT Gateway, wire it to every subnet that will speak out, not just one of them, so you don’t end up with some VMs still trying the now-disabled default path. If you have a perimeter firewall or NVA, keep that pattern: force default 0.0.0.0/0 through the appliance with a UDR and give the firewall its own explicit egress path. That way your inspection stays intact and you don’t create bypasses while “fixing” egress.
Treat this change as a Zero Trust affordance. Private subnets are the platform leaning in your direction, not working against you. With private-by-default VNets, you reduce the chances of accidental data egress, you remove mystery IPs from your security logs, and you make cost allocation cleaner because NAT Gateway is a visible, auditable resource with a bill line, not a ghost feature. It also improves reliability: the Microsoft-owned default egress IPs were never guaranteed to be stable, which meant that partner allow-lists could silently fail when those IPs rotated. With NAT Gateway, you pick your IP, you hold it, and your partners know what to expect. If you need a quick win to show leadership the value of the change, create a short report listing every workload that currently depends on implicit egress, the path you will implement (NAT vs. firewall), and the external services affected by the new stable IPs. That report becomes an allow-list update plan and a stakeholder communication list in one.
Mixed estates deserve special care. If you maintain both classic patterns and modern patterns side by side, make the boundaries explicit. Label subnets with tags that indicate “egress=natgw” or “egress=nva,” and fail deployments that don’t set one. Bake a policy into your environment that denies creating a VM NIC in a private subnet unless at least one explicit egress mechanism exists in the same route context. For scale sets, prefer the flexible orchestration mode, which is “secure by default” and doesn’t secretly pick up default outbound access. Document all of this in your runbook so the next engineer can follow the recipe rather than reverse-engineering route tables at 4 a.m. If you’re in the middle of a Databricks or Synapse migration, remember the compute plane often wants to talk out; pair those subnets with a NAT Gateway too and pin the egress IP in any upstream systems that expect it. The Databricks docs even call out the change directly and recommend explicit outbound for workspaces, which is your sign to fix both app and data planes in one effort.
You don’t need a Hollywood rollout to get this right. Create a tiny VNet in a sandbox subscription with private subnets, attach NAT Gateway, deploy a test VM, and prove outbound to a known endpoint. Then repeat in non-prod and tally every workload that requires partner allow-list updates. Send those updates with specific dates, times, and the exact egress IP values. When you flip production, stop and deallocate the VMs that must pick up the subnet change; the docs note this is necessary for the new behavior to reflect, and you don’t want to be confused when a running VM still uses the old path. Write a PIR-style note after the change and link the doc sections you followed. The result will be dull, predictable egress and a posture that aligns with where Azure is heading next. That’s a good day in ops.
Hero image idea for the post: a neat VNet diagram in neon lines where private subnets glow subtly and only one path to the internet is lit through a NAT Gateway block with a single static public IP hovering above. Alt text: “Private subnets with a single explicit egress path via NAT Gateway after September 30, 2025.”

Comments