Module Introduction

• Configure VNet peering
• Configure network routing and endpoints

​

What you’ll learn

​

1 — VNet peering (Overview, use cases, considerations)

• Isolate workloads in separate VNets while allowing private communication (e.g., prod/dev separation)
• Centralize services (e.g., logging, monitoring) in a hub VNet accessed by spoke VNets
• Migrate workloads across subscription boundaries without routing over the public internet

• Peering is non-transitive. If VNet A is peered with VNet B and VNet B is peered with VNet C, traffic from A to C is not automatically allowed through B.
• Address spaces must not overlap between peered VNets.
• You can enable or disable gateway transit and use forwarded traffic options to support specific topologies (hub-and-spoke with centralized VPN/ExpressRoute gateways).

# From subscription and resource group where VNet1 exists:
az network vnet peering create \
  --name VNet1-to-VNet2 \
  --resource-group MyResourceGroup \
  --vnet-name VNet1 \
  --remote-vnet /subscriptions/<SUB_ID>/resourceGroups/OtherRG/providers/Microsoft.Network/virtualNetworks/VNet2 \
  --allow-vnet-access

# Create the reverse peering if required:
az network vnet peering create \
  --name VNet2-to-VNet1 \
  --resource-group OtherRG \
  --vnet-name VNet2 \
  --remote-vnet /subscriptions/<SUB_ID>/resourceGroups/MyResourceGroup/providers/Microsoft.Network/virtualNetworks/VNet1 \
  --allow-vnet-access

• Wrap any subscription or resource placeholders in backticks when copying (e.g., /subscriptions/<SUB_ID>/...).
• To support hub-and-spoke gateway transit, configure --allow-gateway-transit on the spoke peering and --use-remote-gateways on the spoke that uses the hub gateway.

​

2 — Hybrid connectivity: VPN gateways (site-to-site and point-to-site)

1. Create a virtual network and subnet named GatewaySubnet (required).
2. Create a public IP for the VPN gateway.
3. Create the VPN gateway resource.
4. Configure the local network gateway (represents on-premises).
5. Create the VPN connection and verify status.

az network vnet subnet create \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --name GatewaySubnet \
  --address-prefix 10.0.255.0/27

​

3 — Azure network routing and endpoints (UDRs, private endpoints, service endpoints)

• Route tables (UDRs): Attach custom route tables to subnets to override default system routes or direct traffic to virtual appliances (NVA) or on-premises.
• Service endpoints: Extend your VNet identity to Azure PaaS services over the Azure backbone — allows firewall rules on the PaaS side to restrict to VNet subnets.
• Private endpoints: Attach a private IP from your VNet to an Azure PaaS resource, giving private access without public IP exposure.

• Use service endpoints when you want simple service-level access control and do not need full private IP addressing on the resource.
• Use private endpoints when you require private IP connectivity and DNS resolution to the private address of the PaaS resource.

# Create a route table
az network route-table create \
  --name MyRouteTable \
  --resource-group MyResourceGroup

# Add a route that directs traffic for 0.0.0.0/0 to a virtual appliance
az network route-table route create \
  --resource-group MyResourceGroup \
  --route-table-name MyRouteTable \
  --name DefaultRouteToNVA \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

# Associate route table to subnet
az network vnet subnet update \
  --vnet-name MyVNet \
  --name MySubnet \
  --resource-group MyResourceGroup \
  --route-table MyRouteTable

az network private-endpoint create \
  --name MyPrivateEndpoint \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --subnet MySubnet \
  --private-connection-resource-id /subscriptions/<SUB_ID>/resourceGroups/rg/providers/Microsoft.Storage/storageAccounts/mystorage \
  --group-ids blob \
  --connection-name myStorageConnection

• Private endpoints require DNS updates so clients resolve the PaaS resource to the private IP. You can use Azure Private DNS Zones or your own DNS server and conditional forwarding.
• Service endpoints do not change DNS resolution — endpoint traffic still uses public FQDNs but the traffic is secured to your VNet.

​

Practical design tips

• Plan address spaces to avoid overlaps when peering or configuring VPNs.
• Use a hub-and-spoke architecture for centralized services and gateway management.
• Leverage UDRs and NSGs together: UDRs control pathing, NSGs control allowed traffic.
• Prefer private endpoints for sensitive PaaS workloads that must not have public access.

​

References

• Azure Virtual Network peering
• Azure VPN Gateway overview
• Azure route tables (UDRs)
• Azure Private Endpoint documentation