Subnets in Azure: Segmenting Your Virtual Network

What a subnet actually does

When you create a VNet with the address space 10.0.0.0/16, that gives you 65,536 IP addresses. A subnet carves a portion of those addresses for a specific group of resources. For example:

snet-web might use 10.0.1.0/24 — that’s 251 usable IPs for web servers.

snet-db might use 10.0.2.0/24 — 251 usable IPs for databases.

Resources in the same subnet can communicate freely. Resources in different subnets communicate through Azure’s virtual router, which means you can apply route tables and Network Security Groups at the subnet boundary to control or inspect that traffic.

This separation is the foundation of network segmentation. Even if an attacker compromises a web server in snet-web, they cannot automatically reach the database in snet-db — your NSG rules determine whether that traffic is allowed.

The 5 reserved addresses rule

Azure reserves 5 IP addresses in every subnet. Understanding which ones they are helps you plan subnet sizes correctly.

For a subnet with range 10.0.1.0/24:

A /24 subnet gives you 256 total addresses minus 5 reserved = 251 usable IPs. A /28 gives you 16 total minus 5 = 11 usable IPs. A /29 gives 8 total minus 5 = 3 usable IPs.

Never create a /30 or smaller subnet for regular workloads. The minimum recommended size for any subnet with resources is /28.

Subnet design patterns

There is no single right way to design subnets, but several patterns work well for most architectures:

Tier-based segmentation. One subnet per application tier: web, app, data, management. This is the most common pattern for traditional three-tier applications. NSG rules control traffic between tiers.

Environment-based segmentation. Separate subnets for production, staging, and dev resources within the same VNet. This works when you want to keep all environments in one VNet but apply different security rules.

Service-based segmentation. One subnet per Azure service type: one for VMs, one for App Service integration, one for private endpoints, one for the gateway. This works well in hub-and-spoke architectures.

Managing subnets with Azure CLI

All subnet operations use az network vnet subnet. The VNet must exist before you can create subnets inside it.

Create a subnet:

az network vnet subnet create \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --address-prefixes 10.0.1.0/24

Create a subnet and attach an NSG at the same time:

# First create the NSG
az network nsg create \
  --name nsg-web \
  --resource-group rg-prod-networking \
  --location eastus

# Then create the subnet with the NSG attached
az network vnet subnet create \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --address-prefixes 10.0.1.0/24 \
  --network-security-group nsg-web

Update an existing subnet to attach an NSG:

az network vnet subnet update \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --network-security-group nsg-web

List all subnets in a VNet:

az network vnet subnet list \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --output table

Show available IP addresses in a subnet:

az network vnet subnet show \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --query "{name:name, prefix:addressPrefix, available:ipConfigurations}" \
  --output json

Delete a subnet (only possible when no resources are attached):

az network vnet subnet delete \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001

Service endpoints on subnets

Service endpoints extend a subnet’s identity to Azure PaaS services like Azure Storage and Azure SQL. When you enable a service endpoint, traffic from that subnet to the PaaS service travels over the Azure backbone rather than the public internet.

Enable the Azure Storage service endpoint on a subnet:

az network vnet subnet update \
  --name snet-app \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --service-endpoints Microsoft.Storage

Enable multiple service endpoints at once:

az network vnet subnet update \
  --name snet-app \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --service-endpoints Microsoft.Storage Microsoft.Sql Microsoft.KeyVault

Subnet delegation

Some Azure services need to inject resources directly into your subnet. Subnet delegation is how you grant that permission. When you delegate a subnet to a service, that service can create and manage network interfaces in the subnet on your behalf.

Examples of services that require subnet delegation: Azure App Service VNet integration, Azure Container Instances, Azure NetApp Files.

Delegate a subnet to Azure App Service:

az network vnet subnet update \
  --name snet-appservice \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --delegations Microsoft.Web/serverFarms

A delegated subnet can only be used by the service it is delegated to. Do not try to put VMs in a subnet delegated to App Service — the deployment will fail.