Skip to content
FR

Azure Virtual Networks: Subnets, Peering and Routes

Step 21 of 30

Azure Virtual Networks for AZ-104: Subnets, Peering and Routes

Introduction

Configuring Azure virtual networks for AZ-104 requires an address plan, explicit connectivity and a clear routing model. This lesson opens the AZ-104 skills area Implement and manage virtual networking (15–20% of the exam). The study guide objective is configure and manage virtual networks in Azure: create and configure virtual networks and subnets, create and configure virtual network peering, configure public IP addresses, configure user-defined network routes, and troubleshoot network connectivity.

A virtual network (VNet) is your private, isolated network in Azure. Almost every other service in the exam sits on top of it: virtual machines, App Service integration, private endpoints, load balancers. Questions here are scenario based and test details: address ranges that overlap, a peering that is half configured, a route that sends traffic to the wrong place, or a public IP of the wrong SKU.

After this lesson you will be able to design address spaces and subnets, connect networks with peering, choose and attach public IP addresses, override default routing with route tables, and use diagnostic tools to find why two resources cannot talk.

Learning objectives

  • Plan non-overlapping address spaces and subnets, and know the addresses Azure reserves.
  • Create virtual networks and subnets with the portal and the CLI.
  • Configure peering between virtual networks and explain its properties (forwarded traffic, gateway transit, remote gateways).
  • Compare public IP SKUs and allocation methods.
  • Read system routes and build user-defined routes with a route table.
  • Troubleshoot connectivity with Network Watcher tools.

Virtual networks and subnets

Address space

A VNet has one or more address spaces written in CIDR notation using private ranges from RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16); Azure also allows other ranges but warns against public ones. A VNet lives in one region and one subscription, and resources in it communicate privately by default.

A subnet is a range carved out of the VNet address space. Resources receive their private IP from a subnet. Facts the exam likes:

  • Azure reserves five addresses in each subnet: the network address, the broadcast address, and three for Azure (default gateway and two for DNS mapping). A /29 therefore leaves 3 usable addresses, and the smallest subnet is /29 (the largest /2).
  • Subnets inside a VNet cannot overlap each other.
  • Address spaces of VNets that you plan to peer or connect by VPN must not overlap. Plan this early. You can resize a peered VNet address space without deleting its peerings, but synchronize every remote peer after the change and preserve non-overlap.
  • Some services need a dedicated subnet with a fixed name: GatewaySubnet (VPN or ExpressRoute gateway, recommended /27 or larger), AzureBastionSubnet (/26 or larger for dedicated Bastion SKUs; Developer does not require it), AzureFirewallSubnet (/26 or larger). Others need a subnet delegated to them, such as App Service VNet integration.
  • You can add address space to an existing VNet, and resize or add subnets, if the subnet is empty or the change does not conflict with attached resources.
Bash
az network vnet create -g rg-net -n vnet-hub -l westeurope \
  --address-prefixes 10.10.0.0/16 \
  --subnet-name snet-app --subnet-prefixes 10.10.1.0/24

az network vnet subnet create -g rg-net --vnet-name vnet-hub \
  -n snet-data --address-prefixes 10.10.2.0/24

Default behaviour

Default VNet routes and NSG rules permit communication between subnets, but service restrictions and guest firewalls can still block it. Private subnet defaults changed in 2026: VNets created with API versions released after March 31, 2026 use private subnets by default (defaultOutboundAccess: false); the portal also defaults to private subnets. Existing VNets are unchanged, and older API versions can retain the earlier behavior. Plan an explicit outbound method such as NAT Gateway, load-balancer outbound rules, a VM public IP or Azure Firewall. The presence of a system Internet route alone does not supply outbound SNAT connectivity. Public Microsoft endpoints also need a permitted outbound path.

Direct internet access to a VM requires a public frontend plus permitted NSG/guest rules; a public load balancer or other proxy can provide that frontend without a public IP on the VM. Azure-provided DNS resolves names within a VNet; peering alone does not extend this default name resolution to another VNet. Use linked Azure Private DNS zones or a suitable custom resolver for names across VNets.

Virtual network peering

What peering does

Peering connects two VNets so that resources communicate using private IPs over the Microsoft backbone, with low latency and no gateway. There are two forms:

  • Virtual network peering: both VNets in the same region.
  • Global virtual network peering: VNets in different regions.

Peering works across subscriptions and Microsoft Entra tenants (with proper permissions). It is not transitive: if A is peered with B and B with C, then A cannot reach C. Use a hub-and-spoke design with a firewall or gateway in the hub and routes in the spokes, or peer A and C directly.

Peering is two links

A peering consists of a link on each side. Each link must be created, and the status shows Initiated after the first link and Connected after both exist. Creating a peering in the portal can create both links in one step if you have rights on both VNets. If one side is missing, traffic does not flow and the troubleshooting answer is "create the reverse link".

Peering options

Option What it does When to use
Allow virtual network access Permits VNet-to-VNet access in the configured direction; check both peering links Normally on
Allow forwarded traffic Accepts traffic that did not originate in the peered VNet (for example forwarded by a network virtual appliance) Hub with firewall/NVA routing spoke traffic
Allow gateway transit This VNet shares its VPN/ExpressRoute gateway Set on the hub that owns the gateway
Use remote gateways This VNet uses the remote VNet's gateway Set on the spoke; requires the hub to allow gateway transit

Keep peered address spaces non-overlapping. Address-space changes do not require deleting peerings: after each change, synchronize the peering on every remote peered VNet so its learned prefixes are current. For example, if the hub address space changes, synchronize spoke1-to-hub on the spoke with az network vnet peering sync -g rg-net --vnet-name vnet-spoke1 -n spoke1-to-hub. Check synchronization and effective routes before relying on the new prefix. Peering data transfer is billed.

A spoke using a remote gateway cannot have its own gateway, and only one of its peerings can use remote gateways. The following commands assume both VNets already exist in rg-net and the hub already has a supported gateway; enable gateway transit on the hub first. Across resource groups or subscriptions, pass the remote VNet’s full resource ID instead of its short name.

Bash
az network vnet peering create -g rg-net -n hub-to-spoke1 \
  --vnet-name vnet-hub --remote-vnet vnet-spoke1 \
  --allow-vnet-access --allow-gateway-transit
az network vnet peering create -g rg-net -n spoke1-to-hub \
  --vnet-name vnet-spoke1 --remote-vnet vnet-hub \
  --allow-vnet-access --use-remote-gateways

Public IP addresses

A public IP address resource gives a resource an internet-routable address. It can be associated with a VM network interface, a load balancer front end, an Application Gateway, a VPN gateway, a Bastion host or a NAT gateway.

Property Options Notes
SKU Basic (retired for most uses), Standard Standard is the current choice. Basic public IPs were retired on 30 September 2025, so new designs use Standard. Existing unsupported Basic resources may still operate; Cloud Services (extended support) has a documented exception.
Assignment Static, Dynamic Standard IPv4 is always static. Dynamic assignment applied to Basic.
Security Standard is secure by default: closed to inbound traffic until an NSG explicitly allows it A VM with a Standard public IP and no NSG rule is not reachable
Availability zones Standard supports zone-redundant or zonal Must match the resource it fronts
Version IPv4, IPv6
Public IP prefix A contiguous block of addresses Useful to give partners a fixed range to allow-list

Standard SKU resources must be paired with Standard SKU: a Standard public load balancer needs Standard public IPs. A public IP that is allocated but not associated still costs money, so remove unused ones.

User-defined routes

How Azure routes traffic

Azure creates system routes for every subnet: traffic within the VNet, to peered VNets (when peered), to the internet (0.0.0.0/0) and others. You override or extend them with a route table containing user-defined routes (UDRs) that you associate with one or more subnets.

Each route has an address prefix and a next hop type:

Next hop type Meaning
Virtual appliance Send to a network virtual appliance or firewall by its private IP
Virtual network gateway Send to a VPN gateway
Virtual network Route within the VNet; the API/CLI next-hop value is VnetLocal
Internet Send to the internet
None Drop the traffic (black hole)

Route selection: normally compare the longest matching prefix, then prefer UDR > BGP > system when the prefixes match. There are exceptions: system routes for the VNet, peering and service endpoints are preferred over BGP routes, even a more-specific BGP route. Service-endpoint routes cannot be overridden by UDRs. Read the effective route and its source instead of applying the normal priority rule blindly.

Forcing traffic through a firewall

To inspect ordinary internet-bound traffic from a subnet, create a route table with a route 0.0.0.0/0 to next hop type Virtual appliance with the firewall's private IP, associate it with the subnet, and permit the flow through the firewall. For a third-party NVA, enable IP forwarding on its Azure NIC and in its guest OS. Azure Firewall manages its own forwarding; do not apply the guest-NIC procedure to the managed service. A 0.0.0.0/0 route does not override more-specific VNet/peering routes or protected service-endpoint routes; inspect the effective paths before claiming all traffic is inspected. For spoke-to-spoke traffic through a hub firewall, each spoke needs a route to the other spoke's prefix via the firewall, and peering from the spoke must allow forwarded traffic.

Bash
az network route-table create -g rg-net -n rt-spoke1 -l westeurope
az network route-table route create -g rg-net --route-table-name rt-spoke1 \
  -n to-internet-via-fw --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance --next-hop-ip-address 10.10.0.4
az network vnet subnet update -g rg-net --vnet-name vnet-spoke1 \
  -n snet-app --route-table rt-spoke1

A route table can be associated with many subnets in the same region and subscription, but a subnet has at most one route table. If a route table is changed, the effect is applied to the associated subnets quickly; you can inspect the result in Effective routes on a network interface.

Troubleshooting connectivity

Connectivity problems usually come from one of four layers. Work through them in order.

  1. Addressing and DNS: wrong subnet, overlapping ranges, a name that does not resolve (custom DNS server unreachable).
  2. Security rules: NSG on the subnet or NIC, or a firewall, blocking the flow.
  3. Routing: a UDR sending traffic to an appliance that drops it, or a missing return route.
  4. Platform or guest: a VM-level firewall, a service not listening, peering not connected.

Tools in Network Watcher (enabled per region):

Tool Question it answers
IP flow verify Does an NSG rule allow or deny this specific 5-tuple to or from a VM? Shows the rule responsible.
Next hop Where will a packet from this VM to this destination be routed?
Effective security rules / Effective routes What is the combined NSG and routing result on a NIC?
Connection troubleshoot / Connection monitor Can source reach destination on a port, and what is the latency and hop path?
Packet capture Capture traffic from a VM for deeper analysis
VNet flow logs Record supported network flows for later analysis; use this for new flow-logging deployments
Topology Show resources and links in a VNet

New NSG flow logs cannot be created after June 30, 2025; existing NSG flow logs retire on September 30, 2027. Plan migration to virtual network flow logs. Flow logs support historical analysis; IP flow verify and Next hop answer a targeted diagnostic question.

Worked example: why can the spoke not reach the hub database?

Scenario. Contoso has vnet-hub (10.10.0.0/16) with a database VM at 10.10.2.10, and vnet-spoke1 (10.20.0.0/16) with an app VM. An administrator created a peering named spoke1-to-hub with the CLI on the spoke only. The peering status reads Initiated, and the app VM cannot reach 10.10.2.10.

Step 1 – Read the status. Initiated means only one side exists. Peering requires a link on each VNet.

Step 2 – Fix. Create hub-to-spoke1 on vnet-hub with Allow virtual network access. The status becomes Connected on both sides.

Step 3 – Verify. Use Next hop from the app VM to 10.10.2.10; the next hop type should be VNet peering. Then use IP flow verify to confirm the database's NSG allows the app subnet on port 1433.

Step 4 – Why other choices are weaker. Adding a VPN gateway is unnecessary because peering already provides private connectivity. Changing the address space does not help because ranges do not overlap. A UDR cannot specify a peering as next hop; peering routes are system routes created automatically.

Worked example: inspecting outbound traffic with a firewall

Scenario. Security requires that ordinary public internet traffic from snet-app passes through an Azure Firewall at 10.10.0.4 in the hub. After creating a route 0.0.0.0/0 through the firewall and associating it, the app VMs lose internet access entirely.

Reasoning. A UDR with a virtual appliance next hop only sends the packets; the firewall must allow them. Check (1) the firewall has an application or network rule permitting the traffic, (2) the firewall subnet can reach the internet itself, (3) for a third-party NVA, IP forwarding is enabled on its NIC and the OS forwards packets. Use Next hop to confirm the packet goes to 10.10.0.4 and the firewall logs to see the denial.

Comparison: connecting networks

Option Latency Needs gateway Transitive Typical use
VNet peering Lowest No No Connect VNets in Azure
VNet-to-VNet VPN Higher, encrypted Yes Possible with routing IPsec link between non-overlapping VNets when gateway-based encryption is required
Site-to-site VPN Internet-dependent Yes Via routing On-premises to Azure
ExpressRoute Private circuit Yes Via routing High bandwidth to on-premises

Pitfalls and exam tips

  • Overlapping address spaces cannot be peered. Check ranges before designing.
  • Peering is not transitive and needs a link on both sides (status Initiated vs Connected).
  • Gateway transit is set on the hub; use remote gateways is set on the spoke.
  • Azure reserves five addresses per subnet. A /29 has three usable.
  • Standard public IPs are static and closed by default. An NSG must allow inbound traffic.
  • Normal route priority is longest prefix, then UDR > BGP > system. Learn the preferred system-route exceptions and the non-overridable service-endpoint routes.
  • A route table associates to subnets, not to VNets or NICs.
  • Third-party NVA forwarding requires both Azure NIC IP forwarding and guest OS forwarding; managed Azure Firewall handles its own forwarding.
  • Use the right tool: IP flow verify for NSG decisions, Next hop for routing, Connection troubleshoot for end-to-end tests.

Exam tip: If the question says "traffic must not leave the Microsoft backbone and must be private between VNets in different regions", the answer is global VNet peering, not a VPN.

Mini case study: Litware multi-region network

Litware has a hub VNet in North Europe (10.0.0.0/16) with a VPN gateway to the head office, two spoke VNets in the same region (10.1.0.0/16 and 10.2.0.0/16) and a spoke in East US (10.3.0.0/16).

Requirements:

  1. Spokes must reach head-office servers through the hub's VPN gateway without their own gateways.
  2. Spoke-to-spoke traffic must go through a firewall in the hub at 10.0.0.4.
  3. A new partner must allow-list a fixed set of Litware outbound internet addresses.
  4. Diagnose an intermittent failure from a spoke VM to a hub service on port 8443.

Solution.

  1. Peer each spoke with the hub. On the hub side enable Allow gateway transit; on the spoke side enable Use remote gateways. The East US spoke uses global peering with the same options.
  2. Add a route table to each spoke subnet with routes to the other spokes' prefixes (and 0.0.0.0/0 if required) using next hop virtual appliance 10.0.0.4, and allow forwarded traffic on the peerings. The firewall needs rules for the permitted flows.
  3. For centralized egress, route ordinary internet traffic from the spokes through the hub firewall and give the partner its configured public SNAT address range. Alternatively, attach NAT Gateway with a suitable public IP prefix to workload subnets within each VNet and supply all those ranges. A NAT gateway attached only to the hub’s subnets does not provide transitive outbound connectivity to peered spokes. Keep public-IP SKU, region and service compatibility aligned.
  4. Run Connection troubleshoot and IP flow verify to port 8443, then check Effective routes for an unexpected UDR; enable Connection monitor to track the intermittent loss over time.

Commentary. Peering alone is not transitive, so spoke-to-spoke traffic needs the firewall route. Gateway transit and remote gateways are a pair; setting only one of them leaves spokes without on-premises access.

Key terms

  • Address space / CIDR: the range of IP addresses assigned to a VNet or subnet.
  • Subnet: segment of a VNet; Azure reserves five addresses in it.
  • VNet peering / global peering: private connection between VNets in the same or different regions.
  • Gateway transit / use remote gateways: hub shares its gateway; spoke consumes it.
  • Public IP (Standard SKU): static, secure-by-default internet address.
  • System route / user-defined route: default or custom entries in routing.
  • Route table: collection of UDRs associated with subnets.
  • Next hop: where a matching packet is sent next.
  • Network Watcher: diagnostic service with IP flow verify, next hop and connection tools.
  • NVA: network virtual appliance, such as a third-party firewall.

Summary checklist

  • I can plan non-overlapping address spaces and subnets and know the five reserved addresses.
  • I can create VNets and subnets and name the special subnets (GatewaySubnet, AzureBastionSubnet, AzureFirewallSubnet).
  • I can configure both peering links, synchronize address-space changes and check gateway-transit prerequisites.
  • I know peering is not transitive and when a hub-and-spoke design with a firewall is needed.
  • I can choose the Standard public IP SKU and understand it is static and closed by default.
  • I can build a subnet route table, recognize route-selection exceptions and configure an explicit outbound method.
  • I can use IP flow verify, Next hop, Effective routes and Connection troubleshoot to find faults.

Continue learning

After checking the address plan and route, secure Azure network access with NSGs and private endpoints. For name-resolution faults, review Azure DNS and load-balancing configuration; use Azure Monitor metrics, logs and alerts to turn recurring connectivity symptoms into monitored signals.

Official sources