Azure Architecture Cloud Security

Designing for Fewer East–West Options (Not Zero)

Containment comes from removing choice, not pretending internal traffic doesn’t exist.

If you’ve ever tried to clean a cluttered bench mid‑shift, you know the trick isn’t perfection it’s removing places where clutter can spread.

East–west traffic is the same.

Once an attacker is inside your Azure estate, the problem isn’t whether lateral movement is possible.
It’s how many plausible directions they can go next.

Designing for zero east–west traffic is fantasy.
Designing for fewer options deliberately is architecture.

The Mental Model

Common assumption:
“Internal connectivity is fine. We’ll trust it unless there’s a reason not to.”

Why it breaks:
This assumes internal networks are stable trust zones. They aren’t.

In real Azure estates, east–west paths accumulate quietly:

  • A new VNet peering to “unblock delivery”
  • A Private Endpoint added for convenience
  • A shared services VNet that slowly becomes transit infrastructure

Each change feels reasonable in isolation.
Collectively, they create unbounded lateral optionality.

The core mistake isn’t trusting internal traffic.
It’s failing to ask: from this point of compromise, where can I go next?

How It Really Works

A more useful mental model is bounded lateral radius.

An Azure network has meaningfully reduced east–west risk when compromise of a single workload results in a small, predictable set of lateral paths not an open‑ended search space.

This is not about neat diagrams or tidy segmentation.
It’s about outcomes from the attacker’s starting point.

If an attacker lands in one subnet:

  • Can they only reach one or two specific services?
  • Or do they quickly discover multiple VNets, shared dependencies, and alternate routes?

East–west risk grows when:

  • Connectivity is cheap and reversible
  • Shared services relay traffic instead of terminating it
  • New paths don’t require justification

Azure makes all of this easy, which is why architecture has to be intentional.

Real‑World Impact

Designing for fewer east–west options changes how you think about:

  • Blast radius
    Networks are designed around where compromise stops, not where workloads live.
  • Shared dependencies
    Anything broadly reachable is inside the blast radius by definition.
  • Change conversations
    Adding connectivity becomes a security‑relevant decision, not plumbing.

This directly answers the practical question:

How would this change something I design, deploy, or operate?

You stop optimising for convenience first and start optimising for predictable containment.

Implementation Examples

Make Lateral Paths Explicit and Rare

A hub‑and‑spoke model only helps if the hub does not quietly become a router.

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

resource hubToSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  name: 'hub-to-app-spoke'
  parent: hubVnet
  properties: {
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: false
    allowGatewayTransit: false
    useRemoteGateways: false
  }
}

This snippet isn’t about syntax.
It’s about default behaviour.

Two flags here are doing real containment work:

  • allowForwardedTraffic: false
  • allowGatewayTransit: false

Removing either one does not usually break functionality.
What it breaks is bounded lateral radius.

With forwarded traffic or gateway transit enabled, a compromised spoke doesn’t just reach the hub it can use the hub to explore elsewhere. The hub becomes a lateral movement amplifier rather than a boundary.

This is how east–west risk is usually introduced:
not by adding new connectivity, but by failing to prevent transit.

Treat Shared Services as a Containment Trade‑Off

A broadly peered “shared services” VNet is not neutral.

Shared services VNets almost always expand lateral radius, often dramatically.

If a service is reachable from many workloads:

  • It sits inside many blast radii
  • It becomes a lateral pivot, not just a dependency

Operational necessity doesn’t change this reality.

If a service must be shared, then the blast radius is knowingly widened and should be treated as a high‑risk architectural decision, not a default pattern.

Private Endpoints: Visibility, Not Immunity

Private Endpoints don’t break the bounded‑radius model.
They expose where it isn’t being enforced.

Each Private Endpoint is an explicit east–west path:

  • It crosses VNets
  • It expands reachable surface area
  • It persists quietly

If you can’t explain why a Private Endpoint exists and which blast radius it belongs to then lateral radius is already unbounded.

Visualising Bounded Lateral Radius

flowchart LR A[App VNet] -->|Explicit| B[API VNet] B -->|Private Endpoint| C[PaaS Service] A -. No direct path .-> C A -. No peering .-> D[Admin VNet]

From App VNet, there is one obvious direction.

That’s the goal:

  • Not isolation
  • Not zero‑trust theatre
  • Predictable movement

Gotchas & Edge Cases

  • Shared services creep
    What starts as DNS or automation often becomes transit.
  • Private Endpoint sprawl
    Endpoint count is less important than endpoint intent.
  • Delivery pressure
    If adding a new east–west path is easy, your architecture is optimised for attackers, not operators.

Best Practices

  • Design networks around points of compromise, not environments
  • Assume shared reachability expands blast radius unless proven otherwise
  • Make east–west connectivity nameable and explainable
  • Prefer terminating connections over relaying ones

A simple test:

If you can’t name every lateral path out of a workload without querying tooling, optionality hasn’t been reduced, it’s just been obscured.

🍺
Brewed Insight: You don’t control lateral movement by drawing boundaries.
You control it by deciding, deliberately, how much choice you’re willing to give an attacker.

Learn More