Virtual Networks: Your Cloud Foundation
Learn how Azure Virtual Networks provide isolated network environments, plan address spaces, configure subnets for services, and understand the naming rules that trip up exam candidates.
Virtual Networks: Your Cloud Foundation
Every Azure network starts with a Virtual Network (VNet). Before you deploy a single VM, gateway, or firewall, you need to understand how VNets carve out your private space in Azure. This module is the foundation for everything that follows.
🎬 Video coming soon
Virtual Networks and Subnets Deep Dive
Virtual Networks and Subnets Deep Dive
~14:00What Is a Virtual Network?
Think of Azure as a massive skyscraper. A Virtual Network is your private floor in that building. You control who comes in, who goes out, and how the rooms (subnets) are arranged. Other tenants can’t wander onto your floor, and your devices can talk to each other freely within it — but talking to the outside world or other floors requires explicit configuration.
Key VNet facts for the exam:
- A VNet is scoped to a single Azure region — it cannot span regions
- A VNet belongs to a single subscription — but can peer across subscriptions and tenants
- You can assign multiple address spaces to one VNet
- Address spaces must not overlap with other VNets you plan to peer or connect
- Azure reserves 5 IP addresses in every subnet (first four and last)
Address Space Planning with Ravi
🏢 Ravi Sharma at Pinnacle Financial is migrating from two data centres to Azure. He needs a hub-and-spoke network for 5,000 staff across multiple business units. Here’s his plan:
| VNet | Purpose | Address Space | Region |
|---|---|---|---|
| Hub VNet | Shared services, gateways, firewall | 10.10.0.0/16 | Australia East |
| Spoke 1 — Finance | Finance workloads | 10.20.0.0/16 | Australia East |
| Spoke 2 — HR | HR workloads | 10.30.0.0/16 | Australia East |
Each /16 gives Ravi 65,536 addresses per VNet — plenty of room for subnetting.
Why non-overlapping matters: If Ravi used 10.10.0.0/16 for both hub and spoke, VNet peering would fail. Azure cannot route traffic between two networks that claim the same address range. Plan this before you deploy — changing a VNet address space later requires downtime and resource redeployment.
CIDR Notation Refresher
CIDR (Classless Inter-Domain Routing) uses a prefix length to define how many addresses a range contains.
| CIDR | Addresses | Typical Use |
|---|---|---|
| /16 | 65,536 | Large VNet |
| /20 | 4,096 | Medium VNet or large subnet |
| /24 | 256 | Standard workload subnet |
| /26 | 64 | Bastion or Firewall subnet |
| /27 | 32 | Gateway or small service subnet |
| /29 | 8 | Smallest allowed (3 usable after Azure reserves 5) |
The 5 reserved addresses in every subnet:
- x.x.x.0 — Network address
- x.x.x.1 — Default gateway
- x.x.x.2, x.x.x.3 — Azure DNS mapping
- x.x.x.255 (last address) — Reserved by Azure
So a /29 (8 addresses) minus 5 reserved = 3 usable IPs.
Special-Purpose Subnets
This is a high-value exam topic. Azure requires specific subnet names and minimum sizes for certain services. Get the names wrong, and the service won’t deploy.
| Subnet Name | Required For | Minimum Size | Naming Rule |
|---|---|---|---|
| GatewaySubnet | VPN Gateway, ExpressRoute Gateway | /27 recommended | Must be named exactly GatewaySubnet |
| AzureBastionSubnet | Azure Bastion | /26 minimum | Must be named exactly AzureBastionSubnet |
| AzureFirewallSubnet | Azure Firewall (data) | /26 minimum | Must be named exactly AzureFirewallSubnet |
| AzureFirewallManagementSubnet | Azure Firewall (management) | /26 minimum | Must be named exactly AzureFirewallManagementSubnet |
| RouteServerSubnet | Azure Route Server | /27 minimum | Must be named exactly RouteServerSubnet |
| (any name) | Application Gateway | /24 recommended | Dedicated subnet required, but you choose the name |
Exam Tip: The exam loves testing exact subnet names. GatewaySubnet is case-sensitive and cannot be changed. Both VPN Gateway and ExpressRoute Gateway share the same GatewaySubnet — you don’t create two. Application Gateway needs a dedicated subnet but the name is your choice.
Ravi’s Hub VNet Layout
Here’s how Ravi’s hub VNet subnets are arranged within 10.10.0.0/16:
10.10.0.0/16 — Hub VNet
├── GatewaySubnet 10.10.0.0/27 (VPN + ER gateways)
├── AzureFirewallSubnet 10.10.1.0/26 (Azure Firewall)
├── AzureBastionSubnet 10.10.2.0/26 (Bastion)
├── RouteServerSubnet 10.10.3.0/27 (Route Server)
├── SharedServices 10.10.10.0/24 (DNS, AD DS, tooling)
└── Management 10.10.11.0/24 (Jump boxes, monitoring)Notice how the special-purpose subnets are small (just meeting minimum requirements) while workload subnets get a full /24. This is a common and recommended pattern.
Shared vs Dedicated Subnets
When Can Resources Share a Subnet?
Shared subnets — Most Azure resources (VMs, NICs, private endpoints, internal load balancers) can coexist in the same subnet. There’s no technical restriction on mixing them.
Dedicated subnets — Some services require their own subnet with no other resources:
- Azure Firewall (AzureFirewallSubnet)
- Azure Bastion (AzureBastionSubnet)
- VPN/ER Gateways (GatewaySubnet)
- Route Server (RouteServerSubnet)
- Application Gateway (needs a dedicated subnet)
- Azure Container Instances (when using subnet delegation)
- Azure SQL Managed Instance (delegated subnet)
Best practice: Even when sharing is allowed, use separate subnets per workload tier (web, app, data) so you can apply different NSG rules and route tables to each.
| Aspect | Shared Subnets | Dedicated Subnets |
|---|---|---|
| When required | Default for most resources — no restriction | Required by specific Azure services |
| Examples | VMs, NICs, private endpoints, internal load balancers | GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet, Application Gateway |
| Naming | Any name you choose | Must use exact names (GatewaySubnet, AzureBastionSubnet, etc.) |
| Other resources allowed | Yes — multiple resource types can coexist | No — only the designated service can deploy here |
| Flexibility | Apply any NSG and route table | Some services restrict NSG or route table association |
| Best practice | Separate subnets per workload tier for NSG granularity | Size to minimum requirement and leave room for growth |
Creating a VNet — The Basics
When creating a VNet, you specify:
- Subscription and resource group — where it lives for billing and management
- Name — descriptive (e.g., vnet-hub-aue-001)
- Region — cannot be changed after creation
- Address space — one or more CIDR ranges (can be added later)
- Subnets — at least one to start (can be added later)
- DNS servers — default Azure-provided, or custom (covered in Module 3)
- DDoS protection — optional (covered in Module 7)
- Tags — for cost management and organisation
You can add or remove address spaces after creation, but only if no resources conflict with the change. Adding subnets is non-disruptive. Removing or resizing subnets requires removing all resources in them first.
Key Takeaways
- VNets are region-scoped and subscription-scoped
- Plan non-overlapping address spaces before deployment
- Azure reserves 5 IPs per subnet — /29 gives only 3 usable
- Special subnets have exact naming requirements (GatewaySubnet, AzureBastionSubnet, etc.)
- Both VPN and ExpressRoute gateways share one GatewaySubnet
Test Your Knowledge
Ravi needs both a VPN Gateway and an ExpressRoute Gateway in his hub VNet. How many gateway subnets does he need?
Sam creates a /29 subnet. How many VMs can he deploy in it?
Which subnet name is required for Azure Firewall?
Next up: IP Addressing: Public, Private and Prefixes — Learn how Azure assigns IP addresses and when to use prefixes for consistent outbound IPs.