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
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.