East–West Traffic Is Where Cloud Incidents Actually Spread

Thu, 23 Apr 2026 00:00:00 +1100

Most cloud incidents don’t escalate because someone was clever at breaking in.

They escalate because the environment was already helpful once they arrived.

If you’ve ever sat in a post‑incident review thinking, “I didn’t realise those systems could talk to each other”, you’ve already seen where the real damage happens east–west traffic.

The Mental Model

Common assumption:
“Internal traffic is safer. The perimeter is where risk lives.”

Why it breaks:
Under an Assume Breach mindset, internal reachability is the primary blast‑radius multiplier. East–west paths are rarely designed to contain failure. They’re designed to keep systems working as requirements evolve.

That makes them durable, invisible, and dangerous under compromise.

How It Really Works

In Azure estates, east–west traffic isn’t centrally planned. It emerges.

It emerges from:

Incremental connectivity added to unblock delivery
Runtime dependencies discovered after go‑live
Legacy behaviour preserved to avoid outages
Organisational pressure to keep things moving

Each individual decision is reasonable. Collectively, they form traversal paths no one set out to design, but which attackers can rely on.

The platform doesn’t distinguish between “architectural intent” and “operational necessity”. Routing and reachability follow what exists now, not what was drawn.

Real‑World Impact

Here’s a common post‑incident pattern.

A business application is described and diagrammed, as a classic three‑tier design: web, app, data. During a containment exercise, outbound connectivity from the app tier back to the web tier is disabled as a scream test.

Production breaks.

Investigation shows the app tier is:

Writing files back to the web tier for user access, and/or
Responding directly to users under certain workflows

None of this was malicious. All of it was required.

The bidirectional connectivity wasn’t an accident it was an operational dependency that formed after the original design. Over time, that dependency became untouchable.

From a breach perspective, compromise of the app tier now inherently includes a path back to user‑facing surfaces without exploiting anything new.

How would this change something I design, deploy, or operate?
You stop trusting tier labels and start validating directional behaviour. “Internal” no longer means “contained”.

Structural Reasons East–West Paths Persist

These paths survive because they acquire protection through necessity:

They’re justified post‑hoc as “how the app works”
They’re undocumented because they evolved organically
They can’t be removed without immediate impact
They cross boundaries that were never designed as security controls

The phrase that shows up in reviews is telling: “unexpected but required”.

Once something is required, it stops being questioned and becomes architectural fact.

Implementation Examples

Architecture View: How Runtime Behaviour Overrides Design

flowchart LR U[User] --> W[Web Tier] W --> A[App Tier] A --> D[Data Tier] A -->|Operational Dependency| W style A fill:#f5f5f5 style W fill:#f5f5f5

The diagram says “three tiers”.
The runtime says “bidirectional”.

Attackers only need to follow what already works.

Gotchas & Edge Cases

“Same app” is not a containment boundary
Lateral movement doesn’t care about application ownership.
Scream tests reveal truth late
By the time you can’t disable a path, it’s already structural.
Directionality is rarely validated
Engineers confirm that traffic flows, not who initiates it.
Removal risk entrenches exposure
The harder a path is to remove, the more dangerous it becomes under breach.

Best Practices

Without touching specific controls:

Treat east–west connectivity as intentional architecture, not background plumbing
Validate direction of initiation, not just reachability
Assume every “temporary” dependency will outlive its justification
Design internal paths so they can fail without collapsing user‑facing surfaces

Containment is a design outcome, not a firewall feature.

🍺

Brewed Insight: In cloud environments, lateral movement usually isn’t enabled by attackers, it’s enabled by applications quietly evolving past their original design.

Azure Network on Brewed in the Cloud by Chris Hailes