Skip to main content
A virtual network (VNet) is a foundational building block of cloud networking. In Azure, a VNet provides an isolated, logically separate network space where you define IP address ranges, subnets, route tables, gateways, and security rules. VNets let your cloud resources—virtual machines, platform services, and applications—communicate with each other, the internet, and on-premises networks in a scalable and secure way. Below is a high-level diagram showing two separate VNets, each with its own address space divided into subnets. These VNets connect to an on-premises network using gateways, route tables, or other hybrid connectivity components.
A diagram showing virtual networks and subnets with Linux and Windows virtual machines connected to an on-premises network. Colorful icons along the bottom highlight cloud network representation, dedicated instances, hybrid scenarios, and Azure connectivity.

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.
This article explains how to create VNets, configure address spaces and DNS, work with route tables, and establish hybrid and VNet-to-VNet connectivity at a high level. For deep dives into ExpressRoute or advanced VPN Gateway setups, see the AZ-700 course linked in the references.

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.
Analogy: A VNet is like your home router’s network—private IPs are assigned to your devices and are isolated from your neighbor’s network until you create an explicit connection 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 GatewaySubnet in Azure—see docs).
  • Front-end subnet: hosts public-facing VMs or services.
  • Database subnet: hosts stateful services (databases, caches) with tighter security controls.
You can attach NSGs, route tables, and service endpoints to each subnet to control traffic flow and secure resources.
A diagram titled "Virtual Network Concepts" showing a virtual network (192.168.0.0/16) divided into three subnets: GatewaySubnet (192.168.0.0/24), frontendSubnet (192.168.1.0/24) with VM icons, and databaseSubnet (192.168.2.0/24) with SQL icons. The layout also shows a region boundary and a key icon for the network.

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 GatewaySubnet and 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.

Watch Video

Practice Lab