This chapter covers Azure Route Tables and User-Defined Routes (UDRs), a critical networking feature that controls traffic flow within Azure virtual networks. Understanding UDRs is essential for the AZ-900 exam, as it falls under Objective 2.3: Describe Azure networking services. This objective area carries approximately 15-20% of the exam weight. By the end of this chapter, you will be able to explain when and why to use custom routing, how to configure route tables, and how they differ from other Azure networking components.
Jump to a section
Imagine a large corporate campus with multiple buildings. The internal roads have default paths that everyone follows (system routes). But one day, the CEO decides that all delivery trucks must go through a security checkpoint before reaching the warehouse (a network virtual appliance). Without a custom traffic director, trucks would take the default road directly to the warehouse, bypassing security. You install a traffic director (route table) at each intersection, with signs (user-defined routes) that override the default directions. Each sign has a destination (e.g., 'Warehouse Building C') and a next hop (e.g., 'Security Gate 2'). The traffic director is not a physical device; it's a set of rules stored in a central office that each intersection checks when a truck arrives. If a sign matches the truck's destination, the truck follows the custom path; otherwise, it follows the default. This is exactly how Azure Route Tables work: they are logical containers of UDRs that override Azure's default system routes for virtual network traffic, directing packets to specific next-hop types like virtual appliances or VPN gateways.
What Are Azure Route Tables and UDRs?
Azure automatically creates a system route table for each subnet in a virtual network (VNet). These system routes handle traffic within the VNet, between VNets (via peering), to on-premises networks (via VPN or ExpressRoute), and to the internet. However, many scenarios require custom routing—for example, forcing all outbound traffic through a firewall or routing traffic between peered VNets through a network virtual appliance (NVA). This is where User-Defined Routes (UDRs) come in. A UDR is a custom route that you add to a route table, which overrides the default system routes for specific destinations.
How It Works: Step-by-Step Mechanism
Packet arrives at a subnet's virtual router. Each subnet in Azure has a logical router that examines the destination IP of every packet leaving the subnet.
Route table lookup. The router checks the subnet's associated route table. The route table contains a list of routes, each with an address prefix (destination) and a next hop type.
Longest prefix match. The router selects the route with the most specific address prefix that matches the destination. For example, a route for 10.0.1.0/24 is more specific than 10.0.0.0/16.
Next hop determination. The matched route specifies a next hop type, such as Virtual appliance, VPN gateway, or Internet.
Packet forwarding. The packet is forwarded to the next hop IP address or interface as specified.
Key Components
- Route Table: A logical container that holds one or more UDRs. It is associated with zero or more subnets within the same region. A subnet can have only one route table, but a route table can be associated with multiple subnets. - User-Defined Route (UDR): A single route entry with an address prefix (CIDR notation) and a next hop type/address. Common next hop types: - Virtual appliance: An IP address of a VM or load balancer that performs network functions (e.g., firewall). - Virtual network gateway: Forces traffic to an on-premises network via VPN or ExpressRoute. - VNet peering: Used to override peering routes (rare). - Internet: Forces traffic to the internet (default for 0.0.0.0/0). - None: Drops traffic matching the prefix.
System Routes vs. UDRs
Azure's system routes are automatically created and cannot be deleted or modified. They include:
Routes within the VNet (e.g., 10.0.0.0/16)
Routes to peered VNets (e.g., 10.1.0.0/16)
Routes to on-premises (e.g., 192.168.0.0/16 via VPN)
Default route to internet (0.0.0.0/0)
UDRs take precedence over system routes for the same prefix. If you create a UDR for 0.0.0.0/0 with next hop Virtual appliance, all internet-bound traffic from that subnet will go to the appliance instead of directly to the internet.
Business Scenarios
Forced tunneling: An organization wants all internet traffic from Azure VMs to go through an on-premises firewall for inspection. They create a UDR for 0.0.0.0/0 with next hop VPN gateway, and configure the on-premises VPN device to route traffic to the internet.
Hub-and-spoke topology: A central hub VNet hosts shared services like a firewall. Spoke VNets peer to the hub. To ensure traffic between spokes goes through the firewall, you add UDRs in each spoke subnet pointing to the firewall's IP in the hub.
Isolating management traffic: For compliance, management traffic (e.g., RDP, SSH) must go through a jump box. A UDR directs all traffic to the jump box's subnet.
Azure Portal and CLI Touchpoints
In the Azure portal, navigate to "Route tables" under "Networking" to create a route table. You can add routes and associate the table with subnets. Using Azure CLI:
az network route-table create --name MyRouteTable --resource-group MyRG --location eastus
az network route-table route create --route-table-name MyRouteTable -g MyRG --name MyUDR --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.1.4
az network vnet subnet update -g MyRG --vnet-name MyVNet --name MySubnet --route-table MyRouteTableLimits and Pricing
Route tables and UDRs themselves are free, but you pay for data processing by the next hop (e.g., VM, VPN gateway). There are limits: up to 400 UDRs per route table, and up to 400 route tables per subscription (adjustable via support). Each route table can be associated with up to 1000 subnets.
Comparison to On-Premises
In on-premises networks, routing is typically handled by physical routers using dynamic routing protocols (e.g., OSPF, BGP). UDRs are analogous to static routes on a router. Azure does not support dynamic routing within a VNet; UDRs are static. However, when using VPN or ExpressRoute, you can propagate BGP routes from on-premises, which appear as system routes in Azure.
Create a Route Table
In the Azure portal, go to 'Create a resource' > 'Networking' > 'Route table'. Provide a name, subscription, resource group, and location (must match the region of the VNet). Optionally, enable 'Propagate gateway routes' if you want to include routes from on-premises via BGP. This creates an empty container for routes.
Add User-Defined Routes
In the route table, go to 'Routes' and click 'Add'. Specify a route name, address prefix (CIDR), and next hop type. For next hop type 'Virtual appliance', provide the private IP address of the appliance (e.g., a firewall VM). For 'Virtual network gateway', no IP is needed. Each route must have a unique prefix within the table.
Associate Route Table with Subnet
Navigate to the subnet you want to customize (under your VNet). In the subnet's 'Route table' dropdown, select the route table you created. You can also associate from the route table's 'Subnets' blade. A subnet can only have one route table, but a route table can be associated with multiple subnets. Disassociation is immediate.
Verify Effective Routes
After association, test traffic flow. In the portal, go to a VM in the subnet, click 'Networking' > 'Effective routes'. This shows the combined system and user-defined routes that apply to that VM. You can also use Azure CLI: `az network nic show-effective-route-table --name MyNic -g MyRG`. This helps troubleshoot if routes are not working as expected.
Test and Monitor
Use tools like `tracert` or `pathping` from a VM to verify the path. For forced tunneling, check if internet traffic goes through the VPN gateway. Monitor route table changes with Azure Monitor activity logs. If traffic is dropped unexpectedly, check for a route with next hop 'None' or a misconfigured appliance.
Scenario 1: Forced Tunneling for Compliance A financial services company must log all outbound internet traffic from Azure for audit compliance. They deploy a firewall VM (NVA) in a hub VNet. In each spoke VNet's subnets, they create a route table with a UDR for 0.0.0.0/0 pointing to the firewall's private IP. All internet-bound traffic from spoke VMs is forced through the firewall, where it is inspected and logged. The team configures the firewall to forward allowed traffic to the internet. This setup ensures no VM can bypass the firewall. Common misconfiguration: forgetting to add a UDR for the firewall's own subnet, causing asymmetric routing (traffic goes out through firewall but returns directly, dropping packets).
Scenario 2: Hub-and-Spoke with Shared Services An e-commerce platform uses a hub VNet for shared services like Active Directory and a web application firewall (WAF). Spoke VNets (production, staging, development) peer to the hub. To ensure all traffic between spokes goes through the WAF, they add UDRs in each spoke subnet for the other spoke's address prefixes, with next hop pointing to the WAF's IP in the hub. Without these UDRs, traffic would flow directly over the peering connection, bypassing the WAF. The team must also ensure the WAF's subnet has a route to return traffic to the spokes via the hub. This requires careful IP planning and possibly UDRs on the hub subnet as well.
Scenario 3: Isolating Management Traffic A healthcare organization requires that all RDP and SSH traffic to production VMs must originate from a jump box subnet. They create a route table for the production subnet with a UDR for 0.0.0.0/0 pointing to the jump box's private IP (which acts as a NAT). This forces all outbound traffic from production VMs (including management responses) through the jump box. The jump box then routes responses back to the admin's client. This ensures no direct inbound RDP/SSH from the internet. Pitfall: if the jump box is not properly configured to forward traffic, responses never reach the admin, breaking connectivity.
Exam Objective: AZ-900 2.3 Describe Azure networking services Specifically, you need to understand the purpose of route tables and UDRs, when to use them, and how they differ from other networking components like Azure Firewall or Network Security Groups (NSGs). The exam will not ask you to write a route, but you must identify scenarios where UDRs are required.
Common Wrong Answers and Why Candidates Choose Them 1. "UDRs are used to filter traffic." Candidates confuse UDRs with NSGs. NSGs filter traffic (allow/deny), while UDRs route traffic. UDRs do not inspect or filter; they only direct packets. 2. "UDRs can be applied to a VNet." UDRs are associated with subnets, not VNets. A route table is attached to a subnet. Applying to a VNet would affect all subnets, but Azure does not allow that. 3. "UDRs override all system routes." UDRs only override system routes for the same prefix. They cannot override routes within the same VNet (e.g., traffic between subnets in the same VNet still uses system routes unless you add a more specific UDR). Also, routes learned via BGP from on-premises can be overridden only if you disable route propagation. 4. "You need a route table for every subnet." You only need a route table if you want to override default routing. Many subnets work fine with system routes alone.
Specific Exam Terms and Values - Next hop types: Virtual appliance, Virtual network gateway, VNet peering, Internet, None. - Address prefix must be in CIDR notation (e.g., 10.0.0.0/16). - Route tables are regional resources (tied to an Azure region). - Maximum 400 UDRs per route table. - A subnet can have only one route table.
Edge Cases and Tricky Distinctions - UDRs and Azure Firewall: Azure Firewall is a managed service that automatically creates UDRs for forced tunneling when configured. You don't need to manually create UDRs for Azure Firewall's default route. - UDRs and Service Endpoints: Service endpoints add routes automatically; UDRs can override them if needed. - UDRs and Private Endpoints: Private endpoints use private IPs; UDRs can affect traffic to them if you add a route for the private endpoint's subnet. - Asymmetric routing: If you force traffic through an NVA but the NVA's subnet doesn't have a route back to the source, return traffic takes a different path, causing connection drops. Always ensure symmetric routing.
Memory Trick "UDR = User Defines Route" – think of it as a custom signpost. If you want traffic to take a detour, you add a sign (UDR) at the subnet's intersection. Only subnets with custom signs need a route table. The default signs (system routes) work for most cases.
UDRs are custom routes that override Azure's default system routes for a subnet.
Route tables are logical containers for UDRs and are associated with subnets, not VNets.
Common next hop types: Virtual appliance (IP), Virtual network gateway, Internet, None.
UDRs follow longest prefix match; more specific prefixes take precedence.
Route tables are free; you pay only for data processing by the next hop resource.
Maximum 400 UDRs per route table; up to 400 route tables per subscription.
UDRs are essential for forced tunneling, hub-and-spoke topologies, and traffic inspection scenarios.
These come up on the exam all the time. Here's how to tell them apart.
Azure Route Table / UDR
Controls traffic routing (path) based on destination IP.
Layer 3 (network layer) decision.
No state; does not track connections.
Applied to subnets or network interfaces (effective on subnet).
Does not filter; only directs packets.
Network Security Group (NSG)
Controls traffic filtering (allow/deny) based on source/destination IP, port, protocol.
Layer 3/4 (network and transport layer) decision.
Stateful; tracks connections for return traffic.
Applied to subnets or network interfaces.
Does not route; only permits or blocks.
Mistake
UDRs can filter traffic like a firewall.
Correct
UDRs only route traffic; they do not inspect or filter packets. Filtering is done by Network Security Groups (NSGs) or Azure Firewall.
Mistake
A route table can be associated with a VNet directly.
Correct
Route tables are associated with subnets, not VNets. To affect all subnets, you must associate the route table with each subnet individually.
Mistake
UDRs always override system routes.
Correct
UDRs override system routes only for the same address prefix. System routes within the same VNet (e.g., inter-subnet) still apply unless a more specific UDR exists.
Mistake
You must create a route table for every subnet.
Correct
Route tables are optional. Subnets without an associated route table use default system routes.
Mistake
UDRs can be applied to a virtual machine directly.
Correct
UDRs are applied to subnets, not individual VMs. All VMs in a subnet inherit the subnet's route table.
Yes, by adding a UDR for 0.0.0.0/0 with next hop type 'None'. This drops all outbound internet traffic. However, this does not prevent inbound traffic; for that, use an NSG. Also, note that Azure services like Azure Backup or Windows Update may require internet access; blocking it could break those services. Exam tip: 'None' next hop is often tested as a way to disable internet connectivity for a subnet.
System routes are automatically created by Azure for default connectivity within a VNet, between peered VNets, to on-premises, and to the internet. They cannot be modified or deleted. UDRs are custom routes you add to a route table to override system routes for specific destinations. UDRs take precedence over system routes for the same prefix. Exam tip: Remember that system routes exist by default; UDRs are optional overrides.
Yes, a route table can be associated with up to 1000 subnets in the same region. However, each subnet can only have one route table. This allows you to reuse the same custom routing rules across multiple subnets, simplifying management. Exam tip: This is a common scenario for hub-and-spoke designs.
The old route table is disassociated and the new one takes effect immediately. There is no transitional period. Traffic may be briefly affected if routes change. Exam tip: This is a straightforward operation; no downtime is expected, but existing connections may drop if routing changes are asymmetric.
No, traffic within the same subnet is always local and does not go through the virtual router. UDRs only apply to traffic leaving the subnet. Exam tip: This is a common trick question; UDRs do not affect intra-subnet communication.
Yes, Azure Firewall automatically creates a system route for forced tunneling when deployed. However, you can also manually create UDRs to force traffic to Azure Firewall. In fact, when you enable forced tunneling on Azure Firewall, it creates a default route (0.0.0.0/0) to the firewall's private IP. Exam tip: Azure Firewall simplifies UDR management; you don't always need to create UDRs manually.
Check the effective routes on a VM's network interface to see which routes are applied. Use `az network nic show-effective-route-table` or the portal. Verify that the next hop appliance is running and has IP forwarding enabled. Also, ensure symmetric routing: the return path must have a route back. Common issues: missing route on the appliance's subnet, or UDR not associated with the correct subnet.
You've just covered Azure Route Tables and UDRs — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?