
Why VNets matter (benefits and capabilities)
- Segmentation and isolation: break a VNet into multiple subnets to separate front-end, back-end, database, and gateway workloads.
- Security controls: apply Network Security Groups (NSGs) and Azure Firewall or third-party virtual appliances.
- Routing and policy: attach custom route tables to control traffic paths between subnets and to on-premises networks.
- Hybrid and multi-VNet connectivity: connect VNets to on-premises using VPN Gateways or ExpressRoute, or connect VNets to each other using VNet peering.
VNet address spaces and IP planning
Each VNet has a private IP address space—typically RFC 1918 ranges (for example,10.0.0.0/16, 192.168.0.0/16, 172.16.0.0/12). You subdivide that space into subnets and assign resources IPs from those subnet ranges. Resources that require direct internet access can still have public IP addresses, but the VNet itself uses private addressing.
Overlapping address spaces between connected networks cause routing conflicts and prevent connectivity. Plan non-overlapping CIDR ranges when you design VNets that will connect to each other or to on-premises networks.
Always ensure your VNet address space does not overlap with other VNets or with your on-premises network when you plan to connect them. Non-overlapping address spaces are required for successful routing between networks.
Typical VNet structure and common subnet roles
A VNet (for example,192.168.0.0/16) is commonly divided into smaller subnets with specific roles:
- Gateway subnet: hosts VPN or ExpressRoute gateway VMs (must be named
GatewaySubnetin Azure—see docs). - Front-end subnet: hosts public-facing VMs or services.
- Database subnet: hosts stateful services (databases, caches) with tighter security controls.

Common subnet examples
Key concepts to remember
- Private address ranges: VNets use private address ranges (RFC 1918). Public IPs are optional and assigned to individual resources when needed.
- Non-overlapping CIDRs: required for routing between VNets and on-premises networks.
- NSG vs. route table: NSGs filter traffic; route tables control packet paths.
- Gateway naming: when deploying VPN/ExpressRoute gateways in Azure, create a subnet named
GatewaySubnetand allocate enough IPs.
What this lesson covers next
If the VNet structure and address planning are clear, the next topic is how private and public IP addresses are allocated and used within VNets, and how DNS and name resolution work for resources inside and across VNets.Links and references
- Azure virtual network documentation
- Azure VPN Gateway documentation
- VNet peering overview
- AZ-700: Designing and Implementing Microsoft Azure Networking Solutions