Designing Azure Networks That Scale: From Small Deployments to Enterprise-Grade
Hello Folks! If you have ever spent a long afternoon untangling overlapping CIDR ranges, chasing down a broken VNet peering, or trying to remember which UDR points to which firewall, this MAIS 2026 session is going to feel uncomfortably familiar. Jon Ormond (Principal PM, Azure Networking) brought along Jay Li and Jeff Lovett from the Azure Networking team to walk through what actually happens when an Azure network grows from a handful of VNets into a real enterprise estate, and where most teams hit the wall. The headline they kept coming back to is simple. Azure networks do not usually fail because they were built wrong on day one. They fail because they did not evolve fast enough. Scale is not a smooth ramp. It is a step function, and every step adds an order of magnitude of complexity. Why IT Pros Should Care You may be running three VNets today. That is fine. But the day a second team shows up, or you cross into a second region, or somebody asks for hybrid connectivity to the datacenter, your operating model changes whether you planned for it or not. The session is built around two pivots every growing Azure environment hits: Management and control inside Azure (VNets, peerings, routes, security rules). Connectivity and hybrid (VPN, ExpressRoute, Virtual WAN, reliability). Both of those break quietly. By the time you notice, you are already firefighting drift, broken peerings, or unpredictable latency from on-prem. Bottom line, here is what you take away: Design for the next stage, not the one you are in. Put the management layer in before complexity outpaces manual effort. Treat reliability as a design choice, not an afterthought. Start Small, Plan to Grow One VNet, one subnet, one workload. Nothing wrong with that. You can manage it with the portal, a spreadsheet for CIDR tracking, and a calm heart. The problem is that the jump from “one VNet” to “a few VNets across teams” is not gradual. As soon as you have a second team that needs isolation, you are into hub and spoke territory. Ten spokes feels manageable. Fifty spokes across multiple subscriptions does not. And by the time you hit a hundred, the spreadsheet is a liability. Jay made the case that the smartest move at small scale is not to stay manual until it hurts. It is to put Azure Virtual Network Manager (AVNM) in early, even if you only have three VNets. AVNM lets you declare intent once and let the platform handle the rest: IP address management (IPAM) so new spokes get non-overlapping CIDRs automatically. Network groups with tag-based dynamic membership so VNets land in the right group the moment they exist. Connectivity (hub and spoke or mesh) without hand-built peerings. Security admin rules pushed centrally across the estate. Routing intent so traffic flows through the right firewall by default. The honest tradeoff: AVNM is one more thing to learn and operate, and it adds cost. The counter-question Jay kept asking is, “What is the cost of drift?” One overlapping CIDR or one missing UDR at 100 VNets can cascade into an outage that takes days to unwind. That is the real tradeoff. Mid-Stage Patterns: Hub and Spoke, Peering, and the First Cracks The hub and spoke topology is the workhorse of Azure networking and the pattern the Cloud Adoption Framework recommends for most enterprises. It centralises shared services (firewall, DNS, ExpressRoute and VPN gateways, Private DNS zones) in a hub VNet, and connects spoke VNets through peerings. Where teams get into trouble at this stage: Peering sprawl. Every new spoke needs a peering, sometimes two if you want transitive paths. Doing this by hand across subscriptions is where human error lives. Route table drift. UDRs copied from spoke to spoke get out of sync. One spoke routes through the firewall, another bypasses it. Now you have a compliance problem. Security rule drift. NSGs and security policies start as a copy paste exercise and end as a forensic exercise. CIDR collisions. “Just give me a /24” turns into a multi day investigation when the new spoke overlaps with on-prem. Jay’s point on this was sharp. The mistake is not the topology. Hub and spoke is the right pattern. The mistake is staying manual on top of it. AVNM network groups let you say, “any VNet tagged environment=production joins the production group, gets the production security baseline, peers to the production hub, and inherits the routing intent that sends east-west traffic through the firewall.” No tickets, no copy paste, no drift. If you are already deployed via Azure Landing Zones (ALZ) with Bicep or Terraform, AVNM is not a replacement, it is another construct in your template. As Jon put it in the chat, it is “just another object” in your ALZ, and the two layers work together rather than competing. Enterprise Scale: Virtual WAN, Segmentation, and Governance At some point hub and spoke stops scaling cleanly. You start adding regions. Branch offices show up. You need SD-WAN integration, more than 30 IPsec tunnels, or transitive routing between VPN and ExpressRoute. That is when Microsoft pushes you toward Azure Virtual WAN. Virtual WAN is a Microsoft managed global transit network. You deploy regional virtual hubs and connect everything (Azure VNets, branches, remote users, ExpressRoute circuits) into them with consistent routing and security. The trade up is real: Any to any connectivity by default. Hub to hub mesh is built in. Routing intent and policies for centralised internet egress and east-west inspection through Azure Firewall or a partner NVA in a secured hub. Branch scale. Tens or hundreds of sites stop being a custom integration project. Operational simplification. Microsoft owns the hub control plane so you stop babysitting peerings. For hybrid connectivity itself, Jeff walked the curve every customer travels: VPN Gateway is the on-ramp. Cheap, fast to stand up, good enough until public internet latency, throughput, or regulatory requirements force a change. ExpressRoute circuits give you dedicated bandwidth from 50 Mbps to 100+ Gbps, with predictable performance and over 200 service providers worldwide. Scalable ExpressRoute virtual network gateways grow and shrink with usage, so you deploy once and stop re-architecting every time traffic changes. ExpressRoute Metro is the headliner. Same price as a standard circuit, but the redundant device lives in a second, physically distinct co-location facility across town. Building fire, flood, or power outage in one site, and your traffic keeps flowing. Multiple circuits are still on the table when “this cannot fail” actually means it cannot fail. Honest tradeoff on Virtual WAN: it is opinionated, Microsoft managed, and you give up some of the granular control you have in a customer managed hub. For most enterprises that is a win. For the few with very specific routing requirements or heavy NVA investments, traditional hub and spoke with Azure Route Server can still be the right call. The CAF guidance lays this out in detail. Getting Started If you take one thing from this session, take this. Design for the next stage. Three concrete moves: Stand up AVNM now, even at small scale. Declare your intent for IPAM, connectivity, security, and routing once. Let new VNets inherit it. Pick your topology with eyes open. Hub and spoke for customer managed control, Virtual WAN for Microsoft managed global transit at scale. The CAF decision tree is the right starting point. Plan hybrid for failure, not for the sunny day. ExpressRoute with Metro by default. Multiple circuits for the workloads that genuinely cannot go down. Test the failover. Resources Azure Virtual Network Manager overview Azure ExpressRoute introduction About ExpressRoute virtual network gateways About Azure VPN Gateway About Azure Virtual WAN Hub-spoke network topology in Azure Define an Azure network topology (Cloud Adoption Framework) Virtual WAN network topology in an Azure landing zone Watch the Rest of the Summit This was one of many great sessions at the Microsoft Azure Infra Summit 2026. If you want to catch the keynotes, the deep dives on storage and AKS, and everything in between, the full playlist is here: Microsoft Azure Infra Summit 2026 Playlist Big thanks to Jon Ormond for moderating, and to Jay Li and Jeff Lovett for the practical, no-fluff walk through what actually breaks at scale and how to design ahead of it. Cheers! Pierre Roman
