Virtual Networks

Hand a /29 subnet to the exam's favorite trap stem and the answer is 3 VMs, not 6: Azure reserves five addresses in every subnet, so a /24 yields 251 usable hosts and a /29 only 3. The address plan is the foundation every other VNet topic builds on (peering, public IPs, user-defined routes, connectivity troubleshooting all assume a correctly sized space), so it is where this page starts.

An Azure virtual network (VNet)^[1] is a logically isolated private network you define inside a single Azure region and a single subscription. You give it an address space (one or more private CIDR ranges such as 10.0.0.0/16) and it automatically spans every availability zone in that region, so you never carve a VNet up by zone (VNets and availability zones^[1]). The VNet itself is free; you pay only for the resources inside it.

Subnets and the five reserved addresses

You partition the address space into subnets, each a sub-CIDR of the VNet range (for example 10.0.0.0/24 inside 10.0.0.0/16). Azure reserves five addresses in every subnet, which is the most-missed sizing fact on the exam (subnet reservations^[2]):

Address	Reserved for
x.x.x.0	Network address
x.x.x.1	Azure default gateway
x.x.x.2 and x.x.x.3	Azure-mapped DNS (maps the platform DNS to the VNet space)
x.x.x.255 (last)	Network broadcast address

So a /24 (256 addresses) gives 251 usable host IPs, not 256, and the smallest usable subnet is a /29 (8 addresses minus the 5 reserved leaves 3 usable). A common trap stem hands you a /29 and asks how many VMs you can place: the answer is 3, not 6.

Default behavior you get for free

Three behaviors are on by default and require no configuration. First, all subnets in a VNet route to each other. Azure creates a system route so subnet-to-subnet traffic just works (you add network security groups, covered in the Network Security sibling page, only to restrict it). Second, all resources can reach the internet outbound via an Azure-assigned ephemeral IP, even with no public IP attached. Third, the address space is fully editable after creation: you can add, resize, or remove ranges later (with a peer sync step if the VNet is peered). Subnet delegation, handing a subnet to an Azure PaaS service such as Azure SQL Managed Instance or App Service so the service can inject its instances and manage subnet settings, is configured per subnet and reserves that subnet for the delegated service.

Peering is the one VNet-to-VNet primitive, and a single property of it, non-transitivity, drives most of its exam questions; the topology figure below shows that property at a glance. A spoke peered to a hub does not reach the hub's other peers.

Virtual network peering^[3] joins two VNets so their resources communicate by private IP, as though they were one network. The traffic stays entirely on the Microsoft backbone, no public internet, no gateway, and no encryption are involved, giving same-region latency equal to intra-VNet latency. There are two flavors, distinguished only by geography:

• Virtual network peering (regional) connects two VNets in the same Azure region.
• Global virtual network peering connects two VNets in different regions.

Both can span subscriptions and Microsoft Entra (formerly Azure Active Directory) tenants, both carry a nominal ingress/egress data charge, and creating a peering causes no downtime to either VNet.

Non-transitive: the rule everything else follows

Peering is non-transitive. If VNet A is peered to hub H, and H is peered to VNet B, A still cannot reach B: there is no peering between A and B, and traffic does not hop through H automatically. This is the defining constraint of a hub-and-spoke topology, and the exam tests it relentlessly. To make spokes reach each other (or reach on-premises through the hub), you must add a routing element in the hub:

• Deploy a network virtual appliance (NVA) or firewall in the hub and steer spoke traffic to it with a user-defined route (covered in the next section). This pattern is called service chaining: the UDR's next hop is the appliance's private IP, and the appliance forwards between spokes.
• Or use Azure Virtual Network Manager or Azure Virtual WAN to manage transitive connectivity at scale.

Peered VNets must also have non-overlapping address spaces. You cannot peer two 10.0.0.0/16 VNets; re-IP or resize one first.

Gateway transit: sharing one gateway across spokes

A VNet can have at most one gateway, so deploying a VPN or ExpressRoute gateway in every spoke is wasteful. Gateway transit lets spokes borrow the hub's gateway. It is a per-peering setting configured on both ends: on the hub side you enable Allow gateway transit, and on the spoke side you enable Use remote gateways (gateway transit^[3]). A spoke that uses a remote gateway must not have its own gateway. Gateway transit works on both regional and global peering. The reconciling cost note: traffic the spoke sends through the hub's gateway is billed as peering ingress/egress on the spoke, the Microsoft documentation was corrected to state this explicitly, so don't assume transit traffic is free on the spoke side.

A VNet already gives outbound internet access for free; a public IP is the separate resource you attach when you need a stable, inbound-reachable address.

A public IP address^[4] is its own Azure resource with its own properties, which you associate with a NIC (on a VM), a public load balancer, a VPN/ExpressRoute gateway, a NAT gateway, Azure Firewall, or a Bastion host. You need one for inbound internet connectivity; outbound already works through an Azure-assigned ephemeral address, so a public IP is about being reachable, not about reaching out.

One SKU that matters: Standard

The Basic SKU was retired on September 30, 2025, so every new design uses the Standard SKU (public IP SKUs^[4]). Standard differs from the retired Basic in three exam-relevant ways, and each is a recognizable question stem:

Property	Standard SKU	Basic SKU (retired)
Allocation	Static only	Dynamic or static (IPv4)
Security	Secure by default (closed to inbound until an NSG allows it)	Open by default
Availability zones	Zone-redundant by default in zone-enabled regions	Not supported (non-zonal)

Static allocation means the IP is assigned at creation and never changes until you delete the resource (IP assignment^[4]). This matters whenever something external depends on the address not changing: firewall allow-lists, DNS A records, IP-based security models, or TLS/SSL certificates bound to the IP. (Basic's dynamic IPv4 could change when a VM was stopped and started, the source of a classic "why did my IP change?" stem.)

Secure by default is the most common Standard-SKU surprise: attaching a Standard public IP to a VM does not open inbound traffic. The resource is closed until a network security group^[5] rule explicitly allows it. If a VM with a Standard public IP is unreachable, a missing NSG allow rule is the first thing to check.

Zone redundancy means a Standard IP is created across multiple zones and survives any single-zone failure, in regions that have availability zones. A public IP's availability-zone setting is fixed at creation and cannot be changed later. (Deeper load-balancer behavior, internal vs. public, the frontend IP configuration, lives in the DNS and Load Balancing sibling page.)

Azure already routes everything by a system route table it builds and maintains for each subnet. You write a user-defined route only to override a specific system route. Building on the addressing and peering model above, this is how Azure decides where a packet goes and how you override that decision.

System routes you get automatically

Every subnet receives system routes^[6] you cannot delete: a Virtual network route for intra-VNet traffic, a 0.0.0.0/0 → Internet default route, and None routes that drop the RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) plus 100.64.0.0/10. Azure adds more optional system routes as you enable features: a Virtual network peering route per peered range, and Virtual network gateway routes for gateway/BGP prefixes.

User-defined routes (UDRs)

To change routing, you don't edit system routes. You create a route table, add user-defined routes, and associate the table to a subnet. Each subnet has zero or one route table. A UDR's next hop is one of exactly five types (next hop types^[6]):

Next hop type	Use
Virtual appliance	Send traffic to an NVA/firewall (you also give its private IP)
Virtual network gateway	Send traffic to the VPN gateway (forced tunneling)
Virtual network	Override default intra-VNet routing
Internet	Force traffic to the internet
None	Drop the traffic

You cannot set Virtual network peering or service endpoint as a UDR next hop. Azure creates those route types only when you configure the feature.

Forced tunneling

The canonical UDR is forced tunneling: a route for 0.0.0.0/0 whose next hop is a firewall appliance or the VPN/ExpressRoute gateway, associated to a subnet so that all outbound traffic is sent on-premises (or through the NVA) for inspection instead of going directly to the internet (0.0.0.0/0 route^[6]). This is how you override Azure's default internet route.

How Azure picks a route (two-step)

Route selection is longest-prefix-match first, source priority second, and getting the order right answers most routing questions:

1. Longest prefix match. For 10.0.0.5, a route for 10.0.0.0/24 beats one for 10.0.0.0/16 because it is more specific, regardless of source.
2. Source priority, only on an exact prefix tie. When two routes share the same prefix, the order is User-defined route → BGP route → system route. This is exactly why a UDR for 0.0.0.0/0 overrides the default internet route: same prefix, UDR wins.

Reconcile the one apparent exception: routes for the VNet itself, VNet peerings, and service endpoints are preferred system routes you cannot override, even with a more-specific prefix or a UDR. A service-endpoint route always wins for that service's addresses.

When traffic doesn't flow, the question is always one of two things, and each has its own Azure diagnostic: is the packet being routed somewhere wrong, or is it being blocked? The decision tree below maps each symptom to the tool that answers it. Reading the routing rules above is enough to use both.

Effective routes: what is actually winning

The routes you author are not the routes that run. Azure merges your UDRs with the system and BGP routes, applies the longest-prefix and source-priority rules from the previous section, and the result is the effective routes on a NIC. You read them per network interface (Portal: the NIC's Effective routes, or az network nic show-effective-route-table) to see the final, evaluated table and which next hop a given destination resolves to (diagnose routing^[7]). This is also how you confirm a peering exists: if VNet peering is active, every subnet shows routes with next hop type Virtual network peering for each peered address range. A missing peering route in the effective table is your evidence the peering isn't there or isn't synced.

IP Flow Verify: allowed or denied, and by which rule

Effective routes tell you where a packet would go; they don't tell you whether a security rule blocks it. IP Flow Verify^[8], a feature of Azure Network Watcher, takes a 5-tuple (direction (inbound/outbound), protocol, local IP/port, remote IP/port) and tells you whether the traffic is Allowed or Denied, and crucially which network security group rule made the decision (IP Flow Verify^[8]). If the verdict is Denied, it names the blocking rule so you fix the right NSG.

Which tool for which symptom

Use the two together, and pick by symptom:

• "Traffic goes to the wrong place / a peer is unreachable" → a routing problem. Read effective routes to see which route wins and whether the peering/UDR route is present.
• "Traffic is dropped / connection refused" → likely a security problem. Run IP Flow Verify to confirm allow/deny and find the responsible NSG rule.
• "End-to-end path is failing and I don't know where" → use Network Watcher Connection Monitor / connection troubleshoot to test the full hop-by-hop path between two endpoints.

The deeper NSG rule mechanics, priority numbers, default rules, application security groups, belong to the Network Security sibling page; here the point is only that IP Flow Verify is the tool that turns a vague "it's blocked" into a named rule.