Azure Peering or VNet-to-VNet VPN? Decide Before Routing

Azure gives you at least two ways to connect two virtual networks, and they are not interchangeable settings on the same object. Peering joins the VNets on Microsoft's backbone without a gateway; a VNet-to-VNet VPN puts an IPsec relationship between two gateways that you deploy, size and monitor. The decision comes down to three conditions, and if you cannot answer all three before you add a route, you are about to build a workaround for a model you never chose.

Three conditions that decide the model

The first is whether anything in the requirement needs an IPsec boundary that you own and can point at. The second is whether the address spaces are clean and the two VNets only need to talk to each other. The third is who owns any transitive path and the gateway bill. Answer them in that order, because the first one can eliminate peering no matter how attractive the second looks.

What both models share is a hard addressing rule: the VNet address spaces must not overlap. Neither peering nor a VNet-to-VNet VPN is a supported way to make two identical ranges unambiguous, and an overlap needs a mapping design or a redesign rather than a different connection type.

Condition 1: do you need an IPsec boundary you own?

Peering carries traffic over Azure's private backbone and does not require a VPN gateway for the peered connection itself. That is a transport statement, not an encryption statement you can hand to an auditor as "we run IPsec". If the requirement names a customer-configured tunnel, a specific IKE policy, or a boundary that terminates on equipment you control, peering does not satisfy it however private the backbone is.

A VNet-to-VNet VPN does provide that boundary: two gateways, an IPsec/IKE relationship, shared keys and all the operational surface that comes with it. You inherit tunnel state, gateway capacity, SKU limits and the monitoring that proves the tunnel is up. That is the correct answer when the requirement is specifically about that boundary, described in the peering overview as a distinct connection type from peering.

Be equally careful in the other direction. "We need encryption between VNets" is often satisfied by the workload's own TLS, and then a gateway is a cost with no requirement behind it. Write the sentence the auditor will read before choosing the mechanism.

Condition 2: is the topology direct, or does something need to transit?

Peering is not transitive. Two VNets peered to a hub are not thereby connected to each other, and a route that appears to work in one direction is usually a peering that reached Connected on one side only. Both sides must exist and both must show Connected, which is the first thing to check when traffic silently disappears.

If the requirement is on-premises reachability through a hub, gateway transit is a separate design with specific roles: the hub owns the gateway, the spoke peering allows gateway transit, and the spoke must allow forwarded traffic. Those are properties on the peering, not automatic consequences of connecting the VNets:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

The effective route table is the honest answer to "does the path exist". It shows the next hop type the platform will actually use, so a peering that looks configured but is not connected shows up as a missing or wrong route rather than a mystery.

Condition 3: who owns the transitive path and the bill?

Every additional hop has an owner. With peering, a new VNet means a new peering pair on both sides and, for transit, a hub that keeps forwarding traffic and a route table that keeps pointing at it. With a VPN, a new VNet means another gateway or another connection on an existing one, with its own capacity ceiling to watch.

Cost follows the same shape but not the same line items: peering charges are connection and data transfer, while a VPN adds gateway hours and its own transfer charges. Compare the total for the topology you will actually run in a year, including the second tunnel and the monitoring, not the price of one connection today. Include the labour that nobody invoices: someone has to rotate keys, watch tunnel state and answer the alert at three in the morning when a gateway restarts. That line item is usually what decides the argument, because it is the only one that never appears in a quote.

Whichever you pick, test three flows: the intended one, a denied one that should stay denied, and the recovery case where the hub gateway or a peering is down. A model that only explains the happy path has not been verified, it has been demonstrated.

Verify the choice against its own claim

Write one sentence that names the model, the boundary and the owner, then check that the deployed state matches it. For peering that means both peering states Connected, the effective route showing the peering next hop for the destination prefix, and no gateway in the path. For a VNet-to-VNet VPN it means both connections Connected, matching keys and policies on both gateways, and a route whose next hop is the virtual network gateway.

If the checks disagree with the sentence, fix the sentence first. Most of the confusion in these designs comes from a hybrid that nobody described: a peering for the workload subnet, a VPN for one legacy service, and a route table that silently prefers one of them.