# East-west traffic analysis: Why internal network visibility matters

By: Shynu

10-11 minutes

Last updated: August 28, 2026

Ask a network team where their flow exporters are and the answer is usually the WAN edge and the internet gateway. Ask where an attacker spends most of their time and the answer is everywhere else.

The gap between those two answers is the east-west problem. Perimeter instrumentation was designed for a network where the interesting traffic crossed a boundary. In a virtualized data center, a collapsed campus core, or a Kubernetes cluster, much of the traffic never touches a device anyone thought to instrument.

## In this guide

- Why the traffic ratio shifted and what perimeter-only monitoring misses as a result.
- Five specific places east-west blind spots form, including inside a single hypervisor host.
- Instrumentation options with their honest trade-offs, the internal patterns worth alerting on, and what stays invisible afterward.

## North-south, east-west, and where the traffic actually is

North-south traffic crosses the boundary between your network and something outside it: users reaching the internet, customers reaching your applications, branch offices reaching the data center.

East-west traffic moves between systems inside your network from application server to database, workstation to file share, microservice to microservice, replication between storage nodes.

The ratio shifted because architecture changed, and no single event caused it. A monolithic application on one server produced one north-south conversation per user request. The same application decomposed into a dozen services produces one north-south request and a substantial number of internal calls behind it. Virtualization concentrated many of those calls inside single physical hosts. Container orchestration pushed them further down, into virtual networking that never reaches a physical switch port.

The practical figure varies enormously by environment, so treat published ratios with caution. What holds across environments is directional: internal traffic volume in a modern data center substantially exceeds perimeter traffic, and the gap widens with every service decomposition.

## Where do east-west blind spots form?

East-west blind spots form wherever two systems exchange traffic over a path that no flow-exporting device observes. Five architectural locations account for most of them.

**1. Intra-host virtual switching:** Two VMs on the same hypervisor communicate through the virtual switch. The packets never reach a physical NIC. Unless the virtual switch itself exports flow, that conversation is invisible to every physical device in the rack.

**2. Container and pod networking:** Pod-to-pod traffic inside a node travels through the container network interface. Service mesh sidecars add another layer. Physical network telemetry observes traffic at the node boundary and has no view of the conversation inside it.

**3. Access-layer switching:** Two workstations on the same VLAN and the same access switch communicate through that switch without traversing the core or a router. If the same VLAN spans two switches, the conversation crosses an uplink that may already be instrumented, which is why the exporter placement question has to be answered per switch rather than per VLAN. The intra-switch path is exactly what lateral movement uses, and access switches are the devices least likely to be exporting flow.

**4. Cloud VPC internal traffic:** Traffic between instances in the same subnet stays inside the provider's fabric. Provider flow logs (AWS VPC Flow Logs, Azure VNet flow logs, Google Cloud VPC Flow Logs) exist for this reason, and they need to be collected deliberately rather than assumed.

**5. Storage and backup networks:** Frequently on dedicated fabrics with their own switches, often instrumented by nobody, and carrying the largest transfers in the estate. Ransomware operators go looking for exactly these paths.

## What you lose without east-west visibility

Lateral movement, by definition, is east-west. An attacker who gains a foothold on a workstation and hops toward a domain controller may never generate an anomalous north-south flow until the moment of exfiltration, and by then the operation is nearly complete.

The window is narrow. [CrowdStrike's 2026 Global Threat Report](https://www.crowdstrike.com/global-threat-report/) put the average eCrime breakout time, meaning the interval between compromising the first host and pivoting to a second, at 29 minutes for 2025, with the fastest observed pivot at 27 seconds. Pivots of that kind are east-west flows, and a perimeter firewall sees none of them. The stage-by-stage view in [ransomware detection through network traffic monitoring](https://www.manageengine.com/products/netflow/ransomware-detection-network-traffic-monitoring.html) shows how much of a ransomware kill chain is internal.

Beyond security, three operational problems live east-west.

**Security:** Lateral movement, internal reconnaissance, and data staging before exfiltration.

Performance. A backup job saturating a data center link degrades application performance in ways perimeter monitoring cannot explain. Application dependency mapping has the same requirement: you cannot document which services depend on which without observing the calls between them, which turns every migration into an archaeology project.

**Architecture:** A firewall rule stating that two segments must not communicate is a claim. East-west flow data provides direct evidence of whether those systems are actually communicating across the boundary the design defines.

## How to instrument internal traffic

East-west instrumentation is the set of methods for generating traffic records on internal paths that do not cross a perimeter device. No single method covers every environment, so most estates need a combination.

| Method | Covers | Relative cost | Trade-off |
|---|---|---|---|
| Flow export from access and distribution switches | Physical east-west across VLANs and within campus | Low, where the feature already exists | Older or lower-tier switches may lack flow export or handle it in the software path |
| Virtual switch flow export | VM-to-VM inside a hypervisor | Low to medium | Requires distributed switch capability, and availability varies by platform and licensing tier |
| Cloud provider flow logs | Instance-to-instance in VPCs and VNets | Medium, and volume-driven | Provider log charges; field sets differ from on-premises flow |
| SPAN or TAP into a probe | Any segment, with full packet fidelity | High | Cost and cabling per segment; does not scale estate-wide |
| Host-based agents | Per-host conversations regardless of network path | Medium to high | Deployment and lifecycle burden across every workload |
| Service mesh telemetry | Service-to-service in Kubernetes | Low, where a mesh is already adopted | Covers meshed traffic only, and complements network flow rather than replacing it |

**Choosing between them:** Physical east-west across campus and data center goes to switch flow export. VM-to-VM inside a host goes to virtual switch export. Instance-to-instance in cloud goes to provider flow logs. Packet-level fidelity on a specific segment goes to SPAN or TAP. Workloads that move between environments go to host agents.

The practical approach is coverage by risk. Instrument the segments containing crown jewel systems first, meaning domain controllers, database tiers, backup infrastructure, and administrative networks. Full coverage of every access switch is a multi-year goal in most estates. Coverage of the paths that matter is achievable within a single quarter, and it delivers most of the detection value.

Before committing, check what your existing hardware already supports. Many switches deployed in the last several years support flow export and simply have it disabled.

**On CPU impact:** There is no universal figure, and the shape is consistent. Where flow export is handled in hardware on modern switching silicon, the overhead is negligible. Where it falls to the software path on older or lower-tier platforms, it is measurable and occasionally significant on high-throughput interfaces. Test on the oldest platform in the fleet before any fleet-wide rollout, and enable sampling where the software path is the only option, accounting for it as covered in [choosing a network traffic analysis tool](https://www.manageengine.com/products/netflow/how-to-choose-network-traffic-analysis-tool.html).

## Internal patterns worth alerting on

East-west alerting fails when it is imported from perimeter thinking. Internal traffic is dense, chatty, and full of legitimate machine-to-machine noise. These five rules survive contact with production.

| Pattern | What it may indicate | ATT&CK reference | First thing to check |
|---|---|---|---|
| Fan-out from a single source | Internal reconnaissance | TA0007 Discovery | Source host role and the destination set |
| Workstation-to-workstation on admin ports | Lateral movement | T1021.001, T1021.002, T1021.006 | Whether either endpoint is a management host |
| New peer relationship | Newly established or unauthorized communication | Context-dependent | The application and process behind it |
| Forbidden cross-segment flow | Segmentation failure or bypass | Context-dependent | Policy state and change history |
| Volume anomaly on an internal pair | Data staging before exfiltration | T1074.001 Local Data Staging | The host pair and the application |

**Fan-out from a single source:** One host initiating connections to an unusual number of distinct internal addresses inside a short window. The right threshold is environment-specific and has to be calibrated against observed behavior. As an illustrative starting point, some teams begin by investigating hosts contacting more than 30 distinct internal destinations in 10 minutes, with vulnerability scanners, patch servers, monitoring systems, backup agents, and domain controllers excluded by IP group. Those last two will fire on day one if you leave them in, since both fan out to large host sets by design.

**Workstation-to-workstation on administrative ports:** SMB (445), RDP (3389), and WinRM (5985 for HTTP, 5986 for HTTPS) between two user endpoints. Server-to-server and workstation-to-server traffic on these ports is routine. Peer-to-peer on them rarely is.

**New peer relationships:** A pair of hosts that has never communicated in your retention window suddenly holding a sustained conversation. This detection depends entirely on the quality of your history, which is why baselining comes first.

**Cross-segment flows that policy forbids:** Any conversation crossing a boundary your segmentation design says is closed. These are either misconfigurations or bypasses, and both are worth knowing about.

**Volume anomalies on internal pairs:** Transfers between a file server and a single internal host far exceeding that pair's historical volume, which is the data staging pattern that precedes exfiltration.

Every one of these depends on knowing what normal looks like for each device role. Build that first, using the method in how to baseline network traffic.

## What east-west flow data will not show you

Instrumenting internal traffic closes large gaps and leaves four open. Knowing where they sit prevents the assumption that full instrumentation means full visibility.

**Encrypted internal traffic:** Internal TLS, SMB encryption, and service mesh mTLS mean flow records establish that a conversation happened and carry no information about its contents. Internal encryption is increasing, so this gap widens over time rather than closing.

**Same-host container traffic:** Two containers on a single node behind the same container network interface may produce no separately identifiable record even where node-level instrumentation exists. Service mesh telemetry covers meshed traffic and leaves unmeshed traffic on the same node uncovered.

**What sampling drops:** Where CPU constraints force sampled export on access-layer devices, the low-and-slow patterns that matter most east-west are exactly the ones sampling is likely to miss. A scan composed of small flows can disappear entirely at aggressive sampling rates.

**Anything host-internal:** Process execution, credential access from memory, and local file encryption generate no flows at any level of network instrumentation. That gap belongs to endpoint detection and response.

## East-west visibility and zero trust

Zero trust architectures, as described in NIST SP 800-207, assume the internal network is hostile and require verification at every access decision. That model creates two demands on east-west telemetry.

First, is design input. You cannot write meaningful microsegmentation policy without knowing which systems currently talk to which. Teams that write policy from documentation instead of observed traffic break production, then roll back, then abandon the project. Observed east-west flow is the dependency map that makes policy survivable.

Second, is enforcement verification. Once policy is in place, east-west visibility is how you confirm it holds, and how you detect the exception someone added at 2 AM during an outage and never removed.

East-west traffic analysis supplies the visibility that makes segmentation policy designable and verifiable. Enforcement remains the job of the segmentation and access control layer.

## Practical sequencing

A seven-step approach for teams starting from perimeter-only instrumentation.

1. Inventory what exports today. Most teams discover both unexpected coverage and unexpected gaps.
2. Rank segments by what they contain. Domain controllers, databases, backup infrastructure, and admin networks first.
3. Enable flow on the top-ranked segments, using sampling where the software path is the constraint.
4. Collect for four to six weeks before writing rules, long enough to include a month-end cycle.
5. Build per-role baselines instead of one network-wide profile.
6. Start with fan-out and administrative-port rules, which produce the least noise for the most signal.
7. Expand coverage on a quarterly cadence, tying each addition to a specific detection or design need.

## East-west analysis with NetFlow Analyzer

[ManageEngine NetFlow Analyzer](https://www.manageengine.com/products/netflow/) collects internal flow alongside perimeter export, so internal and external traffic sit in one dataset.

### See internal conversations

Host-to-host and group-to-group traffic views across monitored segments, which is the dependency evidence that migration planning and segmentation design both need.

### Identify unusual internal behavior

IP group profiling builds per-group baselines that reflect device role instead of a single network-wide normal, so a domain controller and a workstation are not measured against the same expectation. Behavioral rules cover fan-out, port-specific, and volume-deviation patterns.

### Collect from multiple telemetry sources

Flow from physical switching, virtual switching, and firewalls in one console, so coverage can expand segment by segment without adding a separate tool each time.

### Validate segmentation

Cross-segment traffic reports showing which conversations crossed which boundaries, usable as policy verification and as audit evidence.

## Frequently asked questions

### What is east-west traffic?

Traffic between systems inside your own network: application server to database, workstation to file share, service to service, node to node. North-south traffic crosses the boundary between your network and the outside world. The names come from traditional network diagrams, where internal tiers were drawn side by side and external connectivity was drawn top to bottom.

![Author](https://cdn.manageengine.com/itom/images/author/shynu.webp)

By Shynu,

ManageEngine Team

Lead product marketer for ManageEngine's FSO suite who breaks down network monitoring, bandwidth management, and the expanding role of flow data in network detection and response, with an emphasis on making technical concepts usable for the practitioners implementing them.