Azure Virtual Networks Explained

What is a Virtual Network?

A Virtual Network is a logically isolated section of the Azure cloud. Think of it as your own private network that exists entirely within Azure’s data centers. You define the address range, decide which resources can join, and control how traffic flows.

When you create a VM or a managed database in Azure, you place it inside a VNet. That’s how it gets an IP address, communicates with other resources, and optionally reaches the internet. Without a VNet, nothing can talk to anything.

The key word is “virtual.” There is no physical cable or switch. Azure handles all of the underlying hardware. What you manage is the logical structure: address ranges, subnets, route tables, and security rules.

Why VNets matter

VNets do three things that make cloud infrastructure safe and reliable:

Isolation. By default, traffic cannot move between VNets. If you create a VNet for production and a VNet for development, they are completely separate. A misconfigured dev environment cannot touch your production database.

Control. You decide which address ranges to use, which subnets to create, and which security rules to apply. This mirrors how network engineers design on-premises networks, but without buying switches or running cables.

Integration. VNets connect to on-premises networks through VPN gateways and ExpressRoute. They also connect to each other through VNet peering. This makes Azure an extension of your existing infrastructure rather than a separate island.

Understanding address spaces: what CIDR means

When you create a VNet, Azure asks you for an address space in CIDR notation. CIDR stands for Classless Inter-Domain Routing, and it’s just a way to describe a range of IP addresses using a single number.

The format is: IP address / prefix length. The prefix length tells you how many IP addresses are in the range. A smaller number means more addresses.

A /16 address space like 10.0.0.0/16 gives you 65,536 IP addresses to work with. You can then carve that up into subnets like 10.0.1.0/24 for web servers and 10.0.2.0/24 for databases.

Use private IP ranges. RFC 1918 reserves three blocks for private use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Always pick from one of these for your VNets.

Core components of a VNet

A VNet is made up of several building blocks. You don’t need to configure all of them on day one, but understanding what exists helps you make better decisions.

Address space. The total range of IP addresses available in the VNet. You can add multiple address ranges to a single VNet.

Subnets. Subdivisions of the address space. You place resources like VMs into subnets. Subnets let you organize resources and apply different security rules to different groups.

Network Security Groups (NSGs). Firewall rules that control which traffic is allowed into and out of a subnet or a specific network interface.

Route tables. Rules that tell Azure where to send traffic. By default, Azure creates system routes. You can add custom routes to send traffic through a firewall or VPN.

DNS settings. By default, Azure provides DNS resolution. You can point your VNet to a custom DNS server, such as one running on-premises or Azure Private DNS.

Creating a VNet with the Azure CLI

The Azure CLI is the fastest way to create and manage VNets. Every command starts with az network vnet.

First, create a resource group to hold your VNet:

az group create \
  --name rg-networking-demo \
  --location eastus

Now create the VNet with a /16 address space:

az network vnet create \
  --name vnet-prod-eastus \
  --resource-group rg-networking-demo \
  --location eastus \
  --address-prefixes 10.0.0.0/16

Add a subnet for web servers:

az network vnet subnet create \
  --name snet-web \
  --resource-group rg-networking-demo \
  --vnet-name vnet-prod-eastus \
  --address-prefixes 10.0.1.0/24

Add a subnet for databases:

az network vnet subnet create \
  --name snet-data \
  --resource-group rg-networking-demo \
  --vnet-name vnet-prod-eastus \
  --address-prefixes 10.0.2.0/24

List all VNets in a resource group:

az network vnet list \
  --resource-group rg-networking-demo \
  --output table

Show detailed information about a VNet, including its subnets and address space:

az network vnet show \
  --name vnet-prod-eastus \
  --resource-group rg-networking-demo

Naming conventions

Azure has no strict naming rules for VNets, but consistent naming saves hours of confusion later. A common pattern is:

vnet-{purpose}-{region}-{environment}

Examples: vnet-prod-eastus, vnet-dev-westeu, vnet-shared-hub.

Subnets follow a similar pattern: snet-{purpose}. Examples: snet-web, snet-db, snet-mgmt, snet-gateway.

VNets are regional

A VNet exists in a single Azure region. Resources in different regions cannot join the same VNet. If you have resources in East US and West Europe, you need a VNet in each region.

To connect VNets in different regions, use global VNet peering. This is different from peering VNets in the same region and has separate pricing. We cover this in the VNet Peering page.

Limits to know

Azure sets default limits per subscription. These can usually be raised by contacting support, but knowing the defaults helps you plan:

You can create up to 1,000 VNets per subscription per region by default. Each VNet supports up to 3,000 subnets. The minimum subnet size is /29 (gives you 3 usable IPs after Azure reserves 5). There is no maximum VNet size — you can use an entire /8 if needed.

Azure always reserves 5 IP addresses in every subnet: the network address, the broadcast address, and three addresses Azure uses internally. So a /29 subnet with 8 total addresses gives you only 3 usable IPs.