We just completed the phased migration of our entire corporate footprint to a major SASE platform. As part of the justification process, I built a detailed flow map of our pre-migration traffic over a two-week baseline period. We repeated the analysis last week, post-full cutover. The headline for the board was the improved security posture and reduced VPN usage. The real story, for us infra grunts, is in the east-west traffic carnage.
The pre-SASE map was a predictable hairball. Every branch office backhauled everything to the nearest data center. Internal applications hosted in AWS us-east-1 were accessed by users in, say, our London office by routing: London User -> MPLS -> London DC -> DC Interconnect -> us-east-1 VPC. The traffic map was dominated by these long, inefficient spokes centered on our data centers. More critically, our "zero trust" was mostly a PowerPoint slide. Once on the corporate network, lateral movement was trivial.
Post-SASE, the map is radically simplified. The most striking visual change is the near-elimination of "spoke-to-spoke" traversals through our cores. Now, it's all: Endpoint -> PoP. The SASE fabric handles the back-end routing. Our actual observed east-west traffic—defined as traffic between two internal corporate entities—dropped by roughly 70% in volume. Why?
* **Direct-to-Cloud Breakout:** The SASE PoP in London sees a request for an internal app in AWS us-east-1. It establishes its own optimized tunnel to that VPC. The traffic never touches our London DC. That entire leg of east-west traffic between data centers is gone.
* **Service Chaining Elimination:** We had a clunky service chain for outbound traffic (proxy -> firewall -> IDS) in each DC. All that traffic is now processed in the SASE cloud, removing another massive chunk of internal network load.
* **Implicit Default-Deny:** The new security policies are identity and context-based. The default posture is deny. The vast amount of background noise and "friendly" scanning traffic between internal subnets just vanished because the policies now explicitly permit only what's needed.
Here's a sanitized snippet of the simple Python script we used with our flow logs (NetFlow pre, SASE API post) to categorize traffic. The core logic is just counting bytes between source/destination entity pairs.
```python
# Pre-process: Enrich raw flow logs with entity tags (e.g., 'aws-us-east-1-app', 'london-office', 'corp-dc-1')
def categorize_flow(src_entity, dst_entity, bytes):
if src_entity == 'external' or dst_entity == 'external':
return 'north-south'
# All traffic between internal entities is east-west
return 'east-west'
# Post-analysis comparison
print(f"Pre-migration East-West: {pre_east_west_bytes} bytes ({pre_ew_percentage:.1f}% of total)")
print(f"Post-migration East-West: {post_east_west_bytes} bytes ({post_ew_percentage:.1f}% of total)")
print(f"Reduction: {((pre_east_west_bytes - post_east_west_bytes) / pre_east_west_bytes * 100):.1f}%")
```
The hard truth? Achieving this wasn't free. The migration pain was substantial. Ripping out legacy MPLS dependencies, re-writing firewall rules from IP-based to identity-based, and dealing with app performance quirks during the transition was a 12-month slog. The cost model also shifts from CapEx to OpEx in a big way.
But the architectural simplification is undeniable. The network is now fundamentally different: it's a collection of endpoints connecting to a cloud fabric, not a traditional "place" we own and manage. The security team is happier, but my team now spends more time tuning the SASE policy than managing routers. Trade-offs.
Has anyone else done a similar before/after flow analysis? I'm particularly interested if you saw a corresponding increase in "east-west" traffic within your cloud VPCs as the SASE gateways become the new central hubs.
---
Been there, migrated that