Most Azure estates don’t feel flat.

They have hubs, spokes, subnets, and diagrams that suggest intent and order. On paper, things look segmented. Contained. Reasonable.

Yet once something unwanted lands inside, movement often feels frictionless like walking through an open-plan office where every door politely steps aside.

That isn’t because someone forgot a firewall rule.
It’s because Azure networking is doing exactly what it was designed to do.

The Mental Model

Common assumption:
Internal Azure networks are segmented unless you explicitly connect them.

Why it breaks:
Azure optimises for reachability, symmetry, and operational correctness. Once you create connectivity, Azure assumes you meant it, and it works hard to preserve stable, symmetric paths between everything involved.

East–west movement isn’t an attacker trick.
It’s an architectural outcome.

How It Really Works

Let’s talk about behaviour, not marketing diagrams.

Symmetric hub routing is the real enabler

Azure VNet peering itself is non‑transitive. On its own, it doesn’t flatten anything.

Transitivity appears when architects (often correctly, at the time):

• Centralise routing through a hub
• Introduce Azure Firewall or NVAs
• Apply default UDRs (0.0.0.0/0) from spokes to the hub
• Expect symmetric paths for reliability and troubleshooting

At that point, the hub stops being a boundary and becomes a routing fabric.

Once symmetry is restored, spoke‑to‑spoke reachability isn’t an accident it’s the inevitable result of a design optimised for correctness.

Azure preserves paths aggressively

Azure system routes and platform behaviour:

• Prefer the most specific prefix
• Preserve return paths when they exist
• Avoid blackholing traffic unless explicitly instructed

This is excellent for application uptime.
It’s also excellent for internal exploration.

If a packet can get there and come back, Azure will try very hard to keep that path stable.

A Hard Admission

I’ve implemented symmetric hub routing myself more than once.

It solved real problems:

• Predictable traffic flows
• Fewer asymmetric failures
• Easier troubleshooting at 2am

What I underestimated wasn’t the firewall or the rules.
It was how completely Azure erased any remaining sense of internal boundary once symmetry was restored.

The design was correct.
The blast radius was just larger than I intended.

Real‑World Impact

This isn’t theoretical. It changes outcomes.

Design
Symmetric hub routing collapses routing domains. Once in a spoke, the rest of the estate becomes discoverable by default.

Reliability
The same paths that propagate traffic propagate failures security incidents and outages share infrastructure.

Security
Lateral movement becomes a question of which routes exist, not which controls failed.

Cost
Broad east–west flows quietly consume firewall throughput and bandwidth even during normal operation.

Practical anchor:
This should change when and how freely, you restore routing symmetry in your designs.

Implementation Example

The “standard” hub‑and‑spoke pattern

No direct peering between spokes.
Yet full spoke‑to‑spoke reachability exists via the hub.

The UDR that makes it inevitable

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

resource spokeRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
  name: 'rt-spoke-default'
  location: resourceGroup().location
  properties: {
    routes: [
      {
        name: 'default-to-hub'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.0.4' // Hub firewall or NVA
        }
      }
    ]
  }
}

This single route:

• Restores symmetry
• Makes the hub a transit router
• Removes natural routing boundaries between spokes

Operationally clean.
Architecturally expansive.

Gotchas & Edge Cases

• Peering flags don’t save you
  AllowForwardedTraffic = false doesn’t help once routing is reintroduced elsewhere.

• Gateway transit magnifies the effect
  Shared gateways flatten routing domains even further.

• Private Endpoints don’t change this
  They reduce exposure, not reachability. Routes still define movement.

Guidance for Future Designs

This isn’t about banning hubs or symmetry. It’s about intent.

Treat routing symmetry as privileged

In Azure, symmetric routing is not neutral.
It is a privileged capability that should be granted deliberately and narrowly.

If symmetry isn’t required, let paths fail closed.

Design routing domains, not just VNets

VNets and spokes are implementation details.
Routing domains define blast radius.

If two workloads don’t need to talk both ways, they don’t belong in the same routing domain regardless of how tidy the diagram looks.

Make hubs earn their reach

Centralised hubs trade convenience for scale including the scale of failure.

Every east–west path enabled by a hub should be justified.
“Operational simplicity” alone is not a sufficient reason.

Defer symmetry, don’t default to it

Today, I treat symmetric hub routing as an optimisation to be earned late not a baseline assumed early.

That single shift changes how networks age under pressure.

Learn More

• Azure virtual network traffic routing
• Virtual network peering
• Hub-spoke network topology in Azure