Episode 1 — Virtual Networks, Subnets & the Azure Address Space

Welcome to Implement and Manage Azure Virtual Networking: a 9-part micro-learning module for the AZ-104 domain "Implement and manage virtual networking" — we begin at the foundation, the virtual network itself.

Learning objectives

By the end of this episode you will be able to:

• Explain where the virtual network (VNet) sits in the Azure networking landscape and why it is the fundamental private-network building block.
• Describe the scope and isolation boundary of a VNet (one region, one subscription) and the rules for its address space.
• Design a non-overlapping address space and segment it into subnets using CIDR notation.
• Compute the usable host IP addresses in a subnet, accounting for the addresses Azure reserves.
• Configure private IP allocation (dynamic vs static) and perform core create/change/delete actions on VNets and subnets via portal and CLI.

Why it matters

Almost every Azure workload — a VM, an App Service Environment, an Azure Kubernetes Service (AKS) cluster — is deployed into a virtual network. The VNet is the private, isolated network you build inside Azure, and the address plan you choose on day one is very hard to unwind later. Overlapping address ranges permanently block peering and hybrid connectivity, so getting the IP design right is the single highest-leverage decision in Azure networking. Everything in the remaining eight episodes — public IPs, peering, routing, NSGs, DNS, load balancing — plugs into the foundation you lay here.

Where the VNet sits in the Azure networking landscape

Azure groups its networking services into five families. The one that concerns us is Networking foundation, which provides core connectivity: Virtual Network (VNet), Private Link, Azure DNS, Azure Bastion, Route Server, NAT Gateway, and Traffic Manager. The other families build on top of it.

The VNet is the foundation on which the rest of this table sits: you cannot attach a load balancer, a firewall, or a private endpoint without a VNet to host it. A VNet lets Azure resources communicate with each other, with the internet (outbound by default), and with on-premises networks, while giving you traffic filtering and routing control. Notably, there is no charge for the virtual network itself — you pay only for the resources you place in it.

The virtual network as an isolation boundary

A virtual network is a virtual, isolated portion of the Azure public network, and each VNet is dedicated to your subscription. Two scope rules are essential for AZ-104:

• One region. A VNet exists in exactly one Azure region. You cannot stretch a single VNet across regions — but you can connect VNets in different regions with peering (Episode 3).
• One subscription. A VNet lives in one subscription; any resource you connect to it must be in the same subscription and region as the VNet. You can still peer VNets across subscriptions and even across Microsoft Entra tenants.

A useful nuance: VNets and subnets span all availability zones in their region. You do not carve up your VNet by zone — a zonal VM simply picks its zone independently of the network design.

Mnemonic — "A VNet is Regional, Subscription-bound, Isolated, and Zone-spanning" → R-S-I-Z. If you remember only that a VNet is pinned to one region and one subscription but transparently covers every zone, you have the boundary right.

Naming and management scope

A VNet's name must be unique within its resource group (you may reuse the name in another resource group, subscription, or region). You can't change the name after creation. Administration is governed by Azure role-based access control (RBAC) — the built-in Network Contributor role (or a custom role with the right actions) is the standard grant for working with VNets, subnets, peerings, NSGs, and route tables.

Planning the address space (CIDR / RFC 1918)

Every VNet is assigned one or more address ranges written in CIDR notation (for example, 10.0.0.0/16). Ranges may be private (RFC 1918) or public address space you own; Microsoft recommends private address space. Whether public or private, the range is reachable only from inside the VNet, from connected VNets, and from connected on-premises networks — not from the internet.

Certain ranges cannot be used as a VNet address range:

The golden rule of address planning: address ranges must not overlap — not with another VNet you might peer, and not with any on-premises network you might connect. Overlap is not a warning you can dismiss; two networks with overlapping ranges simply cannot be connected. Because you may want to peer or go hybrid in the future, plan the whole organization's space up front and leave room to grow.

Exercise 1 — Design an address space for a 3-tier app

You must host a 3-tier application (web, app, data) in one VNet in East US. You expect modest growth. Design a VNet address space and three subnets, keeping room for future subnets, and make sure nothing overlaps an on-premises network already using 10.1.0.0/16.

Solution. Pick a /16 that avoids the on-prem 10.1.0.0/16 — for example 10.0.0.0/16 (65,536 addresses). Carve three /24 subnets, one per tier, and reserve unused space for later:

Tier	Subnet CIDR	Total addresses
web	10.0.1.0/24	256
app	10.0.2.0/24	256
data	10.0.3.0/24	256

Ranges 10.0.4.0/24 … 10.0.255.0/24 stay free for growth (e.g. a future gateway subnet or a management subnet). Because the VNet is 10.0.0.0/16 and on-prem is 10.1.0.0/16, the two do not overlap, so a VPN or peering can be added later without redesign. Choosing per-tier subnets also lets you apply different NSGs and routes per tier in later episodes.

Subnets: segmenting the VNet

A subnet is a container where resources are actually deployed inside the VNet. Segmenting into subnets lets you apply security and routing per tier and keeps blast radius small. Design guidance from the planning doc:

• Give each subnet a unique CIDR range inside the VNet's space; subnet ranges can't overlap each other.
• Segment by workload and security — put resources that need different NSG rules or different routes in different subnets. If you want traffic between two resources to pass through a network virtual appliance (NVA), place them in different subnets.
• Reserve dedicated subnets for services that demand them — for example, a VPN gateway subnet if you plan hybrid connectivity.
• You can associate zero or one NSG and optionally a route table to each subnet.

A naming tip that trips people up: for maximum compatibility, start a subnet name with a letter — Application Gateway, for instance, can't deploy into a subnet whose name begins with a number.

Azure-reserved addresses — the exact count

This is a classic AZ-104 exam point. Azure reserves five IP addresses in every subnet: the first four addresses and the last address of the range.

For the subnet 10.0.0.0/16, the reserved addresses are 10.0.0.0–10.0.0.3 (the first four) and 10.0.255.255 (the last). Concretely they serve:

• First address — network address.
• .1 — the default gateway.
• .2 and .3 — Azure maps its DNS/infrastructure roles into the VNet.
• Last address — network broadcast.

The consequence for sizing: the smallest subnet is /29, which gives 8 total addresses but only 3 usable (8 − 5 reserved = 3). Any subnet you plan has 5 fewer usable IPs than its raw size.

Exercise 2 — Compute usable host IPs

Your app subnet is 10.0.2.0/26. (a) How many total addresses does it contain? (b) How many are usable for VMs? (c) List the exact reserved addresses.

Solution. (a) A /26 has 2^(32−26) = 2^6 = 64 total addresses (10.0.2.0–10.0.2.63). (b) Azure reserves 5 per subnet, so 64 − 5 = 59 usable IP addresses. (c) The reserved addresses are the first four — 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.0.2.3 — plus the last, 10.0.2.63. Note this is more restrictive than on-premises subnetting, where you would normally subtract only 2 (network + broadcast). Always subtract 5 in Azure.

Private IP allocation: dynamic vs static

Resources such as VM network interfaces (NICs), internal load balancers, and application gateways get private IPs from their subnet's range. There are two allocation methods:

Key admin facts: dynamic is the default; allocation is not deterministic — never assume the "next" IP. When you switch a NIC from dynamic to static, Azure keeps the currently assigned dynamic address as the static one by default. If a resource needs a predictable address, use static.

Exercise 3 — Spot the overlap problem

Team A built VNet-A with address space 10.0.0.0/16 in East US. Team B built VNet-B with address space 10.0.0.0/24 in West Europe. Next quarter you must peer these two VNets so their VMs can talk. What is the problem, and what must change?

Solution. VNet-B's range 10.0.0.0/24 is entirely contained within VNet-A's 10.0.0.0/16 — the two address spaces overlap. Peering (and any hybrid connection) is impossible while ranges overlap, and this is enforced, not advisory. To fix it, one VNet must be re-addressed to a non-overlapping range — e.g. move VNet-B to 10.1.0.0/24. Because you can only shrink or extend a VNet's range so long as it still covers its subnets, and re-addressing requires moving resources, this is painful after the fact. Lesson: allocate distinct ranges from a shared organizational plan before anyone builds. (We revisit peering requirements in Episode 3.)

Creating and managing VNets and subnets

The core admin verbs are worth memorizing for the exam. In the portal, you create a VNet from the Virtual networks blade → + Create, filling in Subscription, Resource group, Name, Region, then defining the IPv4 address space and at least one subnet.

Equivalent Azure CLI and PowerShell essentials:

# Create a VNet, then add a subnet
az network vnet create --resource-group myResourceGroup --name myVNet --address-prefixes 10.0.0.0/16
az network vnet subnet create --name web --resource-group myResourceGroup --vnet-name myVNet --address-prefixes 10.0.1.0/24

# Change: add another address range
az network vnet update --resource-group myResourceGroup --name myVNet --address-prefixes 10.0.0.0/16 10.2.0.0/16

# Delete (only when nothing is connected)
az network vnet delete --resource-group myResourceGroup --name myVNet

Rules to remember about changing and deleting:

• You can extend a VNet range (e.g. /16 → /8) or shrink it, but only so it still contains all existing subnet ranges. If the VNet is peered, the new range can't overlap the peer.
• You can change a subnet's address range only if no resources are deployed in it.
• You can delete a subnet only when it's empty, and a VNet only when no resources are connected to it — delete the resources first.
• DNS defaults to Azure-provided name resolution; you can switch a VNet to Custom DNS servers, after which connected VMs pick up the change only after a restart.

Key takeaways

• The VNet is the fundamental private-network building block and the foundation every other Azure networking service plugs into; the VNet itself is free.
• A VNet is scoped to one region and one subscription, is an isolation boundary, and spans all availability zones in its region.
• Address space uses CIDR / RFC 1918 ranges that must not overlap any VNet you might peer or any on-premises network — overlap blocks connectivity permanently.
• Azure reserves 5 addresses per subnet (the first four + the last); the smallest subnet is /29 = 8 addresses, 3 usable. Always subtract 5, not 2.
• Private IPs are dynamic by default; use static for resources needing a fixed address.
• Core admin gates: change a subnet range only when empty; delete a subnet/VNet only when nothing is attached; you can't rename a VNet or subnet after creation.

Quick recall

1. Q: Across how many regions and subscriptions can a single VNet exist? A: Exactly one region and one subscription. (You connect across them with peering, not by stretching a VNet.)
2. Q: How many IP addresses does Azure reserve in every subnet, and which ones? A: Five — the first four addresses and the last address of the subnet range.
3. Q: What is the smallest subnet size, and how many usable IPs does it give? A: /29, which has 8 total addresses and 3 usable (8 − 5 reserved).
4. Q: What is the default private-IP allocation method, and when would you override it? A: Dynamic is the default; use static when a resource (e.g. a DNS server) needs a fixed, predictable address.
5. Q: Why must two VNets have non-overlapping address spaces? A: Because overlapping ranges cannot be peered or connected to on-premises networks — the connection is blocked outright.

Coming up

Next episode: Public IP Addresses & Outbound Connectivity (NAT Gateway) — how resources in your freshly planned VNet reach the internet, the Standard vs Basic public-IP SKUs, and scalable outbound SNAT with Azure NAT Gateway.