An API gateway usually sits at a client-facing boundary and manages north-south API traffic. A service mesh usually applies traffic, identity, encryption, and observability policy to east-west communication between services. They overlap in routing, TLS, authorization, resiliency, and telemetry, but they solve different operational problems. Many microservice environments use both.

That distinction is a design pattern rather than a protocol rule. An internal API gateway can route east-west calls, and a service mesh can provide ingress gateways. Kubernetes Gateway API also now supports mesh use cases through the GAMMA work, which has been in the Standard Channel since Gateway API v1.1.0. The configuration models are converging even while API-management and service-to-service responsibilities remain different.

What an API gateway does

An API gateway is a reverse-proxy and policy layer between API consumers and backend services. Microsoft’s Azure Architecture Center describes the pattern as routing client requests to services while offloading cross-cutting concerns such as authentication, TLS or mTLS, IP controls, and client rate limiting.

Commercial and open-source gateways vary widely, but common responsibilities include:

• Host, path, header, method, and protocol-aware routing.
• OAuth/OIDC/JWT validation, API keys, client certificates, or custom authentication.
• Consumer, tenant, route, burst, and quota-based rate controls.
• TLS termination and certificate management.
• Request/response transformation, header normalization, and protocol adaptation where supported.
• Schema or payload validation where supported.
• API version/stage routing and traffic splitting.
• Access logs, metrics, tracing, and analytics.
• API products, usage plans, developer portal, or monetization in API-management products.

The final items are important. “API gateway” and “API management platform” are often used together, but not every gateway provides developer portals, subscription plans, lifecycle workflows, or analytics. Compare concrete products instead of assigning every possible feature to the category.

What a service mesh does

A service mesh is infrastructure for managing communication among services. Istio describes its architecture as a data plane of proxies that mediate workload traffic and a control plane that configures those proxies. Mesh implementations may use sidecars, node-level or ambient data planes, proxyless clients, or other topologies; the core idea is consistent service-to-service policy independent of individual application code.

Common mesh responsibilities include:

• Workload identity and mutual TLS between services.
• Service-to-service authorization policy.
• Service discovery integration and traffic routing.
• Retries, timeouts, load balancing, circuit breaking, and outlier handling.
• Canary, blue/green, and weighted traffic distribution.
• Service-level telemetry, tracing, and connection metrics.
• Ingress, egress, or cross-cluster gateways as part of mesh topology.
• Policy consistency across many independently developed workloads.

A mesh does not eliminate application authorization. A workload identity can prove that “service A called service B,” but service B may still need to decide whether the propagated end user may access a particular account, whether an order transition is valid, or whether returned fields are appropriate.

API gateway vs service mesh comparison

How security responsibilities should be split

External consumer identity belongs near the API boundary

The gateway is a natural place to validate client certificates, OAuth access tokens, JWT issuer/audience/signature, API keys, request size, CORS, and public route policy. Centralizing these checks can reduce duplicated edge code and keep malformed or unauthorized traffic away from backend services.

However, the backend should not blindly equate “the gateway accepted this token” with “this action is allowed.” Resource ownership, tenant isolation, field-level policy, transaction rules, and authorization that depends on current domain state usually belong in the service that owns that data and behavior.

Workload identity belongs in the service communication layer

A mesh is useful when many services need consistent encrypted service-to-service communication. With workload identity and mTLS, a destination can know which authenticated workload established the connection and enforce service-level allow/deny rules.

End-user context may still need propagation through the system. Keep workload identity and end-user identity conceptually separate: “billing-service is calling” and “user 42 requested this invoice” answer different security questions.

Rate limiting belongs at more than one layer

At the public edge, gateway rate limits protect APIs by consumer, credential, tenant, route, or subscription. AWS API Gateway, for example, documents route-level throttling and REST API usage plans with per-client throttles and quotas. Inside the platform, service-specific concurrency or rate controls can protect fragile dependencies.

Neither layer should assume request count equals business cost. One report request can be more expensive than hundreds of cache hits. Combine static limits with endpoint cost, identity, response volume, and runtime behavior where appropriate. See per-user API rate limiting and throttling for a deeper treatment.

Runtime API abuse crosses both layers

A valid client can pass the gateway and then make authorized-looking calls that become abusive as a sequence: object probing, bulk extraction, credential-driven scraping, excessive data access, or business-logic misuse. A mesh may show the service path, but it may not understand the application meaning of the objects or response data.

This is where runtime API visibility complements infrastructure policy. The API runtime security guide covers request, response, identity, sensitive-data, and behavior context beyond basic routing.

Where gateways and meshes overlap

Overlap has grown because both categories are built around programmable Layer 4/Layer 7 proxies and policy. They can both route traffic, terminate or originate TLS, enforce authorization rules, emit telemetry, retry calls, split traffic, and integrate with identity systems.

Kubernetes makes the convergence visible. Gateway API was originally centered on ingress, but the GAMMA initiative extended it to service-mesh use cases. In the standard mesh model, route resources such as HTTPRoute can attach directly to Kubernetes Service resources. Gateway API v1.6, released in June 2026, further expanded the standard routing surface with TCPRoute and UDPRoute graduating to Standard.

Ingress gateway is not always an API gateway

A service-mesh ingress gateway gets traffic into the mesh and can provide sophisticated HTTP routing and security. If your requirements stop there, it may be enough. If you need API consumer management, developer onboarding, subscriptions, quotas, transformations, API lifecycle, or specialized API analytics, a dedicated API gateway or management layer may still be appropriate.

API gateway is not automatically a mesh

You can route internal service calls through gateways, but a central gateway for every east-west hop can add latency, operational coupling, and chokepoints. A mesh is designed to distribute communication policy across the service topology and apply it consistently even when services call each other directly.

Common architecture patterns

A practical request flow

External client
    |
    | OAuth/JWT, quota, API route policy
    v
API Gateway
    |
    | propagated user/tenant context
    v
Service A == mTLS / workload policy ==> Service B
    |                                      |
    |                                      +-- object/business authorization
    +-- business authorization

Runtime API visibility can observe supported request/response paths
at the boundary where application data is available.

The security design should specify which component owns each decision. Avoid duplicating the same mutable rule in the gateway, mesh, and application unless there is a deliberate defense-in-depth reason and one authoritative source of policy.

Decision framework: gateway, mesh, or both?

Questions to ask before adding a service mesh

• How many services and teams need the same mTLS, identity, and traffic policies?
• Are east-west incidents or inconsistent client libraries creating measurable operational pain?
• Can the platform team operate the mesh control/data plane, upgrades, certificates, and debugging?
• Do applications need end-user identity beyond workload identity?
• What latency and resource overhead is acceptable?
• Which policies remain application-owned?

Questions to ask before adding an API gateway

• Who are the API consumers: browsers, mobile apps, partners, internal apps, services, or agents?
• Do you need OAuth/JWT verification, API keys, per-consumer quotas, request transformation, or API products?
• How will API versions, deprecation, and external domains be managed?
• Which routes must be public, private, partner-only, or admin-only?
• What response and behavior visibility is required for security operations?
• Can the gateway preserve identity and tracing context into the mesh?

Observability and troubleshooting

Gateways provide a strong view of traffic crossing the API boundary. Meshes can provide a broader graph of service-to-service communication. Use both data sets without assuming either one is the complete security record.

Correlate gateway request IDs, authenticated consumer identity, mesh workload identity, distributed traces, service logs, and API response context. In Kubernetes, runtime API visibility across ingress and east-west traffic helps connect infrastructure topology to what the APIs actually expose.

For enterprise operations, define common fields for service, route, environment, tenant, identity, status, latency, response bytes, and trace/request ID. The enterprise API monitoring guide provides a broader monitoring model.

Common architecture mistakes

Gateway and mesh architecture checklist

Authoritative references

Use each layer for the boundary it understands best

API gateways and service meshes are complementary when an architecture has both external API consumers and a large internal service graph. The gateway understands the API consumer boundary; the mesh understands the workload communication boundary; the application understands the business rule.

Modern routing APIs blur configuration lines, but a clear responsibility model remains valuable. Define where identity is established, where policy is enforced, where retries and limits live, how user context crosses services, and which layer provides the evidence needed to investigate real API behavior.

Frequently asked questions