In one sentence. A virtual network is your own private LAN inside Azure; you choose its address range, split it into subnets, plug servers in, and nothing outside can reach it until you build a link (peering to another VNet, VPN to the office). A virtual network is a private LAN that exists only in software. You choose its address range, split it into subnets, and plug servers into subnets. Nothing outside can see it until you deliberately connect it: peering joins it to another Azure network, a VPN joins it to the office. It behaves like the networks you ran in telecom, except the routers and switches are settings, not hardware.
How a VNet is built
- Choose an address range10.10.0.0/16, chosen so it never overlaps the office or other VNets.
- Split it into subnetsWeb 10.10.1.0/24, Data 10.10.2.0/24. Azure keeps 5 addresses in each.
- Attach rules per subnetAn NSG (firewall list) and optionally a route table.
- Connect it outward only on purposePeering to another VNet, VPN or ExpressRoute to the office, private endpoints for Azure services.
You, the admin: build the network before the servers
- Virtual networks › + Create. Name VNet1, region Australia East. IP addresses tab: address space 10.10.0.0/16. Add subnet Web 10.10.1.0/24 and subnet Data 10.10.2.0/24. Delete the default subnet if unused.
- Security tab: Bastion, Firewall, DDoS all optional; leave off for now.
- Review + create. Later, add subnets under VNet1 › Subnets › + Subnet; attach an NSG or route table on the same form.
Script: az network vnet create -g RG-Net -n VNet1 --address-prefix 10.10.0.0/16 --subnet-name Web --subnet-prefix 10.10.1.0/24
- Azure keeps 5 addresses in every subnet (network, broadcast, .1 gateway, two DNS). A /24 gives 251 usable; the smallest subnet allowed is /29.
- Pick ranges that will never clash with the office or another VNet; overlapping ranges cannot be peered or VPN-connected, and fixing it later means re-addressing.
- Some services demand their own specially named subnet:
GatewaySubnet(/27 recommended) for VPN,AzureBastionSubnet(/26 minimum),AzureFirewallSubnet(/26). App Service VNet integration and Container Apps need a delegated subnet. - A VM's private IP is dynamic by default and can change after deallocation. Make it static on the NIC (NIC › IP configurations), never inside Windows.
Public IP addresses
| SKU | Address | Zones | Default behaviour |
|---|---|---|---|
| Basic (being retired) | Dynamic or static | No | Open to everything |
| Standard | Always static | Zone-redundant option | Closed until an NSG rule allows traffic |
A Standard load balancer needs Standard IPs on it and on its VMs; SKUs cannot mix. For many VMs with no public IP that still need to reach the internet in a controlled way, attach a NAT gateway to the subnet.
Peering: joining two VNets
What peering gives you: A ↔ B and B ↔ C
VNet A10.1.0.0/16
→peered
VNet B (hub)10.0.0.0/16
→peered
VNet C10.2.0.0/16
Direct links work
- A talks to B by private IP
- B talks to C by private IP
- No gateway, no VPN, Microsoft backbone
- Works across regions, subscriptions and tenants
What it does NOT give you: A ↔ C through B
VNet A10.1.0.0/16
→arrives here…
VNet Bdoes not forward A's traffic onward
→…and stops
VNet Cunreachable from A
Peering is not transitive
- Each peering is a link between exactly two VNets
- A VM in A pinging C gets no reply
- Fix 1: peer A to C directly
- Fix 2: put a firewall VM in B, add user-defined routes in A and C pointing at it, tick "allow forwarded traffic"
Which is better?
Exam cue: "VNet A cannot reach VNet C" with A-B and B-C peered = not transitive. Add the A-C peering or route through a hub firewall.
You, the admin: connect VNet1 (Sydney) to VNet2 (Melbourne)
- VNet1 › Peerings › + Add. The form creates both halves at once: name the link from this side and from the remote side, pick VNet2 (any subscription you can see).
- Leave Allow access ticked both ways. Tick Allow forwarded traffic only if a firewall VM will route between them. Allow gateway transit on the side that owns a VPN gateway and Use remote gateways on the side that wants to borrow it.
- Add. Status must read Connected on both VNets within a minute; Initiated means the other half is missing.
- Same region = regional peering; different regions = global peering. Traffic stays on Microsoft's backbone, private IPs, no gateway, low latency, charged per GB.
- Not transitive: A-B and B-C does not give A-C. Either peer A-C too, or build hub-and-spoke where the hub holds a firewall and spokes use user-defined routes through it.
- A VNet can borrow only one remote gateway.
Trap wording. "How many usable IPs in a /24" = 251. "A cannot reach C through B" = not transitive. "Spoke must use the hub's VPN" = gateway transit + use remote gateways, and the on-prem router must know the spoke's range.