Azure VNet Peering

In Azure, a classic hub-and-spoke topology is a common networking architecture pattern that provides network isolation and segmentation. This pattern reduces costs and management overhead by centralizing services that can be shared across different applications or workloads.

Components:

• Hub Virtual Network (VNet): This serves as the central point of connectivity to your on-premises network. The hub VNet typically hosts services that are consumed by multiple workloads, such as VPN or ExpressRoute gateways, firewall, network intrusion detection or prevention systems (IDS/IPS), Azure Bastion, etc.

• Spoke VNets: These are connected to the hub and are isolated from each other. They can host workloads, and each spoke can be thought of as a standalone unit of deployment. They can be peered to the hub VNet, providing a pathway for them to communicate with the hub and, if needed, with each other.

Peering:

In the context of the hub-and-spoke model, VNet peering involves establishing a peering relationship between the hub VNet and each of the spoke VNets. This allows network traffic to flow directly between VNets in a low-latency, high-bandwidth connection.

By default, the traffic between the spokes must go through the hub. This is important because you can then implement traffic controls in the hub, enforcing network policies and enabling services like firewall, IDS/IPS, etc. If you want the spokes to communicate directly with each other, you need to specifically configure it.

Remember that peering is a two-way relationship, and it must be set up in both directions. That is, you peer Hub-to-Spoke1 and also Spoke1-to-Hub. Also, VNet peering connections are non-transitive, isolated, and have to be created for each pair of VNets that need to communicate.

Routing:

In the hub-and-spoke topology, you’ll often have User-Defined Routes (UDRs) in place to control the flow of traffic. You might also have a Network Virtual Appliance (NVA), like a firewall or a router, in the hub to handle traffic between the spokes or between a spoke and on-premises networks.

With the correct routing configuration, you can ensure that traffic from Spoke1 to Spoke2 (and vice versa) has to pass through the services in the hub, where it can be monitored, filtered, logged, etc. This helps centralize network and security management.