Virtual network peering
Virtual network peering connects two Azure virtual networks over the Microsoft backbone so that their resources reach each other by private address. The Azure Enterprise Baseline peers every stage spoke and the runner network with the hub, and never peers two spokes with each other.
What it does
A peering is a pair of links, one on each virtual network, and traffic flows only when both exist. Each side has its own settings: allow virtual network access, allow forwarded traffic (accept packets that a network virtual appliance, such as a firewall, forwards from elsewhere), allow gateway transit (offer this network's VPN gateway to the peer) and use remote gateways (route through the peer's gateway). Peering is not transitive: two spokes peered with the same hub cannot reach each other unless something in the hub forwards their traffic.
How BuiltForProd uses it
The vnet-peering unit runs once per spoke, generated by the plat subscription template into every stage, and once for the runner network in acme-core-auto. It writes both sides of the pair in one apply: the spoke side in the spoke's subscription, and the hub side in acme-core-network through the azurerm.hub provider alias that root.hcl generates for every unit. The same deployer identity creates both, so there is no acceptance step.
| Side | Name | Virtual network access | Forwarded traffic | Gateway transit | Remote gateways |
|---|---|---|---|---|---|
| Hub to spoke | peer-to-<spoke-vnet> | allowed | allowed | allowed | no |
| Spoke to hub | peer-to-hub | allowed | allowed | no | only with enable_client_vpn |
The hub side is created first, because gateway transit must be allowed before a spoke may use the remote gateway.
Because the spokes are not peered with each other, traffic between two stages has to cross the hub, where the spoke route tables send it to the Azure Firewall and its isolation-domain rules decide. Forwarded traffic is allowed on both sides for exactly this path. In the spoke NAT egress mode, with no firewall, the spokes cannot reach each other at all.
enable_client_vpn in network.hcl changes one setting in place: when the point-to-site VPN gateway exists, every spoke side switches to use the hub's gateway, so VPN clients reach the spokes through it. With the hub firewall, the replies follow the spoke's default route through it, because the spoke route tables do not take routes from the gateway.
Terms you will see
| Term | Meaning |
|---|---|
| Peering | The pair of links that connects two virtual networks. |
| Forwarded traffic | Packets a firewall or other appliance relays from another network. |
| Gateway transit | The hub offers its VPN gateway to its peers. |
| Use remote gateways | The spoke routes VPN traffic through the hub's gateway. |
Provider alias hub | The second azurerm provider every unit has, pointed at acme-core-network. |
Where to read more
- Azure Enterprise Baseline overview for the network subscriptions.
- Virtual Network for the networks being peered.
- Hub-and-spoke networking for why spokes connect only through the hub.