Virtual Networks (VNet)
Azure Virtual Network is your isolated private network in the cloud. It defines address spaces, subnets, routing boundaries, and how services communicate securely.
What Is It? (Simple Explanation)
A VNet is your own private office network, but inside Azure. You control address ranges and decide which systems can talk to each other.
Why Do We Need It?
- To isolate workloads from other tenants and networks.
- To segment applications into security zones using subnets.
- To connect Azure resources privately and extend to on-premises.
Real-world Analogy
A VNet is a corporate campus. The full campus is address space. Buildings are subnets. Roads between campuses are peering links.
How It Works (Technical)
- VNet address space is defined with one or more CIDR blocks.
- Subnets carve portions of that space for workload tiers.
- System routes allow intra-VNet traffic by default.
- VNet Peering links two VNets over Azure backbone with low latency.
Address Space and Subnets
| Tier | Subnet | Sample CIDR | Purpose |
|---|---|---|---|
| Web | snet-web | 10.20.1.0/24 | Inbound-facing app entry |
| App | snet-app | 10.20.2.0/24 | Business logic tier |
| Data | snet-data | 10.20.3.0/24 | Databases, cache, private endpoints |
VNet Peering
Peering connects two VNets privately. It is not transitive by default: if A peers with B and B peers with C, A cannot automatically reach C.
Visual Representation
Hands-on Commands
# Create two VNets az network vnet create -g rg-net --name vnet-hub --address-prefix 10.0.0.0/16 --subnet-name snet-hub --subnet-prefix 10.0.1.0/24 az network vnet create -g rg-net --name vnet-spoke --address-prefix 10.1.0.0/16 --subnet-name snet-app --subnet-prefix 10.1.1.0/24 # Create peering both directions az network vnet peering create -g rg-net --name hub-to-spoke --vnet-name vnet-hub --remote-vnet vnet-spoke --allow-vnet-access az network vnet peering create -g rg-net --name spoke-to-hub --vnet-name vnet-spoke --remote-vnet vnet-hub --allow-vnet-access # Verify peering status az network vnet peering list -g rg-net --vnet-name vnet-hub --output table
Real-world Use Case
An enterprise uses a hub VNet with shared firewall and VPN gateway, and one spoke VNet per application team. This enforces central governance while keeping teams isolated.
Debugging Scenario
Issue: VM in spoke cannot reach shared service in hub.
- Check peering state is Connected on both sides.
- Verify NSG rules on source and destination subnets.
- If using gateway transit, ensure flags are configured correctly.
- Check route tables for forced route that bypasses expected path.
Interview Questions
Beginner
A logically isolated private network in Azure for hosting and connecting resources.
Yes. Subnets divide VNet address space for segmentation and policy control.
Intermediate
No, not by default. Transitive communication requires explicit architecture using hub routing constructs.
Scenario-based
Use hub-and-spoke VNets, peer spokes to hub, and centralize firewall, gateway, and DNS in the hub.
Summary
VNet design is the foundation for all Azure traffic flow. Plan address spaces early, segment into subnets, and use peering patterns that match governance and scale needs.