Azure Virtual Network Deployment with Subnets and Peering

You will deploy an Azure Virtual Network with tiered subnets and peer it to a second VNet. By the end you will have a segmented cloud network foundation that VMs and services can join.

A Virtual Network (VNet) is the fundamental isolation boundary in Azure networking: every VM, container app, or private endpoint you deploy lives inside one. Getting the address plan right on day one matters because the choices you make here, the VNet CIDR range, how you carve it into subnets, and which VNets are allowed to talk to each other, are painful to change once workloads are running. This lab walks through the entire lifecycle with the Azure CLI: planning a non-overlapping address space, creating the VNet, adding tiered subnets, and connecting two VNets with bidirectional peering so resources can reach each other over the Microsoft backbone instead of the public internet.

Architecture Overview

The lab builds two VNets. vnet-a (10.0.0.0/16) holds the application tiers: a web subnet for internet-facing or load-balanced front ends and an app subnet for middle-tier services that should never be directly exposed. vnet-b (10.1.0.0/16) holds the data subnet, databases and storage that only the app tier should reach. Splitting data into its own VNet models a common production pattern where the data platform is managed by a different team or subscription and is connected on purpose, not by default.

A few design notes on why it is built this way:

• /16 VNets, /24 subnets: each VNet has 65,536 addresses and each subnet 256 (251 usable, Azure reserves five addresses per subnet for its own routing and DNS). /24 leaves room to grow; you can add dozens more subnets per VNet later.
• Non-overlapping ranges: 10.0.0.0/16 and 10.1.0.0/16 share no addresses. VNet peering flat-out refuses overlapping address spaces, so planning this up front is what makes the peering step possible at all.
• Peering, not a VPN gateway: peering is free of gateway VMs, keeps traffic on the Microsoft backbone, and adds no bandwidth cap beyond the VMs themselves. A VPN gateway would cost money and add latency for the same east-west traffic.
• Peering is not transitive: if you later peer vnet-b to a third vnet-c, vnet-a cannot reach vnet-c through vnet-b unless you add gateway transit or a network virtual appliance. Design for this now, not after the incident.

Core Concepts Before You Start

Three ideas carry this entire lab. Skim them even if you have touched Azure networking before, most peering failures trace back to one of these being misunderstood.

1. CIDR notation is a contract, not a suggestion

A CIDR block like 10.0.0.0/16 says "the first 16 bits are fixed, the remaining 16 are mine." That gives you 2^16 = 65,536 addresses, from 10.0.0.0 to 10.0.255.255. When you carve a subnet out of it, say 10.0.1.0/24, you are promising Azure that the web tier gets exactly the 256 addresses 10.0.1.0 through 10.0.1.255, and that no other subnet may touch them. Of those 256, Azure reserves five for itself (the network address, broadcast, and three internal addresses for its virtual router and DNS), leaving 251 usable. Two practical consequences:

• Subnet prefixes must fit entirely inside the VNet prefix and must not overlap any sibling subnet. Azure enforces both at creation time.
• VNet prefixes of peered networks must not overlap at all, 10.0.0.0/16 cannot peer with 10.0.0.0/24, even though one "contains" the other. Overlap is overlap.

If binary subnetting is rusty, the only math you need for this lab: a /16 is 256 blocks of /24, and 10.0.x.x and 10.1.x.x never intersect. That is why the design uses them.

2. Subnets are the security and routing boundary

Every NIC in Azure attaches to exactly one subnet, and Network Security Groups (NSGs) attach to subnets (or NICs, but subnet-level is the maintainable pattern). There is no such thing as an NSG on a VNet. This is the whole reason the architecture has three subnets instead of one big /22 per VNet: the tier boundaries are where the firewall rules will live in the follow-up labs. Decide your tiers now; moving a VM between subnets later means stopping it and moving its NIC.

3. Peering is connectivity, not merging

Peering connects two VNets at the fabric level so packets route privately, but the VNets stay separate administrative objects: separate address spaces, separate NSGs, separate DNS zones if you use them. Peering also composes asymmetric flags, allowVirtualNetworkAccess, allowForwardedTraffic, allowGatewayTransit, and useRemoteGateways, each set per direction. This lab uses only the first (allow access); the gateway-transit pair matters later if one VNet owns a VPN/ExpressRoute gateway and the other wants to share it. And remember the golden rule: peering is non-transitive. A peered to B and B peered to C does not give A a path to C.

Environment Setup

You will need: the Azure CLI authenticated with a default resource group set.

Before you begin: plan non-overlapping CIDR ranges; peered VNets cannot overlap.

Confirm you are logged in and pointed at the right subscription before creating anything. Networking mistakes are quiet, the CLI will happily deploy into the wrong subscription if you let it.

Everything in this lab lives in one resource group so cleanup is a single command at the end. Create it and set it (plus a region) as your CLI defaults so you can stop typing -g on every command:

Common mistake: forgetting that az configure --defaults persists across terminal sessions. If a later lab deploys somewhere unexpected, check az configure --list-defaults first.

Permissions: creating VNets and peerings requires the Network Contributor role (or higher) on the resource group, and peering requires it on both VNets. If you are on a shared subscription and step 03 fails with an authorization error, this, not the command syntax, is the first thing to check.

Cost: VNets and subnets are free, and peering has no hourly charge, but data transferred across a peering is billed at both ends, about $0.01/GB each direction for same-region peering. A lab ping test costs fractions of a cent; a production workload moving terabytes does not. The billable items in this lab are the optional test VMs in the validation section, any public IPs they get, and peering data transfer. Peering across regions (global VNet peering) bills per GB at higher zonal rates, irrelevant here, but worth knowing before you copy this pattern across regions.

Step-by-Step Execution

Before touching the CLI, write the address plan down. This is the artifact you will check every command against, and it is what a reviewer (or future you) needs to understand the network:

Notice what the plan leaves free: 10.0.3.0/24 onward in vnet-a, and almost all of vnet-b. Growth headroom is a design feature, not waste, reserved ranges cost nothing until you allocate them.

{
  "name": "tyf-vnet",
  "properties": {
    "addressSpace": { "addressPrefixes": ["10.1.0.0/16"] },
    "provisioningState": "Succeeded"
  }
}

$ az network vnet subnet list -g tyf-rg --vnet-name tyf-vnet -o table
Name    AddressPrefix
------  ---------------
web     10.1.1.0/24
app     10.1.2.0/24

$ az network vnet peering list -g tyf-rg --vnet-name tyf-vnet -o table
Name           PeeringState    RemoteVnet
-------------  --------------  ------------
tyf-to-branch  Connected       branch-vnet

Step Flow Map

Each box is one step in the lab; work them in order, since later steps build on earlier state.

Progress So Far

How It Works

Testing & Validation

You should see Connected. With both directions peered, resources in app and data subnets can reach each other privately.

State checks prove the control plane agreed to peer, but they do not prove packets flow. The authoritative data-plane check is the effective routes on a network interface. If you have a VM in the app subnet (see the Azure VM Configuration lab), look at what its NIC learned from the peering:

The line that matters is 10.1.0.0/16 → VNetPeering: the app subnet now routes the entire vnet-b address space across the peering. No manual route table entries were needed, peering programs these system routes automatically on every subnet in both VNets.

For an end-to-end test, deploy a small VM into the data subnet and one into app, then ping or SSH between their private IPs:

Sub-2ms latency between VNets in the same region is the signature of peering on the Microsoft backbone, a path through the public internet would show noticeably higher and more variable times. Note that default NSG rules allow VNet-to-VNet traffic, so this works before you lock anything down; once you attach NSGs in the next lab, expect to re-visit this test.

If the ping fails, the next diagnostic layer is the effective security rules on the destination NIC, the merged result of every NSG attached to its subnet and NIC:

AllowVnetInBound is the default rule doing the heavy lifting: its VirtualNetwork service tag automatically includes peered VNet address spaces, which is why no firewall change was needed for this lab. DenyAllInBound at priority 65500 catches everything else, internet traffic to the data VM is already dropped even without any NSG you wrote.

Portal cross-check: open the resource group in the Azure portal and confirm you can see both VNets, three subnets, and two peering resources. CLI-first labs are faster to repeat, but a quick portal glance catches the "I deployed into the wrong subscription" class of mistake that CLI output will not.

Cleanup when you are done, so test VMs do not bill overnight:

Troubleshooting

Quick-reference for the failures you are most likely to hit in this lab.

Extension Ideas

• Place a VM in a subnet with Azure VM Configuration.
• Control traffic with NSGs & Route Tables.
• Codify the whole network with IaC.
• Add a third VNet and observe first-hand that peering is not transitive, then fix it with a hub-and-spoke design where a hub VNet hosts shared services.
• Attach an NSG to the data subnet that only accepts traffic from 10.0.2.0/24 (the app tier), and re-run the connectivity test from the web subnet to prove it now fails.

Key Results

• Deployed a VNet with two non-overlapping subnets.
• Connected two VNets via bidirectional peering.
• Confirmed the peering reached the Connected state.
• Built a segmented foundation for cloud workloads.

Full Command Recap

Every command from this lab in order, assuming the defaults set in Environment Setup. This is the checklist to re-run when reproducing the lab from scratch:

Notice what is not in the list: no route tables, no NSGs, no gateway resources. The entire routed, segmented, two-VNet topology is nine commands, because Azure's system routes and default NSG rules do the rest. Everything you add from here, NSGs, route tables, DNS zones, is tightening or extending this baseline, and each of those layers is a follow-up lab.

Practice Challenges