Episode 28 — Traffic Flows: designing for north/south versus east/west
In Episode Twenty-Eight, titled “Traffic Flows: designing for north/south versus east/west,” we treat flow direction as the clue for where to apply controls, because many scenario questions become straightforward once you know whether the traffic is crossing a perimeter boundary or moving laterally inside the environment. Architects often get pulled into debating tools, but the more important question is where the control point should sit so it actually sees the traffic it needs to govern. North-south traffic is usually about users, clients, and external access paths, while east-west traffic is usually about service-to-service communication and lateral movement risk. The exam uses this distinction to test whether you can place inspection, authentication, and segmentation in the right locations without creating unnecessary friction. When you design with flows in mind, you avoid two common failures: over-inspecting internal traffic until performance collapses, and under-controlling internal movement until one compromise becomes an environment-wide incident. The goal of this episode is to make north-south and east-west feel like a practical lens you can apply immediately to any scenario prompt.
Before we continue, a quick note: this audio course is a companion to the Cloud Net X books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
North-south traffic is user-to-service movement that crosses perimeter boundaries, meaning it typically enters or exits the environment through defined ingress and egress points. Users might be remote employees, customers, partners, or automated clients, and the critical property is that the traffic crosses a trust boundary where you cannot assume endpoint safety. North-south paths often traverse gateways, load balancers, and edge firewalls because those are the places where you can enforce authentication, rate limiting, and inspection consistently. This traffic direction is usually where you publish services, terminate secure sessions, and apply the first layer of identity checks that decide who is allowed in. In exam scenarios, north-south cues include internet-facing services, remote access, customer portals, and any mention of perimeter exposure or inbound requests. Understanding north-south as boundary-crossing user traffic helps you prioritize controls that address identity, abuse prevention, and visibility at ingress. It also helps you reason about availability and scale, because north-south paths often concentrate traffic and failures at a few entry points.
East-west traffic is service-to-service movement inside the environment, meaning it typically stays within internal networks and connects components that collectively deliver an application. These flows include application programming interface calls, database queries, cache access, message bus interactions, and microservice conversations that happen after a request has already entered the environment. East-west is often the majority of traffic volume in modern architectures, especially when systems are decomposed into multiple services and when distributed data access is common. The key risk with east-west is lateral movement, because once an attacker compromises one internal workload, unrestricted east-west reachability can allow rapid expansion of the compromise. In exam scenarios, east-west cues include microservices, internal application tiers, backend services, and phrases like “services communicating inside the network.” East-west flows are also where performance can become sensitive, because a single user transaction can fan out into many internal calls. When you treat east-west as an internal dependency graph, you can place controls that limit spread without destroying performance.
A practical rule is to place edge controls for north-south flows, such as web application firewalls and gateways, because these controls are designed to handle hostile traffic and enforce consistent entry policy. Web application firewalls help detect and block malicious request patterns, injection attempts, and abuse patterns that target application-layer weaknesses, which is especially relevant when services are internet-facing. Gateways can centralize authentication, authorization, rate limiting, and routing decisions, ensuring that only validated traffic reaches internal services. Edge controls also provide a strong observation point, because they see the highest-risk traffic at the boundary where trust changes, making logs high value for both detection and troubleshooting. For availability, centralized edge controls can be scaled and protected with redundancy, and their placement allows you to manage the perimeter without embedding heavy inspection into every internal hop. In exam logic, when the scenario describes remote users, public access, or published services, answers that place strong edge controls at ingress tend to align with best practice. The key is that north-south controls should be concentrated at the boundary because that is where they are both effective and efficient.
For east-west flows, segmentation and microsegmentation are the core tools because they control lateral movement by limiting which services can talk to which other services. Segmentation can be network-based, such as separating tiers into different subnets or zones, and it can be identity-based, such as using security groups, labels, or workload identities to enforce allowed communications. Microsegmentation is the idea of enforcing least privilege at a fine-grained level, allowing only specific service-to-service flows rather than allowing broad internal connectivity simply because systems are “inside.” This matters because internal compromises are common, and the difference between a contained incident and a full breach is often whether east-west movement is restricted and monitored. Microsegmentation also helps reduce blast radius for misconfigurations, because a faulty service cannot accidentally call everything if policies are tight. In exam scenarios, when the prompt emphasizes limiting lateral movement, protecting sensitive internal data, or enforcing least privilege inside the environment, segmentation-focused answers are often correct. The trick is to implement segmentation in a way that remains operable, using clear service identities and consistent policy patterns rather than ad hoc rule sprawl.
Monitoring differs by flow type, and understanding that difference helps you choose where to invest visibility without drowning in noise. North-south monitoring focuses on ingress and egress because that is where you see authentication outcomes, abuse attempts, unusual client behavior, and perimeter scanning patterns. It also focuses on volumetric patterns and availability signals, because edge paths are where denial-of-service conditions and traffic surges show up first. East-west monitoring focuses on lateral behavior inside the environment, such as unexpected service-to-service calls, unusual authentication token usage between services, and anomalous access to data stores. East-west visibility often requires different telemetry because you care about internal dependencies, service graphs, and abnormal traversal between zones rather than about raw inbound request volume. The exam sometimes tests this by describing an incident where an attacker moved laterally after initial access, which is an east-west visibility problem rather than a perimeter-only problem. Conversely, it may describe external abuse patterns, which are best detected at north-south entry points. When you match monitoring to flow direction, you get higher signal and more actionable alerts with less overhead.
Consider a scenario where application programming interface calls between services are timing out intermittently, and the organization needs better east-west visibility to pinpoint where the slowdown is occurring. In this case, focusing only on perimeter logs will not reveal which internal hop is slow, because the problem is inside the environment among service dependencies. East-west visibility should help you see which service calls which, how long each hop takes, and whether failures correlate with specific segments, policies, or nodes. You also want to know whether segmentation rules are blocking or delaying traffic, because misconfigured internal policies can produce timeouts that look like performance issues. In exam reasoning, the best answer in this scenario often involves improving internal telemetry and controlling service-to-service paths rather than adding more perimeter inspection. The point is that internal performance and reliability depend on the internal graph, and you must observe that graph to diagnose it. When the scenario is about service-to-service behavior, your controls and monitoring should be placed where that behavior occurs.
Now consider a scenario where remote users require north-south authentication and inspection to access a corporate application, because this is where edge controls are the primary control plane. Remote users arrive from untrusted networks and unmanaged devices, so you need strong identity gates at the ingress, such as multi-factor authentication, device posture checks, and consistent session management. You also want inspection and rate limiting at the boundary to reduce abuse and to detect anomalies early, because the perimeter is where hostile traffic patterns are most obvious. Once authenticated, the user’s traffic should be routed to internal services through controlled gateways that can log access and enforce least privilege. In exam terms, the best answer in such a scenario typically places authentication and inspection at the edge rather than relying on internal controls alone. Internal segmentation still matters, but it is not the first line of defense for remote access, because the primary risk is at the perimeter boundary. When you see remote users and perimeter access, think north-south and place controls accordingly.
A pitfall is inspecting everything east-west with heavy tooling, because that can introduce latency and cost that undermines the very workloads you are trying to protect. East-west traffic volume can be enormous in microservices and distributed systems, and applying deep inspection to every internal flow can create bottlenecks, increase failure domains, and make normal operations brittle. It can also create cost issues because inspection at scale requires processing, storage for logs, and operational overhead, and those costs grow with internal chatter. Over-inspection can turn minor internal congestion into major user-visible outages, because every internal hop becomes slower and more failure-prone. The exam sometimes tests this by offering answers that propose “inspect all internal traffic everywhere,” which may sound secure but can violate performance and operability constraints implied by the scenario. A better approach is targeted controls, focusing on boundary crossings, high-risk flows, and sensitive data paths, combined with segmentation that reduces unnecessary communication. The design lesson is that security must be effective and sustainable, not maximal in theory.
The opposite pitfall is ignoring east-west controls, because that allows compromise to spread rapidly once an attacker breaches any internal workload. Many incidents begin with one compromised endpoint or one exploited service, and the real damage comes from lateral movement that reaches identity systems, data stores, and management planes. If internal networks are flat and unrestricted, the attacker’s job becomes easier, and defenders lose containment options. Ignoring east-west also reduces detection capability because unusual internal connections are harder to detect when everything is permitted, and it becomes difficult to distinguish malicious movement from legitimate chatter. In exam scenarios, when the prompt mentions a breach, lateral movement, or sensitive data access inside the environment, the correct answer often involves segmentation, microsegmentation, and internal monitoring rather than perimeter controls alone. The perimeter can be perfect and still fail to stop internal spread if the inside is wide open. The key is that north-south controls reduce initial access risk, but east-west controls reduce blast radius and stop expansion after initial compromise.
There are quick wins that improve flow-driven design, such as mapping flows per application and labeling control points, because clarity about what talks to what is the foundation for both security and performance. Flow mapping means you identify the main north-south entry points, the key east-west dependencies, and the data stores and identity services that form the core of the application graph. Labeling control points means you identify where authentication happens, where inspection happens, where segmentation is enforced, and where logs are collected, so you can validate that controls align with flow direction. This practice reduces arguments because it turns architecture discussion into a map of dependencies and enforcement rather than into abstract preferences. It also supports troubleshooting because when a failure occurs, you can quickly see which control points could be involved in that specific flow. Exam scenarios that emphasize “best design” often align with this disciplined mapping mindset, because it leads to coherent control placement. The practical lesson is that if you cannot name the flow, you cannot control it or observe it effectively.
A useful memory anchor is perimeter handles users, segmentation handles services internally, because it compresses the north-south versus east-west distinction into a single actionable phrase. Perimeter handles users means north-south flows should be governed by edge controls that authenticate, inspect, and log inbound and outbound access across trust boundaries. Segmentation handles services internally means east-west flows should be governed by segmentation and microsegmentation that limit lateral movement and enforce least privilege between services. This anchor is not meant to eliminate nuance, but it gives you a default that is correct more often than not in scenario questions. It also helps you avoid swapping the focus, such as attempting to solve remote access with internal segmentation alone or attempting to solve lateral movement with only perimeter tools. When you can recite this anchor, you can orient yourself quickly and then refine the details based on the scenario’s constraints. The exam rewards this orientation because it reflects the practical reality of control placement.
To end the core, name three controls for each flow type, because this exercise forces you to connect the flow direction to real control points rather than to abstract goals. For north-south flows, you typically think of an identity-aware gateway, a web application firewall, and perimeter logging that captures authentication outcomes and request patterns, because these controls live where users enter. For east-west flows, you typically think of segmentation rules that restrict service-to-service access, microsegmentation at the workload level using security groups or policy constructs, and internal telemetry that reveals service dependencies and lateral anomalies. The point is not the exact list, it is that the controls are appropriate to the direction and the risk of the flow. North-south controls focus on untrusted entry and abuse prevention, while east-west controls focus on limiting spread and governing internal dependencies. In exam reasoning, answers that place these controls in the wrong place often fail because they do not align with the flow reality implied by the scenario. When you can name controls by flow type quickly, you are ready to pick the best answer under time pressure.
In the conclusion of Episode Twenty-Eight, titled “Traffic Flows: designing for north/south versus east/west,” the central lens is to use flow direction to decide where to enforce controls and where to focus monitoring. North-south flows are user-to-service traffic crossing perimeter boundaries, so edge controls like web application firewalls, gateways, and strong authentication belong at ingress and egress, with monitoring focused on entry behavior and abuse patterns. East-west flows are service-to-service traffic inside the environment, so segmentation and microsegmentation are essential to limit lateral movement, with monitoring focused on internal dependencies and anomalous lateral behavior. You avoid the pitfall of inspecting everything east-west with heavy tooling that creates latency and cost, and you avoid the pitfall of ignoring east-west controls that lets compromise spread rapidly inside. You gain quick wins by mapping flows per application and labeling control points so enforcement matches the real traffic graph. Assign yourself one flow mapping rehearsal by picking a single application and stating its main north-south entry flow and its top three east-west dependencies, then naming the control points that govern each, because that rehearsal builds the exact “flow first” instinct the exam is testing.
