Azure Virtual Network peering connects two virtual networks so resources can communicate over the Microsoft backbone by using private IP addresses. The connection is low latency, high bandwidth, and does not require a gateway for ordinary VNet-to-VNet traffic. That simplicity makes peering a foundation of Azure hub-and-spoke architecture, but it also hides design details around address space, routing, gateway transit, forwarded traffic, DNS, and scale.<\/p>\n
For AZ-104<\/a>, it is important to understand how to create and operate peering. In production, the more important skill is predicting the path a packet will take. Peering is not automatically transitive, and connecting spokes to a hub does not mean every spoke can reach every other spoke without additional routing design.<\/p>\n A peering relationship is configured between two virtual networks. Once both directions are established and the settings permit it, resources can communicate through private addressing as though the networks were connected by a high-speed routed link. Traffic stays on the Azure backbone rather than traversing the public internet.<\/p>\n Regional peering connects VNets in the same Azure region. Global VNet peering extends the model across supported Azure regions. The basic operational behavior is similar, but region placement, latency, pricing, and dependent service requirements should still be evaluated. Cross-region connectivity is not the same thing as making two applications one local failure domain.<\/p>\n Peering does not merge the VNets. Each network keeps its own address spaces, subnets, security controls, DNS configuration, route tables, and gateways. That separation is useful because teams can manage workloads independently while exposing only the network paths that the architecture requires.<\/p>\n Peering status should be monitored through lifecycle changes. Renaming resource groups, moving subscriptions, or modifying address spaces can require administrators to revisit the relationship, and deleting one VNet obviously breaks the peer. Infrastructure as code should own both directions where possible so the pair is created, updated, and removed consistently rather than leaving one side managed manually by a different team.<\/p>\n Keep that relationship visible in the network inventory.<\/p>\n VNet peering requires nonoverlapping address spaces for ordinary routing. If two networks use the same prefixes, Azure cannot unambiguously route traffic between them. This is why IP planning is an architecture task, not just a deployment detail. Address overlap is easy to create when separate teams independently choose common RFC 1918 ranges.<\/p>\n A central allocation plan becomes more valuable as subscriptions and environments grow. Reserve address space for hubs, spokes, future growth, and hybrid connections. Avoid giving every small workload an enormous prefix \u201cfor flexibility\u201d because that consumes address space that may later be needed for acquisitions, additional regions, or on-premises integration.<\/p>\n General networking fundamentals<\/a> remain relevant in Azure: prefix length determines network size, routes match destination prefixes, and overlapping networks create ambiguity. Cloud networking automates infrastructure, but it does not remove IP mathematics.<\/p>\n Azure now supports some address-space resizing scenarios for peered networks, but growth still deserves advance planning because every peer must ultimately recognize the updated prefixes and dependent routes may need validation. Treat address expansion as a network change with impact analysis. It is safer to reserve sensible growth room early than to assume a production VNet can always be renumbered or expanded without coordination.<\/p>\n Record allocations centrally so a new subscription cannot unknowingly reuse a prefix that an existing hub or hybrid network already routes.<\/p>\n If Spoke A peers with Hub and Spoke B also peers with Hub, Spoke A does not automatically gain direct connectivity to Spoke B merely because both can reach the hub. VNet peering is a relationship between the two networks that participate in that peering. Transitive connectivity requires a separate design, often involving a routing appliance, Azure Firewall, Virtual WAN, or explicit additional peerings.<\/p>\n This is one of the most important hub-and-spoke concepts. The hub can centralize shared services such as firewalls, DNS resolvers, VPN or ExpressRoute gateways, and private endpoints, but traffic between spokes must have a defined path. If the intent is inspection through a firewall, route tables and forwarded-traffic settings become part of the solution.<\/p>\n The mistake is assuming that a diagram with lines to a hub implies router-like transit. Draw packet paths, not only topology lines. For each communication pair, identify the next hop and whether Azure\u2019s effective routes actually direct traffic there.<\/p>\n Nontransitivity is also a security feature when used intentionally. Spokes can consume shared hub services without automatically becoming one flat network. If Spoke A should never talk to Spoke B, the default behavior supports that separation. Transit should be introduced only where there is a documented need, with routing and inspection designed to enforce the intended trust relationship.<\/p>\n Azure supports gateway transit through VNet peering. A hub VNet can expose its VPN or ExpressRoute gateway to a peered VNet, and the spoke can be configured to use the remote gateway. This avoids deploying a separate gateway in every spoke and is a common way to centralize hybrid connectivity.<\/p>\n The relationship has constraints. A VNet using a remote gateway cannot also have its own gateway for the same role; a virtual network can have only one gateway selection in this model. Both regional and global VNet peering support gateway transit according to Microsoft\u2019s current documentation, but the complete hybrid design should still be validated against the chosen gateway and topology.<\/p>\n The deeper Azure networking scope represented by AZ-700<\/a> is useful when gateway propagation, ExpressRoute, VPN, route tables, and hub-spoke connectivity intersect. Gateway transit is simple to enable, but it changes how a spoke reaches networks beyond Azure.<\/p>\n Route visibility is critical in hybrid designs. A spoke may receive routes to on-premises networks through the remote gateway, while user-defined routes or appliance paths alter how return traffic travels. Verify effective routes on representative network interfaces after enabling transit. A gateway setting can be technically correct while an unrelated route table still diverts the flow away from the expected path.<\/p>\n Hub-and-spoke designs often send traffic through Azure Firewall or a third-party network virtual appliance. That traffic may arrive at a peering after being forwarded by a device rather than originating directly from a resource in the peered VNet. Peering settings and route tables need to permit and direct that pattern deliberately.<\/p>\n User-defined routes can set a virtual appliance as the next hop for selected destinations. The appliance then needs IP forwarding and a return path that preserves symmetric connectivity. A forward route without a matching return route creates failures that can look like security-group or application problems.<\/p>\n Concepts from network address translation<\/a> and enterprise routing are useful when appliances alter source addresses or carry traffic between security zones. Azure provides the route infrastructure, but the appliance\u2019s forwarding and NAT behavior still determine what the destination sees.<\/p>\n Appliance high availability needs its own plan. If a single NVA is the next hop for every spoke, peering may be redundant while the transit path remains a single point of failure. Use the appliance vendor\u2019s supported HA pattern or a managed service such as Azure Firewall where appropriate, and test how routes respond when one instance is unavailable. Centralization is valuable only when the central service is resilient.<\/p>\n A successful peering does not bypass network security groups. NSGs on source or destination subnets and network interfaces can still allow or deny traffic according to their rules. Likewise, user-defined routes can redirect traffic away from the system route that peering would otherwise provide.<\/p>\n Troubleshooting should therefore distinguish three questions: does a peering relationship exist and show a connected state, does the effective route table select the intended next hop, and do security rules permit the flow? Looking at only the peering blade can miss a route that sends traffic to an appliance or an NSG rule that blocks the destination port.<\/p>\n Azure Network Watcher tools can help inspect effective routes and test connectivity. Use those tools to validate the path the platform believes should be taken, then compare it with the intended architecture. Evidence is faster than repeatedly changing peering settings in the hope that traffic starts flowing.<\/p>\n Default system routes can also be overridden by more specific user-defined routes. Longest-prefix match and next-hop selection therefore matter during troubleshooting. If one subnet can reach a peer while another cannot, compare their effective routes and NSGs rather than assuming the peer itself is inconsistent. The difference is often local policy applied to one subnet or network interface.<\/p>\n Peering gives networks IP connectivity, but it does not automatically create a shared DNS namespace or copy private DNS settings between VNets. Workloads still need a resolver that can translate the names they use into addresses that are reachable across the peering.<\/p>\n In simple environments, linked Azure Private DNS zones may provide the needed resolution. Larger hub-and-spoke and hybrid architectures often centralize DNS through Azure DNS Private Resolver or custom DNS servers. The design should explain how a spoke resolves private service names, on-premises names, and names hosted in other spokes.<\/p>\n DNS failures can look exactly like routing failures from an application\u2019s perspective. A client may have a valid peering route but resolve a public or obsolete address. The mechanics described in Azure DNS<\/a> are therefore part of practical peering operations.<\/p>\n Resolver placement should follow failure and traffic boundaries. A pair of custom DNS servers in one hub may serve many spokes, but a regional outage can remove name resolution for workloads that otherwise have surviving network paths. Multi-region designs should consider whether DNS forwarding and private-zone access remain available from the secondary operating region, not just during normal primary-region conditions.<\/p>\n As the number of spokes grows, a full mesh of peerings can become operationally expensive because every new VNet needs relationships with many existing VNets. Hub-and-spoke reduces that relationship count, centralizes shared services, and creates a natural security inspection point. The tradeoff is that transit between spokes must be handled by the hub architecture rather than assumed.<\/p>\n Large estates may use Azure Virtual WAN when managed transit, branch connectivity, or global scale justify it. Traditional hub-and-spoke with Azure Firewall and peering remains appropriate for many organizations. The choice depends on topology, operational ownership, routing needs, and scale rather than on a universal threshold.<\/p>\nPeering creates direct private connectivity between two VNets<\/h3>\n
Address spaces must be planned before the peerings multiply<\/h3>\n
Peering is not transitive by default<\/h3>\n
Gateway transit lets a peered VNet use another VNet\u2019s gateway<\/h3>\n
Forwarded traffic matters when an appliance sits in the path<\/h3>\n
NSGs and route tables remain independent of peering<\/h3>\n
DNS is separate from IP reachability<\/h3>\n
Hub-and-spoke scale requires an intentional connectivity model<\/h3>\n