Cascade Regional Airlines wants to peer its headquarters VNet in East US with a new VNet in West Europe that will support the outstation office there. What is required for this cross-region peering to succeed?
Select an answer to reveal the explanation.
Short Explanation
Global peering means the region gap isn't the obstacle — East US to West Europe works fine over Microsoft's backbone. What still trips people up is the same rule that applies everywhere: overlapping address spaces. Two networks can't share addresses just because they're peered across the ocean instead of across the hall.
Full Explanation
Azure global VNet peering explicitly supports peering VNets across different regions, connecting them over Microsoft's private backbone network rather than the public internet, so region alone is not a blocker here. The one hard requirement that still applies, regardless of region, is that the two VNets' address spaces must not overlap; peering relies on route propagation between the VNets, and overlapping ranges create ambiguous routes that Azure will not establish. Global peering also works across subscriptions and even across Microsoft Entra tenants, provided the peering is set up on both sides with the correct resource IDs, so requiring the same subscription is incorrect. Peering itself does not require, and has no dependency on, a VPN gateway; peering is a distinct connectivity mechanism from gateway-based VPN connections, and adding a gateway would be unnecessary extra infrastructure and cost. Public IP SKU has no bearing on VNet peering at all — peering connects private address spaces, not public endpoints. Before creating the West Europe VNet, Cascade's architects should confirm its proposed CIDR block against every existing VNet's range in the environment, not only the headquarters one.