7.1 VNet, Subnet, and Address Space Design

Design the address plan first

An Azure virtual network, or VNet, is a regional private network that uses address prefixes you choose. It is not automatically global, and it does not automatically connect to other VNets, on-premises networks, or the internet in a way that bypasses Azure controls. The address plan is the first administrator decision because route tables, peering, VPN connectivity, private endpoints, and service integration all depend on non-overlapping prefixes.

The most important AZ-104 rule is simple: do not overlap address spaces that must communicate. If VNetA uses 10.10.0.0/16 and VNetB also uses 10.10.0.0/16, normal peering will not solve that conflict. The same problem appears when a corporate network already uses 10.0.0.0/8 broadly and an Azure team casually creates VNets inside that range. Exam case studies often hide this inside a requirement such as connect two VNets or connect a VNet to the datacenter.

A practical design starts with a table like this:

Subnet sizing and Azure reservations

A subnet is a range inside the VNet address space. Azure reserves addresses in each subnet, so the number of usable addresses is smaller than the raw CIDR count. That matters when selecting a subnet for scale sets, Azure Bastion, private endpoints, App Service VNet integration, Azure Firewall, or application tiers that may scale out.

Do not size a subnet only for today's virtual machines. Count expected growth, IPs consumed by platform services, private endpoints, load balancer backends, blue-green deployments, and temporary migration overlap. A subnet that looks acceptable for two VMs can become a blocker when the same application later needs 20 instances, a private endpoint, and additional test nodes.

Common subnet patterns:

Resource placement is an exam skill

AZ-104 is not asking you to memorize only definitions. It asks whether you can place resources correctly. A VPN gateway belongs in GatewaySubnet, not a random workload subnet. Azure Bastion belongs in AzureBastionSubnet, not beside a VM NIC. A private endpoint creates a NIC in a subnet, so it needs available addresses and appropriate DNS. A service endpoint is enabled on a subnet and changes the path to a supported Azure service, but it does not create a private IP for that service in your VNet.

Portal path: Azure portal > Virtual networks > Create for the VNet and initial subnet. After creation, use Virtual networks > <vnet> > Subnets to add subnets, associate NSGs, associate route tables, enable service endpoints, or configure delegation.

CLI example:

az network vnet create \
  --resource-group rg-network \
  --name vnet-prod-eastus \
  --location eastus \
  --address-prefixes 10.41.0.0/16 \
  --subnet-name snet-web \
  --subnet-prefixes 10.41.1.0/24

az network vnet subnet create \
  --resource-group rg-network \
  --vnet-name vnet-prod-eastus \
  --name snet-app \
  --address-prefixes 10.41.2.0/24

Changing subnets safely

Administrators often need to add, resize, or split subnets. The safe workflow is to inspect what is already using the subnet, confirm there is no overlap with existing subnets, verify route table and NSG dependencies, check delegations, and confirm whether resources must be moved or recreated. You cannot freely shrink a subnet around existing IP addresses. You also cannot assign a prefix that overlaps another subnet in the same VNet.

A basic troubleshooting flow:

1. If subnet creation fails, check for overlap with existing VNet address spaces and subnets.
2. If a subnet cannot be deleted, list NICs, private endpoints, delegated resources, and service associations.
3. If a VM cannot be moved into a subnet, check the VM NIC, subnet availability, NSG rules, route table, and whether the resource type is allowed.
4. If the subnet has no more addresses, resize if possible or create a new subnet and migrate resources by planned redeployment.

Useful commands:

az network vnet show -g rg-network -n vnet-prod-eastus --query addressSpace.addressPrefixes
az network vnet subnet list -g rg-network --vnet-name vnet-prod-eastus -o table
az network nic list -g rg-network --query "[?ipConfigurations[0].subnet.id!=null].[name, ipConfigurations[0].privateIPAddress]" -o table

Design traps

Do not assume every resource in a VNet can talk to every other resource in every VNet. A VNet gives private addressing inside its boundary, but communication across VNets needs peering, VPN, ExpressRoute, or another connectivity pattern. Do not assume a public IP is required for VM-to-VM communication inside the same VNet. Private IPs are used by default inside the VNet.

Do not place management services in workload subnets just because the portal allows subnet selection. Required platform subnet names are significant. Do not choose tiny subnets for services that may scale. Do not ignore future peering or hybrid connectivity; overlap discovered after production deployment is expensive to fix.

A final exam trap is confusing subnet security with address assignment. Creating a subnet does not automatically deny inbound traffic between its VMs. Azure has default NSG rules, and if no NSG is associated, you have fewer filtering controls. Proper subnet design usually pairs addressing with NSGs, route tables, DNS decisions, and private access choices.