North-south traffic is the flow between external clients and the platform at the edge, usually entering through a gateway. East-west traffic is the internal communication between services once requests are inside the platform. The distinction matters because edge controls secure inbound access, while internal controls govern service-to-service trust, authorization, and blast radius.
How north-south traffic behaves at the API edge
North-south traffic is the request and response path between outside clients and the platform perimeter. In an API platform, that usually means traffic entering through an API gateway, ingress controller, or edge proxy before it reaches internal services. The security posture here is shaped by exposure to the internet, client authentication, rate limits, request validation, and coarse-grained controls that can stop bad traffic early.
It is the boundary where the platform decides whether to accept, reject, or shape traffic before deeper processing begins. That makes north-south design the right place for controls such as authentication enforcement, API schema checks, throttling, WAF-style inspection, and abuse detection. If the edge is weak, the rest of the platform inherits more risk than internal controls can realistically absorb.
What east-west traffic means inside the platform
East-west traffic is the internal service-to-service communication that happens after a request enters the platform. It covers calls between microservices, backend jobs, databases, message consumers, internal APIs, and platform components that cooperate to complete a single user action. The main security question shifts from external exposure to trust boundaries inside the environment.
This internal traffic matters because compromise rarely stops at the first service. Once inside, an attacker can try to move laterally, reuse tokens or session context, invoke overly broad internal APIs, or exploit weak service authorization. East-west controls therefore focus on fine-grained authorization, service identity, segmentation, mTLS or equivalent trust controls, and monitoring that can spot unusual internal call patterns.
Why the distinction changes API security design
The north-south and east-west split is useful because it separates two different control problems. Edge traffic is about authenticating external actors and filtering untrusted input. Internal traffic is about limiting blast radius, preserving service-to-service trust, and preventing a single compromise from becoming platform-wide access.
That difference also affects operations. A gateway can centralise enforcement for north-south traffic, but internal service paths are usually more distributed and harder to govern consistently. Teams often underestimate how quickly east-west traffic grows once a platform adopts microservices, asynchronous queues, and internal APIs. The result is that the internal layer becomes the real security boundary even when the gateway looks well controlled.
Risk and Threat Considerations
When organisations treat the gateway as the whole security model, they can leave east-west traffic underprotected. That creates a common lateral-movement path, because a single compromised service, token, or workload can be used to reach adjacent services with weaker internal authorization or weak segmentation.
Failure mechanism: Attackers or buggy internal components abuse implicit trust between services, reuse credentials or tokens beyond their intended scope, or call internal APIs that were never designed for hostile use.
Impact: The blast radius expands from one exposed edge endpoint to multiple internal systems, increasing the chance of privilege escalation, data exposure, service tampering, and difficult-to-contain incident spread.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Internal service calls need explicit authorization boundaries. |
| Recommendation — Enforce function-level authorization on internal APIs and service routes. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Service-to-service east-west traffic depends on authenticating non-human callers. |
| Recommendation — Authenticate service callers before allowing internal API access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question hinges on distinct trust handling at edge and inside the platform. |
| Recommendation — Apply zero-trust principles to separate edge trust from internal service trust. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Traffic direction affects how access is granted and constrained across platform boundaries. |
| Recommendation — Restrict access paths so internal services only reach required resources. | ||
Practitioner Guidance
What to verify: Confirm that north-south and east-west paths are enforced differently in design and in telemetry. If the same control pattern is being used for both, one of the layers is usually under-specified.
Decision rule: Use the gateway to harden external entry, but treat internal service trust as its own control plane. If a service can reach sensitive internal data or actions without explicit service-to-service authorization, the east-west boundary is too loose.
What good looks like: External requests are authenticated and screened at the edge, while internal calls are identity-bound, least-privileged, observable, and segmented enough that one service compromise does not become uncontrolled platform access.
Practitioner takeaway: The main mistake is assuming “inside the cluster” means “trusted.” In mature API platforms, north-south controls reduce exposure, but east-west controls determine whether a breach stays local or turns into lateral movement.
Related resources from NHI Mgmt Group
- What is the difference between east west and north south traffic in a zero trust architecture?
- What is the difference between north-south and east-west traffic in an identity security architecture?
- What is the difference between north-south and east-west traffic in Kubernetes service mesh design?
- How should security teams implement API observability across north-south, east-west, shadow, legacy, and partner APIs without slowing delivery?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
