Azure Networking: VNets, Subnets, and Peering
Virtual networks are the backbone of Azure networking. They let your resources communicate securely — with each other, with the internet, and with your on-premises network.
What is an Azure Virtual Network?
Think of a virtual network (VNet) as a private office building in the cloud.
Your VMs, databases, and other resources are like offices inside the building. They can talk to each other freely because they’re on the same internal network — just like colleagues in the same office.
Subnets are floors in the building. The web servers might be on Floor 1, the databases on Floor 2. You can control who goes between floors using security rules.
Peering connects two buildings together with a private hallway. Resources in Building A can reach resources in Building B without going through the public internet.
VNets — your private cloud network
When you create a VNet, you define:
- Address space — the range of private IP addresses available (e.g., 10.0.0.0/16 = 65,536 addresses)
- Region — VNets exist in a single Azure region
- Subnets — subdivisions of the address space
Key facts about VNets:
| Fact | Detail |
|---|---|
| Isolation | Each VNet is isolated from others by default |
| Region-scoped | A VNet exists in one region (but can peer with other regions) |
| Free to create | No charge for the VNet itself |
| Private IP addresses | Resources in a VNet get private IPs automatically |
| DNS | Azure provides built-in DNS, or you can use custom DNS |
Summit Construction’s network design
VNet: summit-prod-vnet (10.0.0.0/16)
├── Subnet: web-tier (10.0.1.0/24) — 256 addresses
│ ├── VM: portal-web-01
│ └── VM: portal-web-02
├── Subnet: app-tier (10.0.2.0/24)
│ └── VM: portal-app-01
└── Subnet: data-tier (10.0.3.0/24)
└── SQL Database: portal-dbEach subnet has its own network security group (NSG) controlling which traffic flows between tiers.
Subnets — segmenting your network
Subnets divide a VNet into smaller sections. This lets you:
- Organise resources — group related resources (web servers in one subnet, databases in another)
- Apply security rules — attach Network Security Groups (NSGs) to control traffic per subnet
- Manage IP addresses — allocate address ranges efficiently
Security example: Harbour Health’s database subnet only allows traffic from the application subnet. No direct internet access to the database — ever.
| Subnet | Allowed Inbound Traffic | Blocked |
|---|---|---|
| Web subnet | Internet (ports 80, 443) | Everything else |
| App subnet | Web subnet only | Internet, direct DB access |
| Data subnet | App subnet only | Internet, web subnet |
Key concept: Subnets within the same VNet can communicate by default. You use NSGs to restrict traffic between subnets — this is how you implement network segmentation (a defence-in-depth practice).
VNet peering — connecting networks
By default, VNets are isolated. VNet peering connects two VNets so resources can communicate using private IP addresses:
| Feature | Regional Peering | Global Peering |
|---|---|---|
| Connects | VNets in the same region | VNets in different regions |
| Latency | Same as within a single VNet | Slightly higher (cross-region) |
| Traffic stays | On Microsoft backbone network | On Microsoft backbone network |
| Cost | Charged per GB transferred | Charged per GB (higher rate for cross-region) |
Important peering rules:
- Peering is not transitive — if VNet A peers with VNet B, and VNet B peers with VNet C, VNet A cannot reach VNet C automatically
- Both VNets must explicitly set up peering
- Traffic uses Microsoft’s backbone network (never the public internet)
- Address spaces must not overlap
Exam tip: Peering is not transitive
This is a commonly tested concept. If VNet A connects to VNet B, and VNet B connects to VNet C:
- A ↔ B: ✅ can communicate
- B ↔ C: ✅ can communicate
- A ↔ C: ❌ CANNOT communicate (unless you also peer A with C)
Think of it like phone contacts. Just because you have Bob’s number and Bob has Carol’s number doesn’t mean you have Carol’s number.
🎬 Video walkthrough
Flashcards
Knowledge Check
Summit Construction has web servers and database servers in the same VNet but different subnets. They want to prevent the web servers from directly accessing the database. What should they use?
Harbour Health has VNet A peered with VNet B, and VNet B peered with VNet C. Can resources in VNet A communicate with resources in VNet C?
Next up: Connecting to Azure from the outside — VPN Gateway, ExpressRoute, Azure DNS, and public/private endpoints.