Azure VNet Architecture: Subnet Delegation, Peering & Service Endpoints

In enterprise cloud deployments on Microsoft Azure, the fundamental building block of private infrastructure isolation is the Azure Virtual Network (VNet). A VNet provides a dedicated, logically isolated software-defined network boundary in which virtual machines, application services, and managed databases communicate securely with each other, with on-premises corporate data centers, and with the public Internet.

Architecting enterprise-grade Azure network topologies requires looking beyond basic IP allocation: understanding internal subnet reservation mechanics, securing east-west traffic using Network Security Groups (NSGs), configuring Subnet Delegation for PaaS integrations, and orchestrating multi-VNet connectivity via Virtual Network Peering while respecting non-transitive routing constraints.

VNet Foundations and Azure IP Address Reservations

An Azure Virtual Network is scoped to a single Azure Subscription and physical Region. Administrators assign one or more Classless Inter-Domain Routing (CIDR) address prefixes from private IPv4 address ranges (RFC 1918, e.g., 10.20.0.0/16):

When dividing a VNet into subnets, systems architects must account for Azure's 5-IP address reservation rule. In every subnet created in Azure, the underlying software-defined networking fabric permanently reserves five IP addresses:

Subnet Delegation: Injecting PaaS Services into VNets

Traditionally, Azure Platform-as-a-Service (PaaS) offerings (such as Azure App Service, Azure SQL Managed Instance, or Azure Databricks) operated exclusively on multitenant public infrastructure. To allow these PaaS services to communicate privately with backend virtual machines without exposing endpoints to the Internet, Azure provides Subnet Delegation.

Delegating a subnet explicitly surrenders full configuration authority of that dedicated subnet to a designated Azure service (e.g., Microsoft.Web/serverFarms). The platform injects private network interface cards (NICs) directly into the delegated subnet, allowing App Services to reach internal corporate databases across private IP routes seamlessly.

Traffic Filtering: Network Security Groups (NSGs) & Application Security Groups (ASGs)

East-west microsegmentation within and across Azure subnets is enforced through stateful Layer 4 packet inspection firewalls called Network Security Groups (NSGs):

• 5-Tuple Filtering: Rules evaluate Source IP, Source Port, Destination IP, Destination Port, and Protocol (TCP/UDP/ICMP).
• Priority-Based Processing: Rules are evaluated in strict numerical order from 100 to 4096. As soon as a packet matches an explicit rule, evaluation halts.
• Application Security Groups (ASGs): Authoring NSG rules using hardcoded IP addresses creates fragile, unmanageable configurations. ASGs allow administrators to group virtual machine NICs by logical workload tag (e.g., ASG-WebServers, ASG-Databases). Administrators write intuitive security rules: Allow Inbound TCP 1433 from ASG-WebServers to ASG-Databases, completely eliminating manual IP management.

Virtual Network Peering & Non-Transitive Routing Mechanics

To connect multiple VNets together—such as linking a centralized shared-services "Hub" VNet with multiple application "Spoke" VNets—organizations deploy Virtual Network Peering. Traffic traversing a peering connection flows entirely across Microsoft's private global fiber backbone, offering low latency, full private IP reachability, and high bandwidth without traversing the public Internet.

Gateway Transit and Remote Gateways

When connecting an on-premises data center to Azure via an ExpressRoute circuit or IPsec Site-to-Site VPN, organizations do not deploy expensive VPN gateways in every spoke VNet. Instead, they leverage Gateway Transit:

• A single Virtual Network Gateway is deployed in the central Hub VNet.
• In the peering settings, the Hub VNet enables Allow gateway transit.
• Spoke VNets enable Use remote gateways in their peering configurations.
• Spoke workloads automatically route on-premises traffic through the central Hub gateway, centralizing edge connectivity and slashing cloud costs.

Configuring Azure Networking via Azure CLI

Systems administrators manage and inspect Azure virtual networks using the cross-platform Azure CLI:

# 1. Create a Hub Virtual Network with a default management subnet
az network vnet create \
    --resource-group "rg-enterprise-networking" \
    --name "vnet-hub-eastus" \
    --address-prefix "10.10.0.0/16" \
    --subnet-name "snet-management" \
    --subnet-prefix "10.10.1.0/24"

# 2. Create a Spoke Virtual Network for application workloads
az network vnet create \
    --resource-group "rg-enterprise-networking" \
    --name "vnet-spoke-app01" \
    --address-prefix "10.20.0.0/16" \
    --subnet-name "snet-workload" \
    --subnet-prefix "10.20.1.0/24"

# 3. Establish bi-directional VNet Peering between Hub and Spoke
# Step A: Hub -> Spoke Peering
az network vnet peering create \
    --resource-group "rg-enterprise-networking" \
    --name "peer-hub-to-app01" \
    --vnet-name "vnet-hub-eastus" \
    --remote-vnet "vnet-spoke-app01" \
    --allow-vnet-access

# Step B: Spoke -> Hub Peering
az network vnet peering create \
    --resource-group "rg-enterprise-networking" \
    --name "peer-app01-to-hub" \
    --vnet-name "vnet-spoke-app01" \
    --remote-vnet "vnet-hub-eastus" \
    --allow-vnet-access

# 4. Verify peering operational status is 'Connected'
az network vnet peering show \
    --resource-group "rg-enterprise-networking" \
    --name "peer-hub-to-app01" \
    --vnet-name "vnet-hub-eastus" \
    --query "peeringState" -o tsv

Confirm that the output reports Connected on both sides of the peering relationship to verify active private routing across the Microsoft backbone.