Migrating from MSEE Hairpin Routing to AVNM Mesh for Large-Scale VNet-to-VNet Connectivity
Introduction A common pattern in large Azure deployments is to route VNet-to-VNet traffic through Microsoft Enterprise Edge (MSEE) routers. This happens when spoke VNets in a hub-and-spoke topology communicate with each other by hairpinning through the ExpressRoute circuit: traffic exits the Azure data center, traverses MSEE, and re-enters the data center to reach the destination VNet. This pattern works, but it was not designed as the long-term connectivity model for east-west traffic. With Azure Virtual Network Manager (AVNM) mesh connectivity and recent scale improvements — including high-scale mesh up to 5,000 VNets and High-Scale Private Endpoints (HSPE) up to 20,000 Private Endpoints across connected VNets — enterprises can migrate to a direct, in-datacenter routing model that removes MSEE dependency for VNet-to-VNet traffic. This article explains why the migration is useful, what the new scale limits are, how to enable the required features, and how to execute the migration with minimal disruption. Who This Is For This migration is most relevant if you have 50 or more spoke VNets communicating east-west through ExpressRoute hairpin routing, are approaching VNet peering limits, want to reduce ExpressRoute utilization from internal traffic, or need a simpler centrally managed connectivity model. Even if most east-west flows must continue through a hub firewall for inspection, you can still simplify connectivity management for the flows allowed to go direct. Why MSEE Hairpin Routing for VNet-to-VNet Is Not Recommended When spoke VNets communicate through MSEE, traffic follows a suboptimal path: Spoke A → Hub VNet → ExpressRoute Gateway → MSEE → ExpressRoute Gateway → Hub VNet → Spoke B Single point of failure. MSEE becomes a shared dependency for east-west traffic. An MSEE outage or capacity constraint can affect every VNet pair in the topology. Lower-latency path. Traffic no longer needs to leave the data center and return for spoke-to-spoke communication. Direct mesh keeps east-west traffic on an in-datacenter path, which is generally lower latency than hairpinning through MSEE. Bandwidth constraints. MSEE circuits have finite bandwidth. Routing east-west traffic through them competes with north-south on-premises traffic and can saturate the circuit. Operational risk at scale. Large deployments place significant load on MSEE infrastructure, creating scalability, reliability, and operational concerns for environments with thousands of VNets. Why Manual Peering Was Not a Practical Alternative The obvious alternative — creating direct VNet peerings between every spoke pair — solves the MSEE dependency but introduces its own operational complexity: Combinatorial growth. Connecting N spokes requires N × (N - 1) / 2 peering relationships. For 100 spokes, that is 4,950 peerings. For 1,000 spokes, it is nearly 500,000. Management overhead. Each peering must be individually provisioned, monitored, and maintained. This increases drift, audit, and operational overhead. How AVNM Mesh Solves This AVNM mesh provides group-based connectivity. You define a set of VNets as a network group, apply a mesh connectivity configuration, and AVNM establishes bi-directional connectivity across all members. Traffic between meshed VNets stays within the Azure data center: no MSEE traversal, no hub hop, and no manual peering management. Define once, connect all. A single mesh configuration connects every VNet in the group to every other VNet. Centralized management. Add or remove VNets from the group; AVNM reconciles connectivity automatically. Direct spoke-to-spoke paths. Traffic flows directly between VNets, bypassing both the hub and MSEE. Dynamic membership. Use Azure Policy to auto-enroll new VNets based on tags or resource group conditions. How to Migrate Large Scale Topology High-scale mesh lets user migrate larger topology — up to 5,000 VNets and 20,000 Private Endpoints in a mesh. Scale — Standard Mesh vs. High-Scale Mesh Dimension Standard Mesh High-Scale Mesh VNets per mesh Up to 250 (soft limit, can request increase) Up to 5,000 Private Endpoints per mesh Up to 2,000 Up to 20,000 (with HSPE enabled) Private Endpoints per VNet Up to 1,000 Up to 5,000 (with HSPE enabled) Enabling High-Scale Private Endpoints (HSPE) As a mesh footprint grows, so does the number of Private Endpoints deployed across the connected VNets. The default platform limits — 1,000 Private Endpoints per VNet and 2,000 across connected VNets and mesh — can be reached quickly in large environments. Enabling HSPE raises these limits to 5,000 and 20,000, respectively. For large-scale mesh migrations, enable HSPE proactively if the environment is expected to grow toward standard Private Endpoint limits by following the steps below. Step 1 — Prepare Each VNet Ensure Private Endpoint Network Policies are set to Enabled or RouteTableEnabled on all subnets containing Private Endpoints. This is a prerequisite. Set the VNet-level property PrivateEndpointVNetPolicies to Basic. This activates HSPE on the VNet. Step 2 — Enable HSPE on the Mesh Configuration In the AVNM mesh connectivity configuration, enable the option for high-scale private endpoints. AVNM validates that all VNets in the mesh are HSPE-enabled. If any VNet is missing the configuration, the deployment is blocked with a clear error. Step 3 — Deploy Deploy the connectivity configuration. AVNM applies HSPE across the mesh. Behavior Changes When Enabling HSPE Brief connection reset. Enabling or disabling HSPE triggers a one-time, approximately 1-second connection reset for existing Private Endpoint connections in the VNet. Plan this during a maintenance window. Per-PE Bytes In / Out monitoring is no longer available. HSPE treats each Private Endpoint IP like any other IP in the VNet, which removes per-PE traffic counters. If you depend on per-PE metrics, evaluate alternatives before enabling. On-premises PE traffic billing changes. PE traffic originating from on-premises appears as an aggregate bill on the gateway VNet, not on the individual Private Endpoint resource. The total bill does not change. How to Avoid Downtime Mesh coexists with existing peerings. AVNM does not delete manually created peerings unless explicitly configured to do so. Traffic shifts automatically. Once mesh is deployed, spoke-to-spoke traffic routes directly. The MSEE hairpin path remains available if mesh is removed. No reconfiguration of hub components. Firewalls, gateways, and NVAs in the hub continue to function. North-south on-premises traffic still flows through the hub gateway. Rollback is simple while the legacy path remains. Keep the MSEE hairpin path in place during validation so affected VNets can fall back by removing them from the network group or undeploying the mesh configuration. Security and East-West Traffic Inspection A common concern is whether direct mesh connectivity bypasses hub firewalls or network virtual appliances. The answer depends on how inspection is enforced today. Mesh provides connectivity, not routing policy. If spoke subnets have UDRs that direct traffic through a hub NVA or firewall, those UDRs continue to apply and can keep inspected flows on the firewall path. Security Admin Rules provide centralized segmentation. For flows that do not require firewall inspection, AVNM Security Admin Rules can enforce network-level allow or deny policies across network groups. Use both where appropriate. Mesh can provide direct connectivity for approved flows while Security Admin Rules enforce segmentation boundaries where required. Recommendation: Before migrating, inventory which spoke-to-spoke flows currently traverses the firewall. Decide per flow whether to maintain inspection by keeping UDRs in place or allowing a direct mesh path by removing the UDR for that flow pair. Migration Order and Process The migration from MSEE hairpin routing to AVNM mesh is non-disruptive by design. Mesh connectivity overlays on top of existing peerings and takes routing precedence for east-west traffic. You do not need to tear down the existing hub-and-spoke topology first. Recommended Steps Design the mesh topology. Group VNets by region into mesh groups. If you expect more than 250 VNets per mesh, register the AllowHighScaleConnectedGroup feature in advance. Create a Network Manager and define Network Groups. Ensure that the AVNM scope covers all relevant subscriptions. Use static membership for initial migration or dynamic membership through Azure Policy for ongoing enrollment. Enable HSPE on every VNet in the mesh. Follow the HSPE enablement steps if you need to have more than 2,000 Pes in a mesh. Schedule the change during a maintenance window to account for the brief connection reset. Create the mesh connectivity configuration in AVNM. Select the network groups, enable mesh topology, enable high-scale private endpoints, and enable global mesh if cross-region connectivity is required. Deploy incrementally. Start with a pilot region or non-critical environment. Validate effective routes, spoke-to-spoke connectivity, spoke-to-hub-to-on-premises connectivity, Private Endpoint reachability, and expected VNet flow log patterns before expanding to production regions. Route Behavior During and After Migration During migration, mesh and MSEE can coexist. Mesh-connected VNets receive direct routes for mesh-connected destinations, while existing ExpressRoute gateway routes continue to serve on-premises destinations. UDRs still override system routes, so forced-tunneling and firewall inspection patterns remain in effect when UDRs are present. Mesh destinations. Traffic between mesh-connected VNets goes directly instead of hairpinning through MSEE when no UDR overrides the route. On-premises destinations. ExpressRoute continues to provide north-south connectivity to on-premises networks. Gateway transit. Spokes can continue to reach on-premises through the hub gateway when the design uses gateway transit. Infrastructure-as-Code Considerations If VNet peerings are managed through Terraform, Bicep, or ARM templates, treat AVNM mesh as the new source of truth only after validation. Deploy mesh first. AVNM mesh can coexist with existing peerings, so do not remove peering resources from IaC before validating the mesh path. Validate the traffic path. Use effective routes, Connection Monitor, and flow logs to confirm traffic is using mesh where expected. Guard against drift. Review pipeline state and lifecycle settings before decommissioning old peerings, especially in environments where multiple teams manage network resources. Codify AVNM. Manage the Network Manager, network groups, configuration, and deployment through IaC so mesh becomes the governed connectivity model. DNS Resolution Across Mesh Mesh connectivity does not change DNS resolution behavior by itself. If spoke VNets are already linked to Private DNS Zones hosted or managed through the hub, those links continue to determine name resolution. If spokes use custom DNS servers in the hub, verify that any UDR changes made during migration do not unintentionally alter the DNS traffic path. Migration Example — Two Hub-and-Spoke Topologies into a Single Mesh This example shows how an enterprise can migrate two regional hub-and-spoke environments into one centrally managed AVNM mesh while preserving the existing MSEE path during validation. Current State — Two Hub-and-Spoke Topologies with MSEE Hairpin Contoso Corp operates a large Azure environment in the East US region with two hub-and-spoke topologies: Topology A Topology B Hub VNet Hub-A Hub-B Spoke VNets 500 500 ExpressRoute Gateway ER-GW-A in Hub-A ER-GW-B in Hub-B ExpressRoute Circuit Shared circuit, connected to both gateways Same shared circuit Avg. Private Endpoints per spoke ~8 (4,000 total) ~12 (6,000 total) Total Private Endpoints 10,000 across both topologies How traffic flows today: Spoke-to-spoke within Topology A: Spoke-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-A → Hub-A → Spoke-A-02 Spoke-to-spoke across topologies: Spoke-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-B → Hub-B → Spoke-B-01 Every spoke-to-spoke packet — whether within the same topology or across topologies — exits the data center, traverses MSEE, and re-enters. With 1,000 spokes generating east-west traffic, MSEE becomes a shared single point of failure and adds latency to every flow. Target State — A Single AVNM Mesh with 1,000 VNets Contoso's goal is to consolidate all 1,000 spoke VNets into a single AVNM mesh, removing MSEE from the east-west traffic path. Spoke-to-spoke traffic, any pair: Spoke-A-01 → directly→ Spoke-B-01. Traffic stays in the data center and uses the direct mesh path. MSEE role: MSEE carries north-south on-premises traffic. East-west load is removed from the ExpressRoute hairpin path. Migration Execution Phase 0 — Pre-Work Register the feature. Since the mesh contains 1,000 VNets, above the 250 standard limit, Contoso registers the AllowHighScaleConnectedGroup feature flag on the subscription. This enables high-scale mesh support for up to 5,000 VNets. Inventory Private Endpoints. With 10,000 Private Endpoints across 1,000 VNets, Contoso exceeds the standard mesh Private Endpoint limit of 2,000. HSPE must be enabled. Phase 1 — Enable HSPE on All 1,000 Spoke VNets Batch 1: Enable HSPE on all 500 spoke VNets in Topology A during the maintenance window by following the instructions. Batch 2: Apply the same configuration to all 500 spokes in Topology B. Expected impact: Each VNet may experience a brief connection reset for existing Private Endpoint connections when HSPE is enabled. Schedule the change during a maintenance window. Phase 2 — Create the AVNM Mesh Create a Network Manager scoped to the management group containing all 1,000 spoke VNets. Define a single network group called eastus-mesh-all-spokes with dynamic membership using an Azure Policy and the tags. Create a mesh connectivity configuration. Set topology to Mesh, network group to eastus-mesh-all-spokes, high-scale private endpoints to Enabled, and global mesh to Not needed because all VNets are in the same region. Save the configuration as a draft and do not deploy yet. Phase 3 — Incremental Deployment Wave 1 — Pilot: Contoso deploys the mesh configuration to 50 dev/test spokes, either by using a temporary network group or by tagging only those VNets initially. Validation includes effective routes showing ConnectedGroup as the next-hop type for meshed spoke prefixes, spoke-to-spoke connectivity through the direct mesh path, Private Endpoint reachability across meshed spokes, unchanged on-premises connectivity through the hub and MSEE, and VNet flow logs that confirm expected direct spoke-to-spoke flows. Wave 2 — Light production traffic VNets: After a successful pilot, Contoso tags light production traffic VNets. The dynamic network group picks them up automatically. Contoso redeploys the connectivity configuration, runs the same validation checklist, and monitors traffic to confirm that east-west traffic from these VNets is moving away from the ExpressRoute hairpin path. Wave 3 — All remaining production VNets: Contoso tags all remaining spokes and redeploys the configuration. At this point, all 1,000 spokes are in the mesh. No downtime migration: During Waves 2 and 3, existing MSEE hairpin routing remains functional. VNets not yet in the mesh continue to communicate through MSEE. VNets already in the mesh communicate directly through the mesh. This avoids a planned connectivity gap during migration. Phase 4 — Post-Migration Validation After deployment, confirm that mesh is active and traffic is taking the expected path before decommissioning the legacy route. Effective routes. Verify spoke subnets show direct routes to peer VNet prefixes instead of routing through the gateway or MSEE. Connection Monitor. Track representative spoke-to-spoke flows and compare latency and reachability before and after migration. VNet flow logs. Confirm east-west traffic matches the expected mesh path and is not still traversing the ExpressRoute gateway path. Network Watcher topology. Visualize the resulting connectivity model and identify any VNets not enrolled in the target network group. If traffic is still hairpinning after mesh deployment, check for UDRs overriding system routes, spokes missing from the network group, deployment not committed to the target region, or IaC pipelines recreating legacy peerings. Rollback Quick rollback while MSEE remains in place. Remove affected VNets from the network group or undeploy the mesh connectivity configuration. AVNM removes only the connectivity it created, and traffic can fall back to the existing MSEE hairpin path. Rollback after decommissioning legacy paths. If old peerings or route dependencies have already been removed, rollback may require reprovisioning those resources and should be treated as a longer change window. Recommendation. Keep the MSEE hairpin path available for at least two weeks after mesh deployment, monitor traffic patterns, and only then remove the legacy path. Before and After Summary Metric Before (MSEE Hairpin) After (AVNM HSPE Mesh) Spoke-to-spoke latency in the same region Higher due to the MSEE hairpin path Lower-latency direct in-datacenter path; actual latency depends on workload, region, and network conditions Traffic path for east-west Spoke → Hub → MSEE → Hub → Spoke Spoke → Spoke directly through the Mesh MSEE dependency for east-west Yes, shared dependency No MSEE dependency for east-west traffic Manual peerings required 0 when using hairpin routing, but 499,500 if built manually for 1,000 spokes 0 manual spoke-to-spoke peerings; AVNM manages connectivity Private Endpoints supported 2,000 per mesh under standard limits 20,000 per mesh with HSPE Rollback complexity Not applicable to the current hairpin model Remove VNets from the network group or undeploy the connectivity configuration Migration downtime Not applicable Designed for no planned downtime when deployed incrementally and validated carefully Closing Notes Migrating to AVNM mesh does not require tearing down your existing network. The hub gateway, firewalls, and NVAs continue to function as they do today. What changes is that east-west spoke-to-spoke traffic stops leaving the data center unnecessarily. MSEE is not the right tool for the east-west fabric. Removing internal traffic from the ExpressRoute circuit is a reliability and capacity improvement. AVNM mesh replaces combinatorial complexity with group-based intent. The operational model scales with the number of groups, not the number of VNets. High-scale mesh and HSPE remove the ceiling — up to 5,000 VNets and 20,000 Private Endpoints per mesh. The migration is incremental and reversible. Mesh coexists with existing paths, and you can validate wave by wave before decommissioning the legacy route. Start with a pilot mesh in a non-critical environment, validate the traffic shift, and expand from there. Resources Connectivity configurations in Azure Virtual Network Manager Increase Private Endpoint virtual network limits Create a mesh topology with Azure Virtual Network Manager Security admin rules in Azure Virtual Network Manager Create a mesh network topology with Azure Virtual Network Manager using Terraform
ICMP Support for Azure StandardV2 NAT Gateway
Our customers, across all industries, depend on consistent outbound connectivity and observability to operate and troubleshoot their cloud workloads at scale. As Azure environments grow in size and complexity, teams increasingly rely on standard network diagnostic tools such as ping to quickly validate reachability and identify connectivity issues. When customers route outbound traffic through Azure NAT Gateway, they benefit from centralized and scalable outbound connectivity designed to prevent SNAT port exhaustion, while simplifying management by removing the need for per‑resource public IPs. Historically, outbound connectivity through Azure NAT Gateway supported TCP and UDP traffic only for Azure workloads. We are pleased to announce that Azure StandardV2 NAT Gateway now supports outbound ping through ICMP Echo Request and Echo Reply traffic. Workloads that rely on NAT Gateway for internet egress can now use ping to validate reachability, improving operational visibility and simplifying network troubleshooting while preserving the scalability and resiliency characteristics of NAT Gateway. What’s now supported? Azure StandardV2 NAT Gateway supports outbound ICMP Echo Request and Echo Reply traffic (ping) for IPv4 and IPv6. Other ICMP message types are not currently supported. With this update, ICMP traffic sent from workloads behind a NAT Gateway can be translated to a public IP address and reliably receive responses from external endpoints. This brings ICMP behavior in line with existing TCP and UDP outbound flows, enabling consistent network diagnostics across all common transport types. This capability is available automatically when workloads egress through a StandardV2 NAT Gateway - no additional configuration or rule changes are required. Scenarios enabled by ICMP support Support for ICMP through StandardV2 NAT Gateway unlocks several common operational scenarios: Basic reachability testing – Operators can use ping from virtual machines, VM scale sets, or AKS nodes behind NAT Gateway to verify outbound connectivity to internet endpoints. Health validation and troubleshooting – Teams can perform quick checks during incident triage without deploying jump hosts, public IPs per VM, or temporary firewall exceptions. These scenarios are especially valuable in large‑scale environments where workloads rely on centralized outbound connectivity via NAT Gateway. How ICMP works through StandardV2 NAT Gateway Unlike TCP or UDP, ICMP does not use ports to differentiate flows. Instead, ICMP messages include an identifier field, which is used by diagnostic tools to correlate requests and responses. A common troubleshooting scenario is when workloads deployed behind an Azure StandardV2 NAT Gateway are unable to reach external endpoints. Since these workloads typically do not have public IP addresses, it can be difficult to quickly determine whether the issue is related to basic network reachability or higher-layer configuration. In such cases, ICMP‑based diagnostics such as ping can be used to validate outbound connectivity and help isolate the source of the issue. When a workload sends an outbound ICMP packet through a NAT Gateway: NAT Gateway translates the source private IP to one of its associated public IP addresses. The platform tracks the ICMP flow using the ICMP identifier and other packet attributes. Return ICMP responses from the external destination are matched to the originating flow. The response is translated back to the original private IP and delivered to the workload. This stateful handling allows replies to be routed correctly even when multiple workloads are sending ICMP traffic concurrently through the same NAT Gateway. Using ICMP for end-to-end outbound troubleshooting To validate outbound connectivity using ICMP from workloads deployed behind StandardV2 NAT Gateway: Go to your virtual network in the Azure portal and select the subnet hosting your workload. Verify that a StandardV2 NAT Gateway is associated with the subnet. The workload does not require a public IP address. Connect to the workload (for example, a virtual machine) running in the subnet. Run an ICMP ping to an external destination to validate outbound reachability. Successful ping from a workload behind an Azure StandardV2 NAT Gateway demonstrating outbound connectivity and ICMP Echo reply. Review the results. Successful ICMP echo replies confirm that outbound connectivity through StandardV2 NAT Gateway is functioning and that ICMP traffic is translated and returned correctly Summary With ICMP Echo support, Azure StandardV2 NAT Gateway provides a more complete outbound networking experience by enabling essential diagnostic tools to function reliably through NAT. Customers can validate reachability, perform basic troubleshooting, and diagnose connectivity issues while continuing to benefit from the simplicity and scale of centralized outbound connectivity. Learn More Azure NAT Gateway overview Troubleshoot Azure NAT GatewayNetwork security perimeter for Azure Service Bus & also now available in Azure Gov. Regions
TL; DR Network security perimeter support for Azure Service Bus is now Generally Available. With this, you can now place your Service Bus namespace inside a central security boundary and apply perimeter-based governance for inbound/outbound network access—while keeping key PaaS-to-PaaS scenarios secure and auditable. Introduction We’re excited to announce that network security perimeter support for Azure Service Bus is now Generally Available (GA). This milestone brings one of Azure’s most widely used messaging services into the network security perimeter ecosystem, enabling customers to define a centralized security boundary across messaging and data services. Alongside this, we are also expanding network security perimeter’s reach — network security perimeter is now available in Azure Government regions, including: Texas Arizona Virginia DoD East DoD Central This ensures that customers operating in regulated, sovereign, and mission-critical environments can adopt network security perimeter while meeting their compliance and regional requirements. Why this matters? Modern applications rely heavily on messaging layers like Service Bus. These systems often connect microservices, data platforms, key management systems and external integrations. As architectures scale, managing network access individually becomes complex and error prone. Network security perimeter changes this by introducing a perimeter-based access model, where: Communication is restricted by default Access must be explicitly allowed Governance is applied consistently across services With Service Bus now onboarded and network security perimeter extending into Azure Gov regions, customers can apply this model across both commercial and sovereign environments. What you can do with Service Bus + network security perimeter Confine communication within a security boundary Service Bus namespaces communicate only with resources inside the perimeter by default—blocking unintended access. Secure PaaS-to-PaaS communication Enable secure interactions between Service Bus, Azure Key Vault (for CMK scenarios) and other network security perimeter-enabled services (What is a network security perimeter? - Azure Private Link | Microsoft Learn) Define explicit access controls Inbound rules → IP ranges and subscriptions Outbound rules → FQDN-based filtering Enable audit and compliance visibility Diagnostic logs capture all access attempts, supporting compliance and investigation workflows. Use Private Link seamlessly Private endpoint traffic continues to work without additional configuration inside the perimeter. Azure Government Availability With this update, network security perimeter is now available in key Azure Government regions (Texas Arizona Virginia DoD East DoD Central), enabling: Consistent security across clouds Apply the same network security perimeter model across public Azure regions and Azure Government environments. Support for regulated workloads Customers in federal, defence, and highly regulated industries can now: Enforce perimeter-based governance Reduce exposure risks Meet compliance requirements Enable secure cross-service patterns in Gov clouds Azure Government boundaries now support scenarios like: CMK with Key Vault Service-to-service messaging Controlled external access More details of onboarded PaaS services are detailed in What is a network security perimeter? - Azure Private Link | Microsoft Learn What’s next Service Bus GA further strengthens network security perimeter’s growing coverage across Azure PaaS services. We will continue to: Expand PaaS service onboarding Improve access rule capabilities (e.g. Service tag-based access, identity-based access)
Pod CIDR Expansion Generally Available and IP Address Planning on Azure CNI Overlay
In networking with Azure CNI Overlay, the cluster-wide pod CIDR is logically partitioned into smaller “node” blocks where each node is assigned a fixed CIDR slice (/24) by Azure. This decouples pod networking from the VNet address space entirely because pods receive addresses from a private CIDR that is separate from the VNet. By default, Azure CNI Overlay uses a pod CIDR of 10.244.0.0/16 which provides 65,536 addresses. Since each node consumes 256 addresses from the /24 slice, the default cluster has a node scaling limit of 65,536 divided by 256, or 256 nodes. Choosing a pod CIDR at cluster creation effectively sets an upper bound on how many nodes the cluster can accommodate. Pod CIDR Per-Node Block Max Nodes Supported /16 /24 256 /15 /24 512 /14 /24 1,024 What does Pod CIDR Expansion enable? Even with careful upfront planning, long-lived clusters grow in ways that are difficult to anticipate. For organizations using Azure CNI Overlay, this previous represents a difficult migration without meticulous IP planning. Pod CIDR expansion allows you to expand the existing CIDR without downtime or node reimaging. Instead of being locked to the range chosen at cluster creation, operators can expand the available pod address space with minimal operational burden. Choosing a Pod CIDR In addition to node scaling limits, there are other considerations for pod CIDR planning: Overlapping pod CIDRs across clusters – even though pod IPs are not directly routable between clusters, overlapping CIDRs can cause problems with observability tooling or cross-cluster networking on top of the overlay. Careful planning can prevent having to recreate the cluster down the road. Accounting for system node pools – each system node also consumes a /24 block. IP address planning should factor nodes running cluster control plane components in addition to existing workloads. Learn More Read more about Azure CNI Overlay: Overview of Azure CNI Overlay Networking in Azure Kubernetes Service (AKS) Try pod CIDR expansion: Expand Pod CIDR Space in Azure CNI Overlay Azure Kubernetes Service (AKS) Clusters
Designing Cloud Landing Zones by Traffic Flow: A Defence‑in‑Depth, DMZ‑First Architecture
As enterprises adopt Microsoft Azure for large‑scale and regulated workloads, security architecture must be driven by traffic trust boundaries and inspection intent, not connectivity alone. Regulatory frameworks consistently require a clear separation between Internet‑untrusted and private enterprise traffic, enforced through defence‑in‑depth controls aligned to the OSI model. This drives the adoption of a DMZ‑first landing zone architecture, where volumetric protection, application‑layer inspection, and perimeter controls are enforced at well‑defined trust boundaries. Security enforcement is prioritised before access, rather than being an afterthought of connectivity. A distributed hub architecture enables this model at scale, delivering consistent controls while improving resiliency, fault isolation, and operational clarity. Traffic Classification in an Enterprise Landing Zone Enterprise traffic flows are classified based on origin, destination, and trust level, which directly dictates inspection requirements: Internet Inbound (North–South): Traffic from the public Internet to Azure‑hosted applications Internet Outbound (South–North): Egress traffic from private workloads to the Internet East–West: Traffic between virtual networks within or across regions Hybrid Connectivity: Traffic between Azure, on‑premises, and multi‑cloud environments Each flow presents a distinct risk profile, making a uniform connectivity and inspection model unsuitable for enterprise and regulated environments. Hub‑and‑Spoke as the Foundation for Centralised Security Enterprises commonly adopt a Hub‑and‑Spoke topology using VNET peering or Azure Virtual WAN, extending hybrid connectivity via Site‑to‑Site VPN or ExpressRoute. The hub provides a centralised, datapath‑centric layer for shared networking and security services, while spoke VNETs host application workloads and remain private, typically without public IPs. Ingress and egress are handled through shared, centrally managed endpoints. This model consolidates critical controls—Azure Firewall, Azure WAF, and DDoS protection—at controlled entry and exit points, significantly reducing the attack surface. Integration with Microsoft Sentinel enables cross‑layer visibility, threat hunting, and detection of risks such as unauthorised access and data exfiltration. Why a Single Hub Is Not Sufficient Using a single hub to process all traffic types introduces operational and security challenges at scale by forcing Internet‑untrusted and private traffic through the same inspection tier. Key limitations include: Coupled Internet and private security policies Rapid firewall rule sprawl and management overhead A single blast radius across all traffic types Throughput and SNAT scalability constraints Increased difficulty meeting regulatory separation requirements These issues become more pronounced as environments scale across regions and workloads. Multi‑Hub as an Enterprise‑Grade Evolution A multi‑hub architecture resolves these challenges by separating inspection responsibilities across dedicated hubs: DMZ Hub VNET: Internet‑facing traffic and perimeter security enforcement Core Hub VNET: Outbound Internet access, East‑West, and hybrid traffic inspection This separation aligns security controls with traffic intent, reduces policy complexity, limits blast radius, and simplifies operations. In the next section, we explore multi‑hub architecture patterns and examine how each traffic flow is inspected and governed in practice. Scenario 1 – Third‑Party Firewall–Centric Multi‑Hub Design In this scenario, third‑party firewalls provide inspection for all traffic flows—Internet inbound, Internet outbound, East‑West, and hybrid connectivity—while Azure WAF and Azure DDoS Protection are used to defend against volumetric attacks, application‑layer threats, and malicious bot traffic. Architecture Overview The design uses two dedicated hub virtual networks, with spoke VNets peered to both hubs to maintain traffic separation based on trust and inspection requirements: DMZ Hub VNET (Internet Ingress Hub) Core Hub VNET (Egress, East‑West, and Hybrid Hub) DMZ Hub VNET – Internet Inbound (North–South) Traffic The DMZ hub establishes a dedicated perimeter for Internet‑facing applications. Internet traffic lands on a public Application Gateway with Azure WAF, protected by an Azure DDoS Protection Plan applied to the public frontend IP. Third‑party firewalls are deployed behind the Application Gateway to perform deep packet inspection. Firewalls operate in active‑active mode as standalone appliances, using three dedicated network interfaces (Untrust, Trust, and Management), each placed in separate subnets. Application Gateway provides load balancing and health probing, ensuring firewall availability and resiliency. Core Hub VNET – Egress, East‑West, and Hybrid Traffic The core hub handles all non‑Internet‑inbound traffic flows, including private inter‑VNET communication and hybrid connectivity. Third‑party firewalls are deployed behind an internal Azure Load Balancer, which maintains high availability using health probes. Firewalls follow the same active‑active, three‑NIC design for consistent policy enforcement and operational symmetry. Azure NAT Gateway is associated with the firewall Untrust subnet to scale outbound SNAT and simplify Internet egress with deterministic public IP. Site‑to‑site VPN or ExpressRoute terminate in this hub for on‑premises and multi‑cloud connectivity, ensuring private and regulated traffic bypasses Internet‑facing controls. Architecture Patterns - Traffic Flow 1.1 North–South (Internet Inbound) Traffic Flow This flow applies when applications hosted on Azure (VMs, VM Scale Sets, or services behind Internal Load Balancer / Internal Application Gateway) are published to the Internet. As shown in the diagram, Internet-bound client requests enter Azure through a dedicated DMZ Hub, where perimeter security controls are enforced before traffic reaches private application spokes. Inbound Request Flow (Blue Path) Client → Application Gateway (WAF) A client request (for example, app1.example.com) is resolved via DNS and lands on the public endpoint of Azure Application Gateway. Azure WAF performs Layer‑7 inspection, bot protection, and rule evaluation. Application Gateway → Firewall (DMZ Hub) Based on hostname and routing rules, Application Gateway forwards traffic to the firewalls while preserving the client’s real IP using the X‑Forwarded‑For (XFF) header. Firewall → Application (Spoke VNET) The firewall performs DNAT to the internal destination (Internal Application Gateway or Internal Load Balancer) and SNAT to its trust‑interface IP to ensure symmetric return traffic. Traffic is then routed over VNET peering to the private application workload. Response Flow (Green Path) Application → Firewall The application responds using its private IP, with the firewall trust interface as the destination. Firewall → Application Gateway The firewall forwards the response based on its session state. Application Gateway → Client Application Gateway returns the response to the Internet client. DDoS Protection Azure DDoS Protection continuously monitors the Application Gateway public IP and mitigates volumetric attacks before they reach the application stack. Key Design Considerations Application Gateway routing - Use a multi‑site listener with hostname‑based rules to steer traffic to the appropriate firewall backend. Firewall backend mapping - Register firewall VMs in a single backend pool and differentiate applications using distinct backend settings (same protocol, different ports). Application steering at firewall - Firewalls perform port‑based DNAT (or private FQDN‑based DNAT where supported) to forward traffic to the correct application private IP in spoke VNets. Traffic symmetry - Source NAT is applied on the firewall trust interface to maintain symmetric return paths. Protocol support - The same pattern applies to TCP/UDP workloads, using an External Azure Load Balancer instead of Application Gateway where WAF is not required. Client IP visibility Application Gateway enables WAF inspection using the real client IP, preserved downstream via X‑Forwarded‑For. With Azure Load Balancer, client IP is retained up to the firewall for IP‑based enforcement, with Azure DDoS Protection safeguarding the public frontend. 1.2 Hybrid Connectivity Traffic Flow Hybrid connectivity represents communication between Azure workloads and on‑premises environments using Site‑to‑Site VPN or ExpressRoute. Traffic Flow Request (Blue: 1–4): Traffic originates from applications in spoke VNETs and is forwarded via UDRs to the Internal Load Balancer, through active‑active firewalls, and then to on‑premises via VPN or ExpressRoute. Response (Green: 5–8): Return traffic follows the same path in reverse. Key Design Considerations Source and destination IP addresses remain unchanged end‑to‑end, despite firewalls operating behind an Internal Load Balancer. UDRs steer both outbound and inbound hybrid traffic to the Internal Load Balancer as the next hop. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. Azure Virtual Network Manager can be used to manage and scale UDR deployment centrally across Hub and spoke networks. 1.3 East-West Traffic flow This traffic flow represents the connectivity between resources across VNETs through Firewall. Considerations remain same as “Hybrid Connectivity Traffic flow” mentioned above. 1.4 Egress/Outbound Connectivity Traffic flow This traffic flow represents the connectivity from the resources hosted inside VNETs to Internet through Firewalls deployed behind Internal Load Balancer in Core Hub VNET. Egress/Outbound Connectivity Traffic flow Key Considerations: A default route (0.0.0.0/0) UDR directs Internet-bound traffic to the Internal Load Balancer for firewall inspection. Firewall performs SNAT to its untrusted interface, after which Azure NAT Gateway translates traffic to a fixed public IP. Alternatively, a public IP can be assigned to the firewall untrusted interface to perform SNAT directly, removing the need for NAT Gateway and reducing cost. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. However, with horizontal firewall scaling, outbound public IPs become non-deterministic. Scenario 2: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows In this scenario, third‑party firewalls secure Internet‑facing traffic, while Azure Firewall handles Egress, East–West, and Hybrid flows. This separation enables organisations to retain existing perimeter security investments while adopting a fully managed, cloud‑native control and data plane for internal traffic flows. As private traffic patterns scale, particularly for chatty East–West communication, Azure Firewall helps simplify operations and improves scalability by offloading traffic inspection to a managed service. This approach reduces operational overhead and provides consistent policy enforcement across internal and hybrid flows. Setup DMZ Hub design remains unchanged from Scenario 1. Core Hub VNET use Azure Firewall for better scalability, built‑in resilience, and simplified operations. Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic. It requires a single subnet (unless force tunnelling is enabled), optimising IP consumption. Outbound traffic is SNATed by Azure Firewall and further translated via Azure NAT Gateway. Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required. Traffic Flow North–South (Internet Inbound) Traffic Flow represented with Numbers. Request flow represented with Blue: 1–3 Response flow represented with Brown: 4–6 Egress/Outbound Connectivity Traffic flow represented with alphabets. Request flow represented with Green: A–C Response flow represented with Blue: D–F Hybrid flow represented with purple Architecture Diagram: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows Further if you want to use Azure Firewall for the Internet Ingress flow, you can use it as well. Below is the architecture diagram explaining the same pattern. Azure Firewalls for Ingress and Private Flows Key Considerations: Application Gateway behaviour remains the same as Scenario 1; however, backend pools use IP‑based targets. Internal applications should be exposed via internal Application Gateway or internal load balancer to provide stable backend IPs. To optimise traffic flow and avoid unnecessary network address translation, the private IP address of the Application Gateway or internal Load Balancer should be configured in the backend pool of External Load Balancer in DMZ Hub VNET. This design does not need Azure Firewall to perform both source NAT (SNAT) and destination NAT (DNAT) operations. Further, implementing User Defined Routes (UDRs) in the Application Gateway subnet—specifically for spoke VNet CIDR ranges steers traffic routing through the Firewall. For non-web (TCP/UDP) workloads, applications can be directly exposed through the firewall public IP, with Azure DDoS Protection applied to mitigate volumetric attacks. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. Scenario 3 - Overcoming Peering Complexity at Scale with Azure Virtual WAN In environments where each application is hosted in its own dedicated VNET for isolation and stronger security, a traditional hub‑and‑spoke model quickly becomes complex. With a single hub, "N" spoke VNETs require "N" peering's; introducing multiple hubs increases this to "2N", significantly amplifying operational overhead—especially across multiple regions. Azure Virtual WAN addresses this challenge by eliminating the need for extensive VNET peering. As a global, managed service, it simplifies large‑scale and multi‑region architectures while providing built‑in scalability and operational consistency. Setup DMZ Hub design and components remain unchanged from Scenario 1 keeping defense in depth principles intact for Internet Inbound or North-South traffic. Core Hub VNET is replaced with Azure Virtual WAN Secure Hub which has Azure Firewall inside the managed Secure Hub VNETs. This further eliminates the need for creating Azure Firewall Subnet, Azure NAT Gateway resources for East-West, Egress and Hybrid connectivity and provides same level of security protection as mentioned in Scenario 2. Secure Hub design using Virtual WAN removes the routing and inspection complexity which was unless required in Scenario 2 by removing UDR configurations in Spoke VNETs, Gateway Subnet and Azure Firewall Subnet. This provides simplified design and operations with built-in resiliency by leveraging the managed platform. Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic. East-West, Egress, and Hybrid connectivity happens via VPN Gateway and Express Route Gateway present in Virtual Hub. All private and Internet Egress traffic is inspected by Azure Firewall present in secure Hub. Outbound traffic is SNATed to Public IP by Azure Firewall thus avoiding the need of Azure NAT Gateway. Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required. Traffic Flow North–South (Internet Inbound) Traffic Flow represented with Numbers. Request flow represented with Blue: 1–5 Response flow represented with Green: 6–10 Egress/Outbound Connectivity Traffic flow represented with Red Hybrid flow represented with Green East-West connectivity flow represented with black Architecture Diagram: Key Considerations Virtual WAN has additional cost Refer to architecture diagram above for different traffic flows. The DMZ VNET components consideration remains same as per scenario 1 You can use your own managed public IP on Azure Firewall for applying standard IP/Network DDoS protection plan. Benefits of multi-Hub approach over single Hub You can use this table as decision matrix to choose the best option for your application requirements. Dimensions Multi-Hub Design Resiliency · Independent scaling of DMZ and Core firewalls · Failure in Internet inspection does not impact East‑West traffic · Easier multi‑region active‑active designs Security & Compliance Clear trust boundaries Auditable inspection points Easier alignment with Zero Trust & regulatory frameworks Operational Simplicity Smaller, purpose‑built firewall policies Clear ownership (Perimeter vs Core team) Faster troubleshooting due to deterministic flows Cost Optimisation Avoids over‑inspection of East‑West traffic by DMZ firewalls Smaller firewall SKUs per hub Better scale‑unit consumption Performance Efficiency Reduced latency for private traffic No unnecessary hair‑pinning Optimised SNAT and connection tracking Key Takeaways Security‑first landing zones should not be designed as one‑size‑fits‑all networks. By designing hubs based on traffic trust level and inspection intent, rather than convenience, organisations gain: o Stronger security boundaries and better fault isolation o Predictable operations at scale o Lower long‑term cost and complexity o Design for traffic flows, not just connectivity o Use DMZ hubs exclusively for Internet‑untrusted traffic o Use Core hubs for East‑West, outbound, and hybrid connectivity o Map security controls to OSI layers o Avoid single‑hub designs for large, regulated, or multi‑region environments This distributed hub‑and‑DMZ landing zone provides a clean, scalable, and secure foundation for enterprise workloads in any Hyperscaler. For regulated, internet‑exposed, or multi‑region environments, a distributed hub with a dedicated DMZ is no longer optional — it is a foundational architecture decision.Simplify Virtual WAN Spoke Connectivity at Scale with Azure Virtual Network Manager
With Azure Virtual Network Manager (AVNM) integration, organizations using Virtual WAN for transitive connectivity can simplify spoke connectivity and policy management across large-scale hub-and-spoke deployments. By using a Virtual WAN hub as the hub in an AVNM hub-and-spoke topology, organizations can define connectivity and routing intent once at the network group level and apply it consistently across large numbers of spoke VNets. This reduces repetitive per-spoke connection and routing configuration, helps maintain operational consistency as deployments expand, and makes it easier to manage hub-and-spoke environments at scale. Together, AVNM’s centralized, group-based orchestration and Virtual WAN’s managed routing, security integration, and hybrid connectivity provide a more streamlined way to simplify operations and scale with confidence. What is Azure Virtual Network Manager? Azure Virtual Network Manager is a management service that lets you group, configure, and deploy network connectivity and security policies across virtual networks at scale. Instead of configuring VNet peering and access rules on each virtual network individually, you define network groups — logical collections of virtual networks based on static selection or dynamic Azure Policy conditions — and apply connectivity configurations and security admin rules to those groups. Key capabilities include: Hub-and-spoke and mesh topologies — Define how virtual networks in a network group connect to a central hub or to each other. Network groups — Group VNets statically or dynamically (using tags, subscriptions, resource group names, or other Azure Policy conditions). Security admin rules — Author and enforce access control lists across all VNets in a network group, providing a centralized layer of defense that complements NSGs and firewalls. Region-scoped deployment — Deploy configurations to specific Azure regions, enabling incremental rollout and controlled blast radius. AVNM operates as an overlay management layer — it orchestrates VNet peering, connectivity, and security rules without replacing the underlying networking primitives. What is Azure Virtual WAN? Azure Virtual WAN as a service brings together routing, security, VPN, ExpressRoute, and transitive connectivity in a hub-and-spoke architecture. A Virtual WAN hub is a managed regional resource that acts as a central transit point for branch connectivity, remote users, private enterprise connectivity, spoke virtual networks, and private traffic routing through security services. Site-to-site VPN connectivity (branch offices, SD-WAN devices) Point-to-site VPN connectivity (remote users) ExpressRoute private connectivity (on-premises datacenters) VNet-to-VNet transitive connectivity (spoke virtual networks) Routing, firewall, and encryption for private traffic All hubs in a Standard Virtual WAN are connected in a full mesh over the Microsoft backbone, enabling any-to-any connectivity between spokes, branches, and remote users across regions. Virtual WAN removes the need to manually manage complex route tables and transit VNets — routing is handled by the hub's built-in router. What this integration enables When you select a Virtual WAN hub as the hub in an AVNM connectivity configuration, AVNM handles the spoke-to-hub wiring for you. For each virtual network in your selected network groups: If the VNet is not yet connected to the Virtual WAN hub, AVNM creates the Virtual Network connection to Virtual WAN hub and applies a consistent routing configuration with Virtual WAN connection policy. If the VNet is already connected, AVNM updates the existing Virtual Network connection to utilize the routing properties in the Virtual WAN connection policy. A connection policy is a hub-level Virtual WAN resource that defines shared routing behavior for the virtual network connections it governs, including route table association and propagation, route maps, internet security settings, and propagated labels. Because the policy applies these settings consistently across governed connections, it helps standardize routing and overrides conflicting settings configured directly on individual connections. How it works The setup follows AVNM's standard workflow: Create a network group. Add virtual networks as members — either statically (by selecting specific VNets) or dynamically (using Azure Policy conditions such as tags or resource group names). Create a connectivity configuration. Choose hub-and-spoke topology, select your Virtual WAN hub as the hub, and select or create a connection policy. Deploy. Commit the configuration to your target regions. AVNM connects all VNets in the network groups to the Virtual WAN hub and applies the connection policy in parallel. You can also enable direct connectivity within a spoke network group. When enabled, VNet-to-VNet traffic within that group routes directly between virtual networks instead of transiting the Virtual WAN hub — useful for latency-sensitive or high-throughput east-west workloads. By default, direct connectivity is regional; enable global mesh to extend it across Azure regions. Key use cases Bulk spoke onboarding Connect many virtual networks to a Virtual WAN hub in one operation. All connections are orchestrated in parallel by AVNM, and the pre-defined routing configuration is automatically applied. Policy-based dynamic onboarding Use Azure Policy to define network group membership conditions. When a new virtual network matches those conditions—for example, a VNet tagged env:prod—it is automatically added to the network group. On the next deployment, AVNM connects it to the Virtual WAN hub with the correct routing configuration, reducing manual onboarding effort. Batch routing configuration updates Push routing changes to all virtual networks in a network group as a single, fully parallelized operation. This significantly reduces maintenance window duration for network-wide changes and makes rollback straightforward. Incremental deployment Segment your network into precise update domains by creating separate network groups — for example, by environment (staging, dev, production) or by region. Deploy connection policies to each group or region independently. This lets you test changes on a smaller subset before applying them broadly, minimizing blast radius. Mesh for selective inspection bypass If you use routing intent to send all private traffic through a firewall in the Virtual WAN hub, certain high-throughput or latency-sensitive flows (such as database replication) may benefit from bypassing that inspection. Enable direct connectivity in AVNM to create a mesh between selected spokes, allowing VNet-to-VNet traffic to route directly while all other traffic continues through the hub firewall. Security admin rules at scale Define network groups for your Virtual WAN spokes, then use AVNM security admin rules to author and deploy access control lists across those spokes. This provides an additional layer of defense alongside next-generation firewalls in the Virtual WAN hub. Getting started Prerequisites: An existing Azure Virtual Network Manager instance An existing Azure Virtual WAN and Virtual WAN hub One or more virtual networks to use as spoke members To configure: Go to your Network Manager instance in the Azure portal. Create a network group and add your spoke VNets. Create a connectivity configuration → select hub-and-spoke → select your Virtual WAN hub → select or create a connection policy → add spoke network groups. Deploy the configuration to your target regions. In your Virtual WAN resource, verify that the expected spoke VNet connections are in a connected state. Review effective routes in the virtual hub to confirm routing behavior matches the selected connection policy. For detailed step-by-step instructions, see Configure Azure Virtual WAN hub for Azure Virtual Network Manager. For more on connection policy, see Connection policy in Azure Virtual WAN. Learn more Azure Virtual Network Manager documentation Virtual WAN and Virtual Network Manager integration overview Azure Virtual WAN documentationSummarized Gateway Prefixes for Route Advertisement in Azure Virtual Networks
Background Many Azure deployments follow a hub-and-spoke topology: one VNet is designated as the hub and holds the connection to on-premises (via ExpressRoute Gateway, VPN Gateway, or both), and workload VNets — the spokes — peer to the hub to reach on-premises and shared services. This centralizes gateway connectivity so many workloads can share a single ExpressRoute or VPN Gateway. However, in large hub-and-spoke topologies, ExpressRoute and VPN Gateway limits on advertised prefixes (for example, 1,000 IPv4 and 100 IPv6 prefixes) can be reached. Because each spoke adds its own address prefixes to that count, these limits are approached quickly, constraining how far the topology can scale. What's New With Summarized Gateway Prefixes, customers can now advertise a single covering prefix (for example, 10.0.0.0/16) instead of many smaller CIDRs (for example, multiple /24s) – dramatically reducing advertised route count and enabling larger-scale Azure environments. A new property, summarizedGatewayPrefixes, is now available on the Virtual Network resource in public preview. When configured on a hub VNet, it controls what your ExpressRoute Gateway and VPN Gateway advertise to on-premises, replacing the default behavior of advertising all individual hub and spoke VNet CIDRs with a set of aggregated prefixes you define. For example, instead of advertising 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on for each spoke, you can advertise a single 10.0.0.0/16. Key Benefits Fewer advertised routes — Replace hundreds of individual spoke CIDRs with a small set of summarized prefixes. Scales with your topology — Supports deployments with 500+ spokes without requiring address plan redesigns or VNet splits. IPv4 and IPv6 — Summarize both address families. Works with both gateway types — Supported on ExpressRoute Gateway and VPN Gateway. Simple configuration — A single property on the VNet resource. No additional services or dependencies. Backward compatible — If the property is left empty, behavior is unchanged: all hub and peered spoke address spaces are advertised as before. How It Works Default behavior ExpressRoute Gateway and VPN Gateway advertise all address spaces of the hub VNet and all address spaces of peered spoke VNets to on-premises. With summarizedGatewayPrefixes configured The gateways advertise the summarized prefixes instead of the hub VNet's individual address spaces. For each peered spoke, if the spoke's address space falls within a summarized prefix, the spoke's individual CIDRs are suppressed from advertisement. Spoke address spaces not covered by a summarized prefix continue to be advertised individually. Example: Without Summarization With Summarization 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, … 10.0.0.0/16 Hundreds of prefixes One prefix Getting Started Open the hub VNet (the VNet containing your GatewaySubnet) in the Azure portal. Go to Address space → Advertised gateway prefixes. Add one or more IPv4 or IPv6 CIDR prefixes that cover the address spaces you want to summarize. Navigate to your virtual network and verify that the summarized prefixes appear. Things to Know The property is set on the hub VNet (the VNet with the GatewaySubnet). The summarized prefixes list can include prefixes outside the VNet's own address space. Avoid overlap among prefixes within the list, but overlap with peered VNet address spaces is expected in hub-and-spoke designs. For dual-stack (IPv4 + IPv6) VNets, define both IPv4 and IPv6 summarized prefixes explicitly.Deploy with Confidence: Using Rule Impact Analyzer in Azure Virtual Network Manager
Introduction In a previous blog post, we described how Azure Virtual Network Manager (AVNM) enables central teams to enforce security admin rules across hundreds of virtual networks—bring consistency and governance to complex enterprise environments. But enforcement at scale introduces a new challenge: deployment confidence. Security admin rules take priority over NSG rules and can span subscriptions and management groups. That makes them powerful—but a single misconfigured rule can disrupt critical traffic across your entire network. Governance teams need a way to understand the real-world impact of a rule before it reaches production—not after. This is exactly the problem Azure Virtual Network Manager now solves with the Rule Impact Analyzer—a capability that simulates proposed security admin rules against your real network traffic, so you can see exactly what will change, what won't, and deploy with confidence instead of guesswork. The Challenge: Understanding Rule Impact Before Deployment As enterprises scale up their use of security admin rules, a visibility gap emerges. Consider a common scenario: a central governance team needs to block high-risk ports across all production virtual networks. The rules are well-intentioned, but the team has no visibility into which existing traffic flows would be affected. Without a way to preview the impact, teams face an uncomfortable tradeoff—move quickly and risk disruption, or slow down manual review across every affected network. The Rule Impact Analyzer is designed to close this gap—giving teams with a clear, data-driven view of what a rule of change will do before it reaches production. What Is the Rule Impact Analyzer? The Rule Impact Analyzer is a joint capability of Azure Virtual Network Manager and Azure Network Watcher. It lets you simulate proposed security admin rules against traffic data derived from virtual network (VNet) flow logs and Traffic Analytics in your environment. Instead of relying on manual review, the analyzer evaluates proposed rules against observed traffic and classifies each flow: Affected — The proposed rule would change the current evaluation outcome for this flow (e.g., traffic that is currently allowed would be blocked). Not Affected — The flow would continue as-is; the rule does not apply. Indeterminate — The flow cannot be conclusively evaluated (e.g., insufficient traffic data). This gives governance teams and network administrators a clear, data-driven view of what a rule of change will do—before it reaches production. Note: The analysis is based on traffic data available through flow logs and Traffic Analytics. Results reflect recorded traffic patterns; traffic that has not yet been observed will not appear in results. The Customer Journey: From Rule Authoring to Validated Deployment The Rule Impact Analyzer fits naturally into the lifecycle of security admin rule management: This workflow lets teams author rules, simulate impact, review results, and refine policies before committing a single change to production. Teams can cycle through simulation as many times as needed. Key Capabilities Predicted Impact Visibility See briefly how your proposed security admin rules would affect existing traffic flows. Results are based on Traffic Analytics data, helping teams make informed deployment decisions. Flow-Level Drill-Down Go beyond summary counts. Inspect specific source and destination paths, see which rule affects each flow, and identify legitimate traffic that would be unintentionally blocked. This makes it easy to pinpoint issues and refine your rules. Configurable Scope You don't have to analyze everything at once. Target your analysis to specific: Rule collections or individual security admin rules Network groups or specific virtual networks This lets you focus on the areas that matter most, whether you're validating a single rule change or assessing a broad policy rollout. Controlled Iteration Modify your security admin rules, re-run the analysis, and repeat—as many times as you need. Deploy only when the simulated impact matches your intended connectivity outcome. Inbound and Outbound Evaluation The analyzer evaluates both inbound and outbound traffic directions, giving you full visibility into the rule's impact across your network. Real-World Scenario: Locking Down Internet-Exposed Management Ports at Scale Let’s look at a real-world scenario as an example. Your organization runs hundreds of VNets across multiple subscriptions. Over time, different teams have created NSG rules that allow inbound SSH (port 22) and RDP (port 3389) from broad source ranges — some even from 0.0.0.0/0. Your security team mandates: block all inbound management-port access except from trusted bastion subnets. The challenge? You can't just flip a switch. Blocking the wrong traffic could be risky, and you want to know the impact of applying the security rules. With Rule Impact Analyzer, you can: Define the proposed security admin rule — deny inbound TCP 22/3389 from all sources except your bastion subnet prefix Simulate before you commit — see exactly which VNets, subnets, and NICs currently have traffic matching the rule, and which existing NSG rules would be overridden Identify conflicts — spot cases where a team's NSG "Allow" rule would be superseded by your new admin-level "Deny," so you can coordinate before deployment Deploy with confidence — roll out the rule knowing the blast radius is fully understood, not guessed Before Rule Impact Analyzer, this required manually auditing NSG rules across every subscription, cross-referencing with resource inventories, and hoping nothing was missed. Now, a single simulation gives you a complete picture in minutes — turning a week-long audit into a self-service workflow. How It Works: Architecture and Design Rule Impact Analyzer uses existing Azure networking telemetry and analytics components. It does not require a separate data collection pipeline. The following diagram provides an interactive version of the architecture: Step 1: Traffic Analytics as Ground Truth. The analyzer queries your existing VNet flow logs through Traffic Analytics. No new agents, log pipelines, or storage accounts are required. Step 2: Log Analytics as the Query Engine. Traffic Analytics data resides in your Log Analytics workspace. The Rule Impact Analyzer runs Kusto Query Language (KQL) queries to retrieve the observed flows relevant to your analysis scope. Step 3: AVNM Rule Evaluation Engine. The retrieved flows are evaluated using AVNM's own enforcement logic—the same priority ordering, allow/deny behavior, and scope resolution used in production. This ensures that what you see in the analyzer matches what would happen when rules are enforced. Step 4: Results Correlation and Surfacing. Each flow is classified and surfaced in the Azure Portal with drill-down capabilities—from summary impact counts down to individual flow paths and the specific rules affecting them. What Means for You Uses existing infrastructure. If you already have Traffic Analytics enabled, there is nothing new to deploy. No data duplication. Queries run in place within your existing Log Analytics workspace, under your existing RBAC and data retention policies. Transparent costs. Only standard Log Analytics query costs apply—no hidden charges or separate billing. Getting Started You can access Rule Impact Analyzer from two entry points in the Azure Portal: From Azure Virtual Network Manager: Navigate to your security admin configuration → select a rule collection → launch the Rule Impact Analyzer. From Azure Network Watcher: Navigate to Monitoring → Traffic Analytics → Rule Analyzer. Both paths lead to the same analysis experience, so you can start with whichever tool fits your workflow. Prerequisites Before using the Rule Impact Analyzer, ensure the following are in place: VNet flow logs are enabled on the virtual networks you want to analyze. Traffic Analytics is configured and sends data to a Log Analytics workspace. You have the necessary RBAC permissions to access the AVNM security admin configuration and the Log Analytics workspace. Steps Enable VNet flow logs and Traffic Analytics on your target virtual networks. Learn more about Traffic Analytics. Author or update your security admin rules in Azure Virtual Network Manager. Learn more about AVNM security admin rules. Launch the Rule Impact Analyzer from either portal entry point, configure your scope (rule collections, network groups, or specific VNets), and run the analysis. Review, refine, and deploy. Iterate your rules until the simulated impact matches your intended outcome, then deploy with confidence. The screenshot below shows the Rule Impact Analyzer in the Azure Portal. After running a simulation, you can see a summary of predicted traffic impact—total paths analyzed, how many are affected or not affected—along with a detailed results table to drill into individual flows and identify which rule impacts each one. Why It Matters Outage Prevention For organizations rolling out network isolation policies at scale, Rule Impact Analyzer acts as a safety net. By simulating rule impact against recorded traffic patterns, teams can catch misconfigurations before they reach production. Faster Rule Adoption Without the analyzer, deploying new admin rules often requires lengthy manual review cycles. With self-service impact analysis, governance teams can validate and deploy rules faster—without waiting for manual approval. Aligning with Behavior Security policies express intent—what traffic should or shouldn't be allowed. Rule Impact Analyzer validates whether a proposed rule achieves that intent against your observed traffic, closing the loop between policy design and operational behavior. Conclusion The AVNM Rule Impact Analyzer closes the gap between policy intent and deployment confidence. Simulating rules against observed traffic—with no additional infrastructure required—governance teams can validate impact before enforcement. Enforcement without visibility is a risk. Visibility without enforcement is incomplete. This capability brings both together. We welcome your feedback as you start using this capability. Share your experience through the Azure Portal feedback button or your Microsoft account team. Learn more: Azure Virtual Network Manager Azure Network Watcher Traffic Analytics AVNM Security Admin Rules Using Azure Virtual Network Manager to Enhance Network Security Authors: Deepak Bansal, Corporate Vice President and Technical Fellow, Microsoft Azure, Xinyan Zan, Vice President, Ashish Bhargava, Principal Software Development Manager, and Jay Li, Senior Product Manager
Understanding and building an Azure Hybrid Meshed Hub-Spoke Topology
A meshed hybrid hub-spoke topology Azure offers two main approaches to build network architectures. This article focuses on traditional networking (using VNets, peering, route tables, etc.), rather than Azure Virtual WAN. Why a hub-spoke topology? A hub‑spoke topology is the only way to control traffic flows while maintaining scalability, because it enforces a central point of connectivity and policy enforcement: Centralized traffic control / inspection: All connectivity (to on‑premises, the internet, and between spokes) is anchored through the hub. The hub hosts shared services such as firewalls or NVAs, providing a single control point where traffic is inspected, filtered, and governed consistently. Avoids uncontrolled lateral communication: Spokes do not connect arbitrarily to each other. All connectivity is routed through the hub, preventing uncontrolled east‑west communication and ensuring traffic follows defined security and routing policies. Inherent scalability by design: New workloads are added by introducing additional spokes. The core network design remains unchanged, enabling linear scaling without the complexity of full-mesh connectivity. In summary, the hub‑spoke model provides centralized control combined with scalable, decoupled workload networks—something that flat or full-mesh designs struggle to achieve. From hub-spoke to meshed multi-region In a hub‑spoke topology, it’s important to keep in mind that the hub is implemented as an Azure Virtual Network (VNet) and VNets are scoped to a single region. This means that in a multi‑region setup, you’ll always need at least one hub per region. Each of these hubs hosts shared services like firewalls, NVAs, and DNS, acting as the central point for connectivity and traffic control. Extending dependencies across regions—for example by connecting spokes to a hub in another region—is generally not recommended. It creates tight coupling between regions, which goes against the goal of keeping regions independent. A well-designed multi‑region architecture aims for regional self‑containment to improve resilience and fault isolation. Relying on a remote hub can lead to issues like failure propagation between regions, higher latency for inspected traffic and more complex routing and operations. It can also introduce organizational challenges when different regions are managed by separate teams, reducing agility and increasing operational risk. For this reason, meshed hub‑spoke architectures should use hubs that are deployed within each region. Connectivity between regions should be established directly between the hubs, not through spokes. In a meshed design, hubs are typically connected in a full‑mesh peering model, allowing for controlled and predictable inter‑region communication while still maintaining regional independence. Within a single region, it can also make sense to deploy multiple hubs to create isolated environments. This is especially useful when you need to separate workloads based on security requirements, regulatory needs, or organizational boundaries. Each hub can then have its own dedicated set of connectivity and inspection services. Finally, each spoke VNet connects to just one hub. This keeps routing simple and predictable, ensures that all traffic passes through the correct inspection and policy enforcement layers, and reinforces the hub’s role as the central control point for network traffic within the region. Integrating hybrid connectivity In most enterprise scenarios, Azure doesn’t operate in isolation—it needs to connect to external networks such as on‑premises datacenters or other cloud environments. This hybrid connectivity is typically set up using services like Azure ExpressRoute, Azure VPN Gateway or third‑party SD‑WAN solutions. In a (meshed) hub‑spoke topology, these connectivity components are best deployed in the hub VNet, since the hub acts as the central point where all inbound and outbound traffic comes together. By centralizing external connectivity in the hub, all traffic—whether entering or leaving Azure—can be routed, inspected and governed in a consistent way using shared services like firewalls or NVAs. It also avoids the need to duplicate gateways and connectivity components across multiple spokes, which helps reduce cost and operational overhead. This approach also simplifies routing and policy management. Spokes can rely on the hub’s shared connectivity instead of maintaining their own connections to external networks. Overall, this reinforces the hub’s role as the single, controlled integration point between Azure and the broader network landscape. Implementation fundamentals With the overall architecture in place, the next step is to understand how Azure actually handles routing and traffic control in this kind of design. When working with a hub‑spoke topology in Azure, it’s important to realize that a virtual network (VNet) doesn’t behave like a traditional router. While you can associate Azure Route Tables with subnets, those routes only apply to traffic originating from within that subnet. Traffic entering the VNet from outside isn’t automatically re‑routed. This is also why VNet peering is non‑transitive by design: peered VNets can communicate directly, but they won’t forward traffic for other networks. To enable controlled routing between spokes—and between Azure and external networks such as ExpressRoute or VPN—you need a component in the hub that can actively receive and forward traffic. In most cases, this is handled by an Azure Firewall or a network virtual appliance (NVA) deployed in the hub. These components act as an explicit routing hop: they receive traffic, inspect or process it based on defined policies and then send it back into the virtual network so Azure’s routing engine can continue forwarding it. In a secure hub‑spoke design, the firewall plays a dual role. It not only provides centralized traffic inspection and enforces security policies, but also acts as the mechanism that enables transitive communication between spokes and external networks. This combination of control and connectivity is a key part of the architecture. Of course, this only works as intended if the firewall is configured with the right rules to allow or block traffic according to your security requirements. While it’s technically possible to implement routing using a basic virtual machine or even a Virtual Network Gateway, these approaches don’t meet typical enterprise requirements. They lack built‑in capabilities like advanced traffic inspection, high availability, autoscaling and centralized policy management. Purpose‑built solutions such as Azure Firewall or mature third‑party NVAs are designed to provide not just routing, but also integrated security, consistency, and scalability. For that reason, they’re generally the only realistic choice for production‑grade hub‑spoke environments where both control and resilience matter. Design principles for building the topology The diagram below shows the topology for a hybrid meshed hub-spoke, with 2 hubs and an Azure Firewall (any other 3rd party Firewall could be used as well). Ensuring correct connectivity in a hub-and-spoke topology may initially appear complex, but in practice it comes down to understanding and correctly applying four key design principles: controlled routing in the GatewaySubnet controlled routing in each spoke proper peering of spokes to the hub meshing the hubs. Before looking at these in detail, it is important to understand a fundamental behavior of Azure Virtual Network (VNet) peering. When two VNets are peered, Azure automatically exchanges their address spaces (CIDR ranges) and injects these prefixes as system routes into the effective route tables of all subnets. As a result, resources in one VNet can communicate directly with resources in the other using private IP addressing, without any additional routing configuration. This built-in route propagation is what makes VNet peering an efficient and low-latency connectivity mechanism in Azure. However, this default behavior is not always aligned with the requirements of a hub-and-spoke topology. In this model, network services such as firewalls, inspection and routing control are typically centralized in the hub VNet. If communication between spokes is allowed to follow the automatically injected system routes, traffic could bypass these centralized controls, which would undermine design objectives such as inspection, segmentation and governance. For this reason, although VNet peering provides seamless connectivity by default, additional configuration is required in a hub-and-spoke architecture. This is usually achieved through Azure Route Tables, network virtual appliances (NVAs) or Azure Firewall, ensuring that traffic between spokes is routed through the hub as intended. This approach enables a controlled routing model that is essential for maintaining security and architectural consistency in enterprise-scale Azure environments. Design principle 1: Controlled routing in the GatewaySubnet In hybrid connectivity scenarios, traffic originating from on-premises environments over VPN or ExpressRoute is first terminated by the Azure Virtual Network Gateway. From there, the traffic is injected into the Azure network using the routing context of the GatewaySubnet. By default, this process relies on system routes that are automatically populated through VNet peering. As a result, when the destination resides in a spoke VNet, the traffic is forwarded directly to that spoke, since its address space has already been learned and installed as a system route. While this behavior is efficient, it also means that traffic will bypass centralized security controls in the hub, such as Azure Firewall. To ensure that all incoming traffic is properly inspected, this default routing behavior needs to be adjusted. This is done by associating a custom Azure Route Table with the GatewaySubnet and defining user-defined routes for each spoke address range. These routes should point to the private IP address of the firewall as the next hop, effectively overriding the system routes created by VNet peering. Because Azure gives precedence to user-defined routes over system routes, traffic that would normally go directly to the spoke is instead redirected through the firewall before reaching its destination. It is important that these user-defined routes precisely match the CIDR ranges defined for the spoke VNets! Any mismatch, such as using broader or more specific prefixes, can lead to unexpected routing behavior and may introduce issues such as asymmetric traffic flows or packet loss. For instance, if a spoke uses address spaces like 10.10.10.0/24 and 192.168.10.0/24, these exact prefixes must be reflected in the route table. Only by aligning the custom routes with the advertised address ranges can you ensure predictable routing and consistent inspection through the firewall. If the hub VNet hosts additional resources beyond an Azure Firewall or third-party network virtual appliance that also require traffic inspection, the corresponding CIDR ranges—either for the specific subnets or for the entire hub VNet—should be included as routes in the route table associated with the GatewaySubnet. These routes should be configured in the same way as those for spoke VNets, ensuring that traffic destined for these resources is directed through the intended inspection point. A typical example is Azure DNS Private Resolver, which can include both inbound and outbound endpoints deployed in dedicated subnets. When such endpoints are present in the hub, their associated subnet address ranges must also be added to the route table for the GatewaySubnet. This ensures that traffic to and from these endpoints is routed through the designated inspection path, maintaining consistent enforcement of security controls. Design principle 2: Controlled routing in every spoke In a hub-and-spoke architecture, traffic flows should follow the intended security model. Workloads within the same spoke VNet are usually treated as part of the same trust boundary, so traffic between resources in that spoke can flow directly over the Azure backbone without needing to pass through centralized controls. Network Security Groups (NSGs) should still be used at the subnet level to provide granular, stateful filtering, but routing this traffic through a central firewall is typically not required. The situation changes when traffic leaves the local VNet. As soon as traffic is destined for another spoke, the hub, or on-premises networks, it crosses a trust boundary and needs to be inspected centrally. To enforce this, Azure’s default routing behavior must be overridden by associating an Azure Route Table with each subnet in the spoke VNets. In most cases, this route table can be kept simple by defining a single default route that sends all outbound, non-local traffic to the firewall in the hub: Destination: 0.0.0.0/0 Next hop: Private IP address of the hub firewall (Virtual Appliance) With this configuration in place, all traffic that is not local to the spoke is forced through the hub, ensuring that communication between VNets and towards external networks is inspected and controlled. From a management perspective, the same route table can often be reused across multiple subnets or even multiple VNets within the same subscription, which helps keep the design consistent and easy to maintain. It’s worth noting, however, that Azure requires route tables and the subnets they’re associated with to be in the same subscription, as this association is enforced by the platform. There is one additional setting that is often overlooked but plays an important role in getting routing right in a hub-and-spoke design. Azure route tables include an option called “Propagate gateway routes”, which controls whether routes learned by a Virtual Network Gateway are added to the effective routes of the associated subnets. By default, routes learned via BGP (for example from ExpressRoute or VPN) or defined through a Local Network Gateway are propagated not only within the hub VNet, but also across VNet peerings. This means that spoke VNets can automatically learn routes to on-premises or external networks and may send traffic directly to the gateway, bypassing the firewall in the hub. To avoid this and keep traffic flowing through the centralized security controls, this setting should be disabled on the route tables used by the spoke subnets. When “Propagate gateway routes” is set to No, routes learned by the gateway are no longer injected into the spokes. As a result, traffic to those destinations cannot take a direct path and instead follows the user-defined default route (0.0.0.0/0) toward the hub firewall, where it can be properly inspected. When combined with the default route to the firewall, this setup ensures that traffic—whether it is going to other VNets, on-premises environments, or external networks—always follows a controlled and predictable path through the hub. This helps maintain consistent security enforcement and avoids unexpected routing behavior in larger or hybrid deployments. Design principle 3: Peering the spokes to the hub Virtual Network (VNet) peering in Azure is often seen as a simple, single configuration, but in reality it is directional by design. To fully connect two VNets, you need two separate peering configurations—one in each direction—and both must be configured correctly to ensure not only connectivity, but also proper routing behavior. Each peering exposes four key settings and getting these right is especially important in a hub-and-spoke architecture. For basic connectivity, the first two settings—“allow virtual network access” and “allow forwarded traffic”—should be enabled on both peerings. These ensure that traffic can flow between VNets and support scenarios where traffic is routed through a central component, such as a firewall in the hub. The other two settings depend on the direction of the peering. In a typical hub-and-spoke setup, the Virtual Network Gateway (or Azure Route Server) is deployed in the hub. This means the peering from the spoke to the hub must enable “use remote gateways”, while the peering from the hub to the spoke must enable “allow gateway transit.” At first, this might seem to contradict the idea that spokes should not directly use the gateway. However, these settings influence control plane behavior and don't enable unrestricted traffic flow. They are required so the gateway can learn and advertise spoke address ranges via BGP to external networks, such as those connected over VPN or ExpressRoute. Whether those routes are actually used in the spokes is still controlled through the “propagate gateway routes” setting on the route tables, allowing you to enforce routing through the firewall as intended. Even if you are not currently using BGP—for example, in environments relying on static routing—it is still a good practice to configure peerings this way. Doing so makes the design future-proof, allowing you to introduce dynamic routing later without changes to the peering model. This approach keeps the architecture consistent and avoids unnecessary rework as the environment evolves. Design principle 4: Meshing the hubs When you extend a hub-and-spoke design across multiple regions, you typically introduce multiple hubs, each managing its own regional spokes. In this setup, it becomes important to connect the hubs to each other, which is done by fully meshing the hub VNets using VNet peering. At the same time, a key principle remains unchanged: each spoke should connect to only one hub in the same region. This keeps the architecture simple, scalable and easier to reason about from a routing perspective. When configuring connectivity between hubs, it’s important to note that VNet peering settings differ from the typical hub–spoke configuration. For inter-hub peerings, only “allow virtual network access” and “allow forwarded traffic” should be enabled. The remaining options—“allow gateway transit” and “use remote gateways”—should be left disabled, as gateway sharing is not required between hubs and would even be blocked in the configuration. Just connecting the hubs with peering is not enough to guarantee correct traffic flow. To ensure traffic moves between regions in a controlled and secure way, you need additional routing logic. Each hub should have an Azure Route Table assigned to its FirewallSubnet (or the subnet hosting the 3rd party NVAs) defining how traffic towards other hub-and-spoke environments is handled. This ensures that inter-region traffic is always routed through the appropriate hub firewall, instead of flowing directly across the Azure backbone. At this point, IP address planning becomes critical. Without a clear addressing strategy, routing quickly becomes complex and hard to maintain. A common best practice is to assign a single “master” CIDR range per region, and then allocate all VNets in that region—both hub and spokes—from that range. This creates a clean, hierarchical addressing model that simplifies routing decisions. With this approach in place, route tables can remain relatively simple. Instead of adding routes for every individual spoke, you only need one route per remote region. The destination is the master CIDR range of that region and the next hop is the private IP of the firewall in the corresponding hub. Because all hubs are peered with each other, these address ranges and firewall endpoints are automatically known through peering, allowing for consistent and predictable routing. Overall, this design keeps routing logic straightforward while ensuring that all inter-region traffic is inspected in the correct hub, preserving the security model and making it easy to scale as new regions are added. Conclusion When the four design principles described in this article are applied consistently, a hub-and-spoke architecture becomes a strong, scalable and easy-to-operate foundation for your network. By combining controlled routing, centralized inspection and clear traffic flows, the model delivers both solid security and predictable behavior, even in complex environments. More importantly, the concepts covered here go beyond just one specific design. They represent the key building blocks of Azure networking, including routing, peering and traffic control. Understanding these fundamentals not only helps you implement hub-and-spoke topologies correctly, but also gives you a solid base for designing and running reliable, enterprise-grade network architectures in Azure. To make this easier to apply in practice, the table below summarizes the main concepts from this article and how they translate into actual configuration. It can be useful both when setting up a hub-and-spoke topology and when troubleshooting existing environments. Area Configuration Key Setting / Value Purpose Hub VNet Deploy shared services Azure Firewall or NVA in hub Central inspection + routing Deploy connectivity VPN Gateway / ExpressRoute in hub Centralize hybrid connectivity GatewaySubnet Associate Route Table UDRs for each spoke CIDR → Firewall IP Force inbound traffic through firewall Spoke Subnets Associate Route Table 0.0.0.0/0 → Firewall (Virtual Appliance) Force all outbound traffic via hub Route Table setting Propagate gateway routes = Disabled Prevent bypass of firewall via gateway VNet Peering (Spoke → Hub) Setting Allow VNet access = Yes Basic connectivity Setting Allow forwarded traffic = Yes Support transitive routing via firewall Setting Allow gateway transit = Yes Allow spoke to leverage hub gateway Setting Use remote gateways = No - VNet Peering (Hub → Spoke) Setting Allow VNet access = Yes Basic connectivity Setting Allow forwarded traffic = Yes Support routing through firewall Setting Allow gateway transit = No - Setting Use remote gateways = Yes Advertise spoke prefixes via hub gateway VNet Peering (Hub→ Hub) Setting Allow VNet access = Yes Basic connectivity Setting Allow forwarded traffic = Yes Support transitive routing via firewall Setting Allow gateway transit = No - Setting Use remote gateways = No - Hub FirewallSubnet Associate Route Table Route remote region CIDR → remote hub firewall IP Ensure inter-region/hub routing Addressing strategy CIDR planning Assign master CIDR per region Simplify routing and reduce UDR complexity Spoke design rule Peering constraint Each spoke connected to one hub only Prevent routing ambiguityAzure Incident Retrospective - Please register! Session 2 - Tracking ID: 5GP8-W0G
Join our upcoming live webcast for a transparent discussion about this recent Azure service incident — led by our engineering teams. Control plane issues in East US Tracking ID: 5GP8-W0G | Impacted: 24-25 April 2026 Same content presented in both sessions — pick the one that works best for your timezone! What to expect 📚 Understand What happened, how we responded, and what we learned 💬 Ask Live Q&A with our engineering experts throughout the session 🛠 Learn The fixes we've put in place and guidance for workload resiliency Choose your session Same content presented at both times — pick the one that works best for your timezone: Session 1 17:30 UTC Thursday, 14 May 2026 Register now → Session 2 05:30 UTC Friday, 15 May 2026 Register now → 9:30 AM US Pacific (PDT) 12:30 PM US Eastern (EDT) 5:30 PM London (BST) 1:30 AM +1 Beijing (CST) 4:30 AM +1 Sydney (AEDT) 6:30 AM +1 Auckland (NZDT) 9:30 PM -1 US Pacific (PDT) 12:30 AM US Eastern (EDT) 5:30 AM London (BST) 1:30 PM Beijing (CST) 4:30 PM Sydney (AEDT) 6:30 PM Auckland (NZDT) Our engineering leaders Deepak Bansal Corporate Vice President, Technical Fellow Azure Networking Cloud+AI Engineering LinkedIn ↗ Qi Zhang Partner Software Engineering Manager Azure Networking Cloud+AI Engineering LinkedIn ↗ ⚠️ Prepare before the livestream Read the Post Incident Review (PIR) ahead of time so you can ask any follow up questions during the live Q&A Helpful resources 🔔 Azure Service Health Alerts Get alerts for relevant incidents by setting up notifications via email, SMS, or webhook 🎥 Past Retrospective Recordings Watch recordings of previous retrospective livestreams 📄 Azure Post Incident Reviews Learn more about PIRs and the retrospective program
