Virtual Networks & Subnets

By the end of this lesson you will be able to plan an address space, create a virtual network with subnets, explain why new subnets are private by default, give a subnet safe outbound internet access, and connect two networks with peering. Networks are the roads of your cloud, so it pays to plan them before you build houses.

What is a virtual network?

An Azure Virtual Network (VNet) is your own private network in one Azure region. Resources inside it, such as virtual machines, talk to each other using private IP addresses. Nothing from the internet can reach them unless you allow it.

Picture a gated housing society in Kochi. The society (VNet) has its own internal roads and house numbers. Blocks A, B and C are subnets. The main gate decides who comes in and goes out. Other societies cannot drive in unless both sides agree to build a connecting road.

Key facts:

• A VNet belongs to one region and one subscription.
• You choose its address space in CIDR notation, such as 10.10.0.0/16.
• You split the address space into subnets, such as 10.10.1.0/24 for web servers.
• Traffic between subnets in the same VNet is allowed by default. You restrict it with network security groups.

CIDR in one minute

CIDR (Classless Inter-Domain Routing) notation writes a range as an address plus a prefix length. The prefix says how many bits are fixed. A smaller prefix means a bigger range:

Use the private ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Pick ranges that do not overlap with your office network or other VNets, because overlapping networks cannot be connected later. This is the most expensive mistake to fix.

Azure reserves five addresses in every subnet: the first four and the last one. So a /24 subnet gives you 256 − 5 = 251 usable addresses, and a /29 gives only 3.

Step by step: create a VNet with two subnets

Step 1: create a resource group and a VNet with a web subnet.

az group create --name rg-net-demo --location centralindia --output none

az network vnet create --resource-group rg-net-demo --name vnet-shop-cin \
  --address-prefixes 10.10.0.0/16 \
  --subnet-name snet-web --subnet-prefixes 10.10.1.0/24 \
  --query "newVNet.{name:name, space:addressSpace.addressPrefixes}"

{
  "name": "vnet-shop-cin",
  "space": [
    "10.10.0.0/16"
  ]
}

The create command wraps its result in a newVNet object, which is why the query starts with newVNet.

Step 2: add a subnet for databases.

az network vnet subnet create --resource-group rg-net-demo --vnet-name vnet-shop-cin \
  --name snet-data --address-prefixes 10.10.2.0/24 --output none

Step 3: list the subnets.

az network vnet subnet list --resource-group rg-net-demo --vnet-name vnet-shop-cin \
  --query "[].{Name:name, Prefix:addressPrefix}" --output table

Name       Prefix
---------  ------------
snet-web   10.10.1.0/24
snet-data  10.10.2.0/24

These outputs are traced from the documented CLI shapes.

Private subnets and outbound access

For years, a VM without a public IP still got a hidden, Microsoft-owned IP for reaching the internet. This was called default outbound access. It was convenient but unpredictable: the IP could change, and it went against "deny by default" security.

The recommended explicit method is a NAT gateway attached to the subnet. It gives every VM in the subnet a fixed, known public IP for outbound traffic, while still blocking unsolicited inbound traffic. Think of the society's one exit gate with a guard who notes every vehicle leaving.

az network public-ip create --resource-group rg-net-demo --name pip-nat-cin --sku Standard --output none
az network nat gateway create --resource-group rg-net-demo --name nat-shop-cin \
  --public-ip-addresses pip-nat-cin --output none
az network vnet subnet update --resource-group rg-net-demo --vnet-name vnet-shop-cin \
  --name snet-web --nat-gateway nat-shop-cin --output none

Other explicit methods are a public IP on the VM, outbound rules on a Standard load balancer, or routing through a firewall.

Connecting networks

VNet peering joins two VNets so their resources talk over Microsoft's backbone using private IPs. Peering works across regions and subscriptions. You create it from both sides.

az network vnet peering create --resource-group rg-net-demo --name shop-to-hub \
  --vnet-name vnet-shop-cin --remote-vnet vnet-hub-cin --allow-vnet-access --output none

Peering is not transitive: if A peers with B and B peers with C, A cannot reach C through B. Large companies use a hub-and-spoke design: shared services such as a firewall live in a hub VNet, and each app has its own spoke VNet peered to the hub.

For connecting to offices and data centres:

• VPN Gateway: an encrypted tunnel over the internet, like a site-to-site VPN from a branch office in Lucknow.
• ExpressRoute: a private connection through a telecom partner that does not use the public internet.

Reaching PaaS services privately

Services such as Storage, SQL Database and Key Vault have public endpoints by default. Two features keep traffic private:

• Private endpoint: puts a private IP for the service inside your subnet. Combined with disabling public access, the service is reachable only from your network. This is the modern, preferred option.
• Service endpoint: an older, simpler option that lets a subnet reach a service's public endpoint over the Azure backbone and lock the service to that subnet.

Private endpoints rely on private DNS zones, such as privatelink.vault.azure.net, so the service's normal name resolves to the private IP. Azure-provided DNS inside a VNet uses the special address 168.63.129.16.

Common mistakes

• Overlapping address spaces. Plan a range per environment and region before you build anything.
• Tiny subnets. Some services, such as App Service VNet integration and AKS, need many addresses. Leave room to grow.
• Expecting new VMs to reach the internet automatically. In private subnets they need a NAT gateway or another explicit method.
• Expecting transitive peering. Use a hub with a firewall or Azure Virtual WAN for any-to-any routing.

Key points

• A VNet is a private network in one region; subnets divide its CIDR address space.
• Azure reserves five IPs per subnet; avoid overlapping ranges with other networks.
• New VNets created with recent API versions have private subnets by default; use a NAT gateway for outbound access.
• Peering connects VNets but is not transitive; VPN Gateway and ExpressRoute connect on-premises networks.
• Private endpoints bring PaaS services into your VNet with a private IP.

az group create --name rg-hospital-net --location indiasouthcentral --output none
az network vnet create --resource-group rg-hospital-net --name vnet-hospital-isc \
  --address-prefixes 10.20.0.0/16 --subnet-name snet-web --subnet-prefixes 10.20.1.0/24 --output none
az network vnet subnet create --resource-group rg-hospital-net --vnet-name vnet-hospital-isc \
  --name snet-app --address-prefixes 10.20.2.0/24 --output none
az network vnet subnet create --resource-group rg-hospital-net --vnet-name vnet-hospital-isc \
  --name snet-data --address-prefixes 10.20.3.0/24 --output none