CH03-04: Route Tables and Traffic Flow

Goal

The previous section explained which traffic should be allowed. This section explains where traffic goes once it is allowed.

The goal is to understand routing as the design of traffic paths through Azure, shared security controls, and hybrid networks. Routing affects security inspection, latency, troubleshooting, migration, and how much control an organization has over outbound and cross-network traffic.

The Short Version

Security rules and routes answer different questions.

An NSG asks:

Is this traffic allowed?

A route asks:

Where should this traffic go next?

Azure creates default routes so common network behavior works automatically. Route tables let you override or shape those paths when the default behavior is not the design you want.

The durable idea is:

Allowed traffic still needs an intentional path.

System Routes

Azure provides system routes automatically.

System routes help resources inside a VNet communicate with:

Other resources in the same VNet.
Certain Azure platform destinations.
The internet, where allowed.
Peered networks or hybrid networks when those connections exist.

You do not need to memorize every system route at this stage. The important point is that Azure networking is not blank by default. Basic routing exists before you create a custom route table.

That means a route table should not be the first thing you add out of habit. Add custom routing when you need to intentionally change where traffic goes.

Route Tables and User-Defined Routes

A route table is a collection of routes that can be associated with one or more subnets.

A custom route is often called a user-defined route, or UDR. A UDR usually describes:

Destination address prefix: the traffic destination range.
Next hop type: where Azure should send the traffic.
Next hop address, when needed.

For example, a route might say:

Destination: 0.0.0.0/0
Next hop: Azure Firewall private IP
Meaning: Send default outbound traffic to the firewall first

Another route might say:

Destination: 10.80.0.0/16
Next hop: Virtual network gateway
Meaning: Send traffic for this on-premises range through the hybrid gateway

Do not worry about exact portal fields yet. Focus on the architecture meaning: a route table makes a subnet use a specific path for certain traffic.

Why Routing Through Inspection Matters

Many organizations do not want workload subnets to send traffic directly to the internet or to other networks without inspection.

A common pattern is to route traffic through a central firewall or network virtual appliance:

Spoke workload subnet
        |
        | route: 0.0.0.0/0 -> firewall
        v
Hub firewall
        |
        +-- Internet
        +-- On-premises network
        +-- Shared platform services

In this model, the route table does not decide whether the application is allowed to call every destination. It decides that certain traffic should pass through a central control point. The firewall or appliance can then apply inspection, filtering, logging, or other rules.

This can support security visibility and governance, but it also introduces operational responsibilities. The firewall path must be resilient, scaled appropriately, monitored, and understood by the teams who troubleshoot application issues.

Forced Tunneling

Forced tunneling is a design where traffic that might otherwise go directly to the internet is sent through a central path, often a firewall, appliance, or on-premises network.

For example, a company may require all outbound internet traffic from production workloads to pass through central inspection. A route table can send default outbound traffic to a firewall in the hub network.

This can be useful when the organization needs consistent inspection and logging. It can also create trade-offs:

Benefit	Trade-Off
Central visibility of outbound paths.	More dependency on central network services.
Consistent filtering and logging.	Possible latency and cost impact.
Easier policy enforcement.	More complex troubleshooting.
Reduced direct internet exposure.	Risk of broad outage if the inspection path fails.

The point is not that forced tunneling is always good or bad. The point is that routing choices are architecture choices.

Routing in Hub-Spoke Networks

Route tables become especially important in hub-spoke designs.

In a hub-spoke design, a hub VNet may contain shared connectivity, firewalls, gateways, DNS services, or other network platform components. Workload VNets are spokes. Spokes connect to the hub, often through VNet peering.

A spoke subnet may need routes for:

Sending outbound internet traffic to a firewall in the hub.
Reaching on-premises networks through a gateway in the hub.
Reaching shared services through controlled paths.
Avoiding direct paths that bypass inspection.

This is where routing, peering, NSGs, and firewalls work together. Peering may create connectivity. NSGs may allow or deny traffic. Route tables shape the path. Firewalls or appliances may inspect traffic.

If any layer is wrong, the application may fail or bypass the intended control.

Routing and Troubleshooting

Routing problems can be subtle because the symptom often appears somewhere else.

An application may show:

Timeout connecting to a database.
Failure reaching an on-premises API.
Private endpoint resolving but not reachable.
Internet access working in non-production but failing in production.
Traffic reaching a firewall but not returning correctly.

When troubleshooting, ask:

Is the destination name resolving to the expected IP address?
Is the traffic allowed by NSGs and service firewalls?
Which route applies to the subnet?
What is the next hop?
Is return traffic using a compatible path?
Is a firewall or appliance allowing the flow?

That list is not a formal troubleshooting runbook. It is an architecture habit: network problems often involve DNS, security rules, routes, inspection, and service configuration together.

Example: Routing Outbound Traffic Through a Firewall

Imagine a production workload in a spoke VNet.

The security team wants outbound internet traffic to be inspected and logged. The workload team still needs access to package repositories, external APIs, and vendor endpoints.

A simple design might use:

A hub VNet with Azure Firewall.
VNet peering between the hub and spoke.
A route table associated with the workload subnet.
A default route from the workload subnet to the firewall.
Firewall rules that allow only approved outbound destinations.

The route table might express this intent:

Subnet: app-prod
Route: 0.0.0.0/0 -> Azure Firewall private IP

The architecture question is not only, "Can the app reach the internet?" A better question is:

Should the app reach the internet directly, or should outbound traffic pass through a controlled path?

The route table helps enforce the answer.

Common Early Mistakes

Confusing routes with security rules. Routes choose paths. NSGs and firewalls allow, deny, or inspect traffic.
Adding custom routes before understanding system routes. Azure already creates basic routes. Custom routing should have a reason.
Routing everything centrally without considering resilience. If the central path fails, many workloads may be affected.
Creating asymmetric paths. Traffic going out one path and returning another can cause confusing failures.
Forgetting route table scope. Route tables are associated with subnets, so different subnets may behave differently.
Breaking platform or service traffic with broad routes. A broad default route can affect dependencies the team did not consider.

If Someone Asks You

If someone asks, "What is a route table used for in Azure?" a clear answer is:

A route table is used to shape where traffic from a subnet goes. Azure has system routes for default behavior, but user-defined routes let you send traffic through specific next hops such as a firewall, network virtual appliance, gateway, or other controlled path. Route tables matter because allowed traffic still needs the right path for inspection, hybrid connectivity, troubleshooting, and operations.

This answer separates routing from filtering while showing why routing matters.

What You Should Remember

Routing is the path design layer of Azure networking.

The most important idea is this:

Security rules decide whether traffic is allowed; routes decide where traffic is sent.

Strong routing design makes traffic paths intentional, inspectable, and understandable during operations.

Questions to Check Your Understanding

What is the difference between allowing traffic and routing traffic?
Why does Azure have system routes?
When would a user-defined route be useful?
What can go wrong with forced tunneling if it is designed casually?
How do route tables support hub-spoke networking?