Lesson 14 — Virtual Networks & Subnets
Why You Need to Understand This First
Every Azure workload runs inside a Virtual Network, or connects through one. VNets are the foundational networking primitive — they determine how VMs talk to each other, how resources connect to the internet, how traffic is inspected, and where PaaS services are reachable. Without a solid understanding of VNet structure, address spaces, subnets, and routing, every subsequent networking topic (NSGs, peering, private endpoints, VPN gateways) will feel arbitrary.
On the AZ-104 exam, networking accounts for 15–20% of questions. Most of these questions assume you can reason through IP addressing, route precedence, and subnet sizing without hesitation. This lesson gives you that foundation.
VNet Fundamentals
An Azure Virtual Network (VNet) is a logically isolated network in the Azure cloud. Resources deployed into a VNet communicate with each other using private IP addresses by default — no public internet exposure, no routing through Microsoft's external network.
- Region-specific: a VNet always lives in exactly one Azure region. You cannot stretch a single VNet across regions. For cross-region connectivity you use VNet Peering or a VPN Gateway.
- Availability zones: a single VNet can span all availability zones within its region. A subnet in that VNet also spans all AZs — you do not need separate subnets per AZ.
- No cost for the VNet itself: creating a VNet is free. You pay for associated resources (public IPs, gateways, firewalls) not for the VNet or subnets.
- Soft isolation boundary: resources in different VNets cannot communicate by default, even within the same subscription. Peering or gateways must be explicitly configured.
Address Space & CIDR Planning
When you create a VNet, you assign one or more address spaces in CIDR notation. All subnets within the VNet must fall within these address spaces. You can add address spaces later, but you cannot remove an address space that contains active subnets.
RFC 1918 private ranges
Always use RFC 1918 private ranges for VNet address spaces. These ranges are not routable on the public internet:
| Range | CIDR | Addresses | Common Azure use |
|---|---|---|---|
10.0.0.0 | /8 | 16,777,216 | Large enterprises — subdivided per region/spoke |
172.16.0.0 | /12 | 1,048,576 | Medium environments |
192.168.0.0 | /16 | 65,536 | Small workloads / dev environments |
Practical CIDR reference
| CIDR | Total IPs | Azure-usable IPs | Typical use |
|---|---|---|---|
| /16 | 65,536 | 65,531 | Hub or large spoke VNet |
| /24 | 256 | 251 | Standard application subnet |
| /26 | 64 | 59 | AzureFirewallSubnet minimum |
| /27 | 32 | 27 | GatewaySubnet minimum (recommended) |
| /28 | 16 | 11 | Small service subnet |
| /29 | 8 | 3 | Absolute minimum — avoid in practice |
Subnets & Azure Reserved Addresses
A subnet divides a VNet's address space into smaller segments. Every resource that requires network connectivity (VMs, load balancers, App Service Environments, etc.) must be deployed into a subnet.
The 5 reserved addresses per subnet
Azure reserves 5 IP addresses from every subnet. You cannot assign these to resources:
| Reserved IP | Purpose | Example (/24 starting at 10.10.1.0) |
|---|---|---|
| First address (.0) | Network address | 10.10.1.0 |
| Second address (.1) | Default gateway | 10.10.1.1 |
| Third address (.2) | DNS mapping (Azure DNS) | 10.10.1.2 |
| Fourth address (.3) | DNS mapping (Azure DNS) | 10.10.1.3 |
| Last address (.255) | Broadcast address | 10.10.1.255 |
Subnet properties
- Subnets span all availability zones within the VNet's region — you do not need to create per-AZ subnets.
- A subnet cannot span multiple VNets or multiple regions.
- You can add subnets to a VNet at any time without downtime to existing resources.
- Subnets can optionally have an NSG associated (traffic filtering) and a Route Table associated (custom routing).
Service Delegation
Service delegation reserves a subnet exclusively for a specific Azure managed service. When you delegate a subnet to a service, that service gains the permission to configure the subnet and inject resources directly into it with private IPs from your address space.
Common service delegations
| Delegation value | Service | Notes |
|---|---|---|
Microsoft.Web/serverFarms | App Service (VNet Integration) | Outbound VNet integration for App Service Plans |
Microsoft.Sql/managedInstances | SQL Managed Instance | Requires dedicated subnet; mandatory delegation |
Microsoft.ContainerInstance/containerGroups | Azure Container Instances | ACI with VNet injection |
Microsoft.Databricks/workspaces | Azure Databricks | Requires 2 delegated subnets (public + private) |
Microsoft.NetApp/volumes | Azure NetApp Files | Dedicated subnet required |
User Defined Routes (UDR) & Route Tables
Azure automatically creates system routes for every subnet: a route for the VNet address space (to keep intra-VNet traffic local), a default internet route (0.0.0.0/0 → Internet), and routes for any peered VNets or connected gateways. You can override these with User Defined Routes.
UDR next hop types
| Next Hop Type | Behaviour | When to use |
|---|---|---|
| VirtualNetwork | Routes within the VNet address space | Rarely overridden — system handles this |
| Internet | Sends traffic to the public internet | Explicitly route traffic out via internet |
| VirtualAppliance | Forwards traffic to a specific private IP (NVA or Azure Firewall) | Force internet traffic or spoke-to-spoke through a firewall |
| VirtualNetworkGateway | Routes to VPN or ExpressRoute gateway | Injected automatically by gateway; rarely set manually |
| None | Drops the traffic (black hole) | Block specific destinations at the routing layer |
Forced tunneling pattern
The most common UDR pattern in enterprise environments is forced tunneling through Azure Firewall:
Route Table: rt-spoke-webtier
Route: 0.0.0.0/0 → VirtualAppliance → 10.10.0.4 (Azure Firewall private IP)
Associated to: subnet-webtier, subnet-apptierThis overrides the default internet route, forcing all outbound internet traffic from those subnets through the Azure Firewall for inspection before it leaves the VNet.
Azure Firewall (NVA Reference Point)
Azure Firewall is a managed, stateful, cloud-native firewall-as-a-service. For the AZ-104 exam you do not need deep Firewall configuration knowledge — but you must understand it as the canonical NVA (Network Virtual Appliance) target for UDRs and the hub-spoke pattern.
Key deployment facts
- Deployed into a dedicated subnet named
AzureFirewallSubnet— this exact name is required. - Minimum subnet size: /26 (64 IPs). Microsoft recommends /26 to accommodate scaling.
- Requires a Standard or Premium tier public IP (Standard SKU, static allocation).
- Stateful — return traffic is automatically allowed; no need for reverse rules.
Rule types (know the names)
| Rule type | Layer | What it matches |
|---|---|---|
| Network rules | L4 | Source IP, destination IP, protocol, port |
| Application rules | L7 | FQDNs, URLs, HTTP/S traffic categories |
| DNAT rules | L4 | Inbound port forwarding from public IP to private backend |
DNS in Virtual Networks
DNS configuration in a VNet determines how all VMs in that VNet resolve hostnames. There are two modes: Azure-provided DNS and custom DNS servers.
Azure-provided DNS (default)
By default, VMs in a VNet use Azure's recursive DNS resolver at 168.63.129.16. This virtual IP provides:
- Resolution of Azure-provided internal hostnames (e.g.
vm-name.internal.cloudapp.net) - Resolution of names in Private DNS Zones that are linked to the VNet
- Forwarding of all other queries to Azure's public DNS resolvers
Custom DNS servers
Set custom DNS server IPs at the VNet level (Settings → DNS servers). This overrides 168.63.129.16 for all VMs in the VNet. Use cases:
- Hybrid DNS: forward queries for on-premises domain (
corp.contoso.com) to an on-premises DNS server - Custom resolver: an Azure DNS Private Resolver or Windows Server DNS in the VNet
- Split-brain DNS: different resolution for internal vs external callers
Public IP Addresses
Azure Public IP addresses attach to resources (VM NICs, Load Balancers, Application Gateways, Bastion, Firewall) to provide inbound and/or outbound internet connectivity. Public IPs come in two SKUs and two allocation methods.
Basic SKU vs Standard SKU
| Feature | Basic SKU | Standard SKU |
|---|---|---|
| Zone redundancy | Not zone-redundant | Zone-redundant by default |
| Default allocation | Dynamic (or static) | Static only |
| Inbound security (default) | Open — inbound allowed by default | Secure — all inbound blocked unless NSG permits |
| Load Balancer compatibility | Basic Load Balancer only | Standard Load Balancer required |
| App Gateway v2 | Not supported | Required |
| Availability | Retiring November 2025 | Current; use for all new deployments |
| Routing preference | Microsoft network only | Microsoft network or Internet routing |
Allocation methods
- Dynamic allocation: IP is assigned when the resource starts and released when it is stopped/deallocated. The IP address can change between stop-start cycles. Basic SKU supports dynamic; Standard SKU is always static.
- Static allocation: IP is assigned when you create the public IP resource and held until you explicitly delete it — does not change on stop/start. Standard SKU is always static. Required for DNS A records, TLS certificates tied to IP, and scenarios needing a predictable inbound address.
Enterprise Address Space Planning
Ad hoc IP address planning is one of the most painful technical debts in Azure environments. Retrofitting overlapping address spaces after deployment can require destroying and rebuilding entire VNets. Get this right at the start.
Planning principles
- Reserve large blocks per region: allocate at least a /16 per region-spoke combination. This gives you 65,536 IPs to subdivide into subnets without running out.
- Never use 10.0.0.0/8 as one allocation: do not assign the entire /8 to a single VNet. Divide it into /16 blocks, one per region or business unit (e.g. 10.10.0.0/16 for East US, 10.20.0.0/16 for West Europe, 10.30.0.0/16 for dev, etc.).
- Document on-premises ranges first: collect all on-premises CIDR blocks before designing Azure ranges. Non-overlap with on-premises is mandatory for any hybrid scenario.
- Account for peered VNets: peered VNets cannot have overlapping address spaces. In a hub-spoke model, all spoke /16s must be unique across the entire estate.
- Use IPAM tooling: Azure Virtual Network Manager includes an IPAM feature. Third-party tools (Infoblox, phpIPAM, NetBox) are also common.
Example enterprise allocation
10.0.0.0/8 — Reserved for all Azure
10.10.0.0/16 — East US: Hub VNet
10.10.0.0/24 — AzureFirewallSubnet
10.10.1.0/24 — GatewaySubnet
10.10.2.0/24 — ManagementSubnet
10.20.0.0/16 — East US: Spoke-Prod
10.20.1.0/24 — WebTier
10.20.2.0/24 — AppTier
10.20.3.0/24 — DataTier
10.30.0.0/16 — East US: Spoke-Dev
(subdivide as needed)
10.100.0.0/16 — West Europe: Hub VNet
10.110.0.0/16 — West Europe: Spoke-Prod
172.16.0.0/12 — Reserved for on-premisesCheck Your Understanding
Click any option to see immediate feedback. Answers reflect real Azure behaviour, not documentation theory.
1. You create a /27 subnet within a VNet. How many IP addresses are available for virtual machines and other resources?
2. You need all outbound internet traffic from a subnet to pass through Azure Firewall for inspection. What is the correct configuration?
3. A subnet is delegated to Microsoft.Sql/managedInstances. What restrictions apply to that subnet?
4. You need a public IP address for a new Standard Load Balancer and require the IP to be zone-redundant. Which public IP configuration meets these requirements?
5. You change the DNS server setting on a VNet from Azure default to a custom DNS server at 10.10.2.4. When will existing running VMs start using the new DNS server?
6. What is the minimum subnet size in Azure, and how many IPs are usable for resources in that subnet?
Read the full overview article and the linked subnet planning guide. Pay particular attention to the reserved address section and the service delegation list — both are directly tested on AZ-104.
This lesson covered VNet structure, addressing, routing, and public IPs. Go deeper on any of these:
- Walk me through designing a complete address space for a hub-spoke estate with 3 regions and 5 spoke VNets per region.
- Explain the interaction between UDRs, system routes, and BGP routes — what happens when all three exist for the same prefix?
- What are the specific NSG and UDR restrictions imposed on a SQL Managed Instance subnet?
- How does Azure DNS Private Resolver fit into a hybrid DNS architecture, and when should it replace a custom DNS VM?