Azure networking: VNets, subnets, peering and segmentation best practices

The network is the backbone of any Azure architecture. A poorly designed VNet causes security, connectivity and scalability problems that are hard to fix later. It is worth investing time in the initial design.

IP addressing planning

Define a non-conflicting addressing plan with the on-premises network:

Hub VNet:           10.0.0.0/16
  GatewaySubnet:    10.0.0.0/27   (minimum /27 for VPN Gateway)
  AzureFirewallSubnet: 10.0.1.0/26
  ManagementSubnet: 10.0.2.0/24

Spoke Analytics:    10.1.0.0/16
  WorkloadSubnet:   10.1.0.0/24
  DataSubnet:       10.1.1.0/24
  PrivateEndpoints: 10.1.2.0/24

VNet Peering

az network vnet peering create \
  --name Hub-to-Analytics \
  --resource-group rg-networking \
  --vnet-name vnet-hub \
  --remote-vnet vnet-analytics \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --use-remote-gateways  # allows using the hub's VPN Gateway

Network Security Groups (NSGs)

Apply NSGs to subnets, not to individual NICs (simpler to manage). Essential rules:

# Allow management traffic from a bastion
Priority 100: Allow TCP 22,3389 from AzureBastionSubnet
Priority 200: Deny  All Inbound from Internet
Priority 4096: Deny All (implicit rule)

Private Endpoints

For PaaS services (Storage, SQL, Key Vault), use Private Endpoints instead of exposing service endpoints publicly. Traffic stays within the VNet.

Conclusion

A Hub-Spoke network with planned addressing, restrictive NSGs and Private Endpoints for PaaS is the foundation of network security in Azure. Build it correctly from the start — refactoring networks in production is costly and risky.