You can have the best security appliances, the cleanest IP schema, and a VNet layout that would make a CCIE weep with admiration, but if your routes aren’t right, your traffic’s not getting anywhere.

Whether you’re connecting virtual machines, segmenting workloads, or forcing traffic through inspection hops, you have to understand how Azure route tables work. And more importantly, how to override the defaults when needed.

Let’s ditch autopilot and take control of our network flows.

What Are Azure Route Tables?

Azure route tables (known in the docs as “user-defined route tables” or UDRs) are your way of telling Azure how traffic should flow within your virtual networks.

Out of the box, Azure adds a set of system routes to every subnet—these cover basic scenarios like:

• Traffic within the same VNet
• Internet-bound traffic
• Routing to peered VNets or service endpoints

But when default isn’t enough—say you’re deploying a firewall or need to isolate traffic, you’ll define your own routes using UDRs.

How It Works

Azure performs routing at the subnet level. Each subnet can optionally be associated with a route table. Every outbound packet is evaluated against these rules in order of specificity.

Routing decision order:

1. User-defined routes (UDRs): Always take priority when matched.
2. System routes: Used when no UDR applies.

A single route table can be associated to multiple subnets, but each subnet can only have one route table.

Each route has:

• Address prefix: Destination range (CIDR format)
• Next hop type: Where traffic should be sent
  • Virtual Appliance (e.g., firewall)
  • Virtual Network Gateway
  • Internet
  • None (drop traffic)
  • VNet Peering
• Next hop IP: Required for Virtual Appliance

Sidebar: Can you assign UDRs to a NIC? You might come across older blog posts or docs mentioning that route tables can be associated directly with a network interface (NIC). That was true once—but no longer.

Real-World Impact

Let’s explore basic traffic flow scenarios.

Traffic within a VNet (default)

In a fresh VNet with two subnets:

• VM in Subnet A can talk to VM in Subnet B via default system route 10.0.0.0/16 → Virtual network.

No UDRs are required. Smooth traffic. Like coffee on a Monday morning, no surprises.

VNet peering

Peered VNets auto learn each other’s address ranges.

• If VNet A (10.0.0.0/16) and VNet B (10.1.0.0/16) are peered, Azure adds system routes in both directions.
• Packets treat these destinations transparently, as if part of the same network fabric.

UDRs can override this behaviour if you want to insert a middlebox (like a firewall) or block access.

Force traffic through a firewall (Defined)

You can steer traffic to a firewall by creating a UDR:

• Destination: 0.0.0.0/0 (assumes catching all outbound)
• Next hop: Virtual Appliance
• Next hop IP: Firewall IP in same subnet/VNet

Deploying this in the subnet’s route table forces outbound traffic through the firewall.

Implementation Examples

Example: Isolate a subnet from the internet

Block outbound internet access from a subnet completely.

Route Table:

1
2
3
4

Name: DenyInternet
Route:
- Address prefix: 0.0.0.0/0
  Next hop: None

Azure Portal Steps

1. From the Azure Portal, go to Route Tables > + Create.
2. Name it e.g., DenyInternet, assign it to a region and resource group.
3. Once created, go to Routes > + Add:
   • Address prefix: 0.0.0.0/0
   • Next hop type: None
4. Go to Subnets > Associate > Select VNet and Subnet.

Traffic from that subnet now has nowhere to go.

Bicep Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

resource routeTable 'Microsoft.Network/routeTables@2023-02-01' = {
  name: 'DenyInternet'
  location: resourceGroup().location
  properties: {
    disableBgpRoutePropagation: false
    routes: [
      {
        name: 'blockInternet'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'None'
        }
      }
    ]
  }
}

resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' existing = {
  name: 'MyVNet-01'
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-02-01' = {
  parent: vnet
  name: 'MySubnet-01'
  properties: {
    addressPrefix: '10.0.1.0/24'
    routeTable: {
      id: routeTable.id
    }
  }
}

Diagram: Routing via UDR

In this example, only Subnet A is forced through the firewall, while Subnet B maintains default internet access.

Gotchas & Edge Cases

• UDRs only affect outbound traffic from the subnet. Inbound traffic still relies on other routes and NSGs.
• Service endpoints and private endpoints can interact subtly with UDRs—be mindful of forced tunnelling.
• Don’t drop all routes unintentionally. Setting 0.0.0.0/0 → None blocks all egress. Great for isolation, but painful when you forget an exception for Azure services.
• If using Azure Firewall, be sure to route only egress via it, unless it’s also configured for east-west subnet flows.

Best Practices

• Use least routes needed—more routes mean more complexity.
• Group related subnets with shared egress paths to the same route table.
• When using firewalls or NVAs, make sure to apply health probes and failover logic.
• Build layered security: route + NSG + Azure Firewall = defence in depth.

Learn More

• Microsoft Docs: User-defined routes
• Azure Route Table Concepts
• Azure Network Architecture Guide