What Is an Azure Virtual Network?
An Azure Virtual Network (VNet) is a logically isolated slice of the Azure network fabric that you control: you define its private IP address space using CIDR notation (for example 10.0.0.0/16), and every resource you place inside it -- VMs, App Service instances with VNet integration, Azure Kubernetes Service nodes -- gets a private IP from that space. A VNet is scoped to a single region and a single subscription (though it can be shared across subscriptions via Azure Lighthouse or RBAC), and by default resources inside it can reach the internet outbound but are not reachable from the internet inbound unless you explicitly open a path with a public IP, load balancer, or NAT gateway.
Cricket analogy: Just as a franchise like Mumbai Indians controls its own squad roster and training ground separate from every other IPL team, a VNet gives your resources a private numbering scheme that no other subscription's VNet can see or collide with unless you deliberately connect them.
Address Spaces and IP Planning
Because a VNet's address space is private, it should be carved out of the RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and planned deliberately across your organization before deployment, since overlapping ranges between VNets are the single most common blocker to future connectivity. A /16 VNet (10.0.0.0/16) gives you 65,536 addresses to subdivide, and Azure reserves the first four and last address of every subnet for its own use (network address, default gateway, two DNS mappings, and broadcast), so a /24 subnet that looks like it has 256 addresses really yields 251 usable ones. Good practice is to size address spaces generously per region or environment (dev, staging, prod) up front, because resizing a VNet's address space later, while technically possible via the portal or CLI, can be disruptive if subnets and peerings already depend on the existing layout.
Cricket analogy: It's like a tournament organizer pre-allocating jersey number ranges to each franchise before the auction -- if Chennai Super Kings and Kolkata Knight Riders both hand out numbers 1 through 30 without coordination, you get chaos the moment players are compared across teams, just as overlapping CIDR blocks collide.
VNet Peering
VNet peering connects two virtual networks so resources in each can communicate using private IP addresses as if they were on the same network, with traffic routed over Microsoft's backbone rather than the public internet. Peering can be regional or global (across Azure regions), and it is non-transitive by default: if VNet A peers with VNet B, and VNet B peers with VNet C, resources in A cannot reach C unless A and C are also directly peered. Peering also does not require overlapping-free but literally requires non-overlapping address spaces -- Azure will reject the peering request outright if the two VNets' CIDR ranges intersect -- and each side can independently choose to allow or block forwarded traffic, gateway transit, and virtual network access from the peered side.
Cricket analogy: It's like two IPL franchises agreeing to a direct player-loan arrangement for a season -- Mumbai Indians can loan a player to Chennai Super Kings, but that doesn't automatically let a third franchise Chennai has a separate loan deal with borrow that same player through Mumbai.
Connectivity Beyond the VNet
For hybrid connectivity back to on-premises datacenters, Azure offers a Site-to-Site VPN Gateway (encrypted IPsec tunnel over the public internet, good for moderate throughput) or ExpressRoute (a private, dedicated circuit through a connectivity provider that bypasses the public internet entirely, offering higher bandwidth and more predictable latency for production workloads). For reaching Azure PaaS services like Storage or SQL Database privately, Service Endpoints extend the VNet's identity to the service (traffic still traverses the Microsoft backbone but the service's public endpoint is used with source restricted to the VNet), while Private Link/Private Endpoint goes further by injecting an actual private IP from your subnet into the PaaS service, making it appear as a first-class member of your VNet and eliminating public exposure entirely.
Cricket analogy: It's like the difference between chartering a private flight for a team's away tour (ExpressRoute -- dedicated, predictable, no queuing with other passengers) versus flying commercial but with a fast-track pass (VPN Gateway -- still shared infrastructure, just an encrypted, prioritized lane).
# Create a resource group, VNet with two address spaces, and a subnet using Azure CLI
az group create --name rg-network-demo --location eastus
az network vnet create \
--resource-group rg-network-demo \
--name vnet-hub \
--address-prefixes 10.0.0.0/16 \
--subnet-name snet-workload \
--subnet-prefixes 10.0.1.0/24
# Peer this VNet with a spoke VNet (run the reciprocal command on the spoke side too)
az network vnet peering create \
--name hub-to-spoke \
--resource-group rg-network-demo \
--vnet-name vnet-hub \
--remote-vnet vnet-spoke \
--allow-vnet-access true \
--allow-forwarded-traffic trueAzure automatically reserves 5 IP addresses in every subnet: the network address (.0), two addresses for Azure DNS (.1 and .2), the default gateway (.3), and the broadcast address (the last address in the range). Plan subnet sizing with this overhead in mind -- a /28 subnet has 16 addresses on paper but only 11 usable.
VNet peering will fail outright if the two virtual networks have overlapping or intersecting address spaces, even partially. Always reserve non-overlapping CIDR blocks across your entire organization's hub-and-spoke topology before creating VNets, because re-addressing a VNet after workloads and peerings are established is disruptive and often requires resource recreation.
- A VNet is a private, region-scoped IP address space (CIDR block) that isolates your Azure resources from other subscriptions by default.
- Address spaces should come from RFC 1918 private ranges and be planned org-wide to avoid overlap, since overlapping CIDRs block peering.
- Azure reserves 5 IP addresses per subnet (network, 2x DNS, gateway, broadcast), reducing usable address count below the raw subnet size.
- VNet peering routes traffic over Microsoft's backbone using private IPs but is non-transitive by default -- A-to-B and B-to-C peering does not grant A-to-C access.
- ExpressRoute provides a private, dedicated, high-bandwidth circuit to on-premises bypassing the public internet; VPN Gateway provides an encrypted IPsec tunnel over the public internet.
- Service Endpoints restrict a PaaS service's public endpoint to your VNet's identity; Private Link/Private Endpoint injects a private IP for the PaaS service directly into your subnet.
Practice what you learned
1. What happens if you try to peer two Azure VNets whose address spaces overlap?
2. By default, is VNet peering transitive?
3. Which connectivity option routes traffic over a private, dedicated circuit that bypasses the public internet entirely?
4. How many IP addresses does Azure reserve in every subnet?
5. What distinguishes a Private Endpoint from a Service Endpoint?
Was this page helpful?
You May Also Like
Subnets and NSGs in Azure
Understand how subnets partition an Azure Virtual Network and how Network Security Groups enforce stateful, priority-ordered traffic rules at the subnet and NIC level.
Azure Load Balancer Basics
Learn how Azure Load Balancer distributes Layer 4 traffic across backend pools using health probes, load balancing rules, and the Standard SKU's secure-by-default model.
Azure DNS Basics
Learn how Azure DNS hosts and resolves domain records, the standard record types, and how Alias records solve Azure-specific limitations like apex domain routing.