Azure Virtual Networks and Subnets

An Azure Virtual Network (VNet) is a logically isolated network in the Azure cloud that represents your own private network in the cloud. It is analogous to a traditional on-premises LAN but operates at scale within Microsoft's global infrastructure. Each VNet resides within a single Azure region and subscription, but can be connected to other VNets across regions via VNet peering or VPN gateways. The VNet defines an IP address space (using CIDR notation) that is private (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or public (though public IPs within a VNet are not routable on the internet unless explicitly attached). Azure reserves the first four and last IP addresses in each subnet for protocol compliance (network address, gateway, Azure DNS, Azure reserved, and broadcast). For example, in a 10.0.0.0/24 subnet, the usable range is 10.0.0.4-10.0.0.254.

Subnets divide a VNet's address space into smaller segments, each with its own security and routing policies. Every subnet must have a unique address range within the VNet that does not overlap with other subnets. Subnets are the deployment boundary for Azure resources: each resource (VM, App Service, etc.) is associated with a specific subnet. Subnets can be delegated to Azure PaaS services (e.g., Azure SQL Managed Instance, Azure Container Instances) to allow those services to inject their own resources. Delegation is configured at the subnet level and is irreversible for that subnet without removing the delegation first.

When you create a VNet, Azure provisions a software-defined network (SDN) using the Azure SDN stack, which is built on top of the Azure Fabric Controller. The VNet's IP address space is programmed into the Azure SDN data plane, which consists of virtual switches (vSwitches) running on Hyper-V hosts. Each VM's virtual NIC (vNIC) connects to a vSwitch, and the vSwitch applies forwarding rules based on the VNet's routing table (system routes and user-defined routes). Azure automatically creates system routes for each subnet that include:

Using Azure CLI:

# Create a VNet
az network vnet create \
  --name MyVNet \
  --resource-group MyRG \
  --address-prefix 10.0.0.0/16 \
  --location eastus

# Create a subnet
az network vnet subnet create \
  --name MySubnet \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --address-prefix 10.0.1.0/24

# Delegate subnet to Azure NetApp Files
az network vnet subnet update \
  --name MySubnet \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --delegations Microsoft.NetApp/volumes

When designing VNets, avoid overlapping address spaces if you plan to peer or connect via VPN. Use a consistent CIDR scheme, such as 10.x.0.0/16 per region (e.g., 10.1.0.0/16 for East US, 10.2.0.0/16 for West US). Subnets should be sized according to resource growth: use /24 for general workloads, /23 or larger for large clusters or delegated services. Remember that some Azure services require specific subnet names and sizes (e.g., Azure Firewall requires AzureFirewallSubnet /26, Azure Bastion requires AzureBastionSubnet /27, GatewaySubnet must be /27 or larger).

A financial services company deploys a three-tier web application in Azure: web servers, application servers, and database servers. They create a VNet with address space 10.0.0.0/16. They create three subnets: 'Web' (10.0.1.0/24), 'App' (10.0.2.0/24), and 'DB' (10.0.3.0/24). NSGs are applied to each subnet: Web allows inbound HTTP/HTTPS from internet, App allows only traffic from Web subnet, DB allows only traffic from App subnet on port 1433 (SQL). This ensures defense-in-depth. They use Azure Firewall in a dedicated AzureFirewallSubnet to inspect outbound traffic. The VNet is peered to a central hub VNet for shared services (Active Directory, monitoring). In production, they monitor NSG flow logs to detect anomalies. Common misconfiguration: forgetting to allow Azure Load Balancer health probes (168.63.129.16) in NSG rules, causing health probe failures.

A retail company connects its on-premises datacenter to Azure using a site-to-site VPN. They create a VNet with address space 10.1.0.0/16, ensuring no overlap with on-premises networks (192.168.0.0/16). They create a GatewaySubnet (10.1.0.0/27) and deploy a VPN gateway. They also create a Local Network Gateway representing the on-premises VPN device. The connection is established via IPsec IKEv2. They use BGP to exchange routes dynamically. In Azure, they create a route table with a forced tunneling route (0.0.0.0/0 next hop to VPN gateway) to send all internet-bound traffic through the on-premises firewall for compliance. They must ensure the on-premises firewall can handle the load. Performance consideration: VPN throughput is limited by gateway SKU (e.g., VpnGw1: 650 Mbps). For higher throughput, they might use ExpressRoute.

A healthcare startup uses Azure Container Instances (ACI) to run microservices. They create a VNet and delegate a subnet ('Containers') to Microsoft.ContainerInstance/containerGroups. This allows ACI to place containers with private IPs in that subnet. They also deploy Azure SQL Managed Instance in a separate delegated subnet. They must size the subnet adequately: ACI requires a /24 or larger, and SQL Managed Instance requires a /27 or larger. They also enable service endpoints on the subnet for Azure Storage to ensure container logs go over the backbone. Common pitfall: forgetting to delegate the subnet before deploying ACI, causing deployment failure. They also restrict NSG rules to allow only necessary traffic from the application subnet to the container subnet.