An API gateway accepts API requests from clients, applies defined rules, forwards them to the right backend service, and aggregates the responses. AWS aptly calls it the "front door" through which applications access data and functionality of services. Instead of solving access, security and governance separately in every service, the gateway consolidates them at one controlled point.

Clients / Partnersexternal access
→
API GatewayAuthN · Rate Limit · TLS · RoutingPerimeter
→
Services A · B · CObject authorization (BOLA)belongs here

The gateway bundles coarse controls at the entry. Fine-grained object authorization belongs in the service, not in the gateway.

Core functions

  • Routing and aggregation: route requests to the right service, merge multiple responses.
  • Authentication: verify identity, e.g. via API keys, JWT, OAuth/OIDC or mTLS.
  • Access control: coarse rights check before forwarding.
  • Rate limiting and quotas: limit request volume per client, user or API key.
  • TLS termination: handle encryption/decryption at the edge and relieve backends.
  • Transformation and protocol translation: rewrite payloads and headers, translate between HTTP, gRPC, WebSocket or GraphQL.
  • Observability: metrics, logging and tracing for all API traffic in one place.

Where it sits in the architecture

The gateway sits as a reverse proxy at the edge of the architecture and controls north-south traffic, i.e. from outside to inside. Internal service-to-service communication (east-west) is usually handled by a service mesh. It hides the internal service landscape behind a unified API facade, decoupling backends, versions and protocols. Unlike a load balancer, which distributes raw network traffic across servers, a gateway operates at the API level.

Security: necessary, but not sufficient

A gateway enforces coarse-grained controls at the perimeter: authentication, rate limits, and schema and protocol checks. But it doesn't know the business context of individual objects. That's exactly why it doesn't catch Broken Object Level Authorization (BOLA, OWASP API1:2023): whether a logged-in user is allowed to access this specific object can only be decided by the service itself. Per OWASP, object-level authorization is typically implemented at the code level.

Rule of thumb

The gateway protects the perimeter, object authorization belongs in the service's code. Secure APIs need both, that's defense in depth. More on this under Why API Security and OWASP API Top 10.

Example: Tyk

Tyk is an open-source API gateway written in Go. The core is licensed under MPL-2.0, alongside commercial components. Tyk consists of the gateway itself, a dashboard, and a developer portal. It supports many authentication methods (API keys, JWT, OAuth2/OIDC, mTLS, HMAC), plus rate limiting, quotas and analytics, and understands REST, GraphQL, gRPC and TCP.

Relevant for data sovereignty: Tyk is self-hostable, so it can be run on-premises or in an EU environment (Redis is required as the data store). This makes it suitable for cases where data must not leave your own jurisdiction.

Deployment patterns for API gateways: edge gateway, BFF and micro-gateway

An API gateway is a central entry point that, as a reverse proxy, routes client requests to the right services and bundles cross-cutting tasks such as authentication, SSL termination, mTLS and rate limiting. How it's rolled out depends on the shape of the architecture. Three patterns dominate, plus the question of managed vs. self-hosted.

Centralized edge/perimeter gateway. A single gateway at the edge of the system takes in all north-south traffic. Microsoft describes three core patterns here: Gateway Routing (layer-7 routing behind one endpoint), Gateway Aggregation (combining multiple backend calls into one response, less chattiness), and Gateway Offloading (cross-cutting functions such as SSL termination, WAF, logging in one place).

  • Advantages: decouples clients from services, reduces client complexity and latency through aggregation, centralizes security.
  • Disadvantages: per Microsoft, routing rules must be maintained with every service change and with changes to SSL certificates, IP allow lists, and security rules (dedicated processes or infrastructure-as-code are recommended). Architecturally, the general risk of a single point of failure and bottleneck also applies, which must be mitigated with redundancy.

Backend for Frontend (BFF). Instead of one generic backend, each client type (e.g. web, mobile) gets its own tailored gateway/backend. The pattern traces back to Sam Newman.

  • Advantages: tailored to the respective client, smaller and more maintainable services; frontend teams control language, release cadence and features autonomously; disruptions to one client stay isolated.
  • Disadvantages: more services mean higher operational overhead and code duplication; an extra network hop. Not worthwhile if only one client exists or all clients issue the same requests; with GraphQL a separate BFF layer is often unnecessary.

Micro-gateway / sidecar in a service mesh. Instead of a dedicated gateway, the ingress gateway of an already-running service mesh takes on the task. North-south traffic enters the mesh data plane right away and uses the same mTLS, workload identity, authorization policy and telemetry as east-west traffic (examples: Istio, Linkerd, Consul; for AKS, the Istio-based add-on is the supported managed option).

  • Advantages: consistent security and observability for internal and external traffic; no separate gateway layer needed if the mesh is already running.
  • Disadvantages: mesh ingress gateways tend to be weaker than dedicated API gateways for WAF, API productization, request transformation and global routing; combine or replace for such requirements.

Kubernetes ingress as a gateway. General-purpose reverse proxies such as NGINX or HAProxy can be run as ingress controllers in the cluster. Microsoft advises preferring the platform's built-in gateway/ingress solutions (e.g. Azure Container Apps, AKS) and using your own gateways only where flexibility is lacking. Running the gateway outside the cluster for isolation increases management complexity.

Managed vs. self-hosted. Managed services (e.g. Azure Application Gateway, Azure API Management, Azure Front Door) lower operational overhead; self-hosted reverse proxies (NGINX, HAProxy) offer mature, extensible feature sets and both free and commercial editions, but require your own lifecycle management. Note: API Management doesn't handle load balancing and should be combined with a load balancer or reverse proxy.

ASCII diagram
Edge gateway:   Client -> [Gateway: Routing, Auth, WAF, Aggregation] -> Service A/B/C
BFF:            Web client    -> [Web BFF]    -> Backend
                Mobile client -> [Mobile BFF] -> Backend
Micro-gateway:  Client -> [Mesh ingress gateway] -> Sidecar -> Service (mTLS in the mesh)

Schematic comparison of the three main patterns

Gateway, reverse proxy, load balancer, service mesh and WAF, clearly distinguished

The five terms overlap technically (all are intermediaries in traffic), but serve different purposes. A clean distinction helps with architecture and procurement decisions.

Reverse proxy. A reverse proxy sits in front of the web servers, accepts client requests, forwards them to a matching backend server, and returns its response. It is the public address of a site and hides the internal servers (abstraction, security). Per NGINX, a reverse proxy is worthwhile even with a single backend server, for example for TLS termination, caching, or routing by device, location or application state.

Load balancer. A load balancer distributes incoming requests across a group of similar servers to balance load, absorb the failure of individual servers, and enable scaling. It is therefore a specialized function and only makes sense with multiple servers present. Topics such as session persistence (requests from one client going to the same instance) belong here. In practice, reverse proxies often come with load balancing built in, which is why the two terms tend to blur.

API gateway. An API gateway is a single entry point for many APIs (typical in microservice landscapes). It handles API-specific logic:

  • Authentication and access control
  • Rate limiting resp. throttling and quotas
  • Routing by path plus request composition
  • Protocol and format transformation

A reverse proxy essentially only forwards; an API gateway understands and controls API semantics. It is thus a functionally extended form of the reverse proxy.

Service mesh. A service mesh addresses east-west traffic, i.e. communication among the services themselves, not north-south traffic from outside. It pulls the communication logic out of the services into an infrastructure layer: a sidecar proxy per service instance (for example Envoy in Istio) intercepts all incoming and outgoing traffic (data plane), controlled by a control plane. Functions include mTLS encryption, traffic management (e.g. canary deployments), central policy enforcement, and observability. Newer approaches (Istio Ambient) replace sidecars with node-level proxies.

WAF (Web Application Firewall). A WAF filters malicious web requests at the application layer (layer 7). It blocks or limits attack patterns such as SQL injection or cross-site scripting (XSS), and can filter by IP, HTTP headers, body or URI; layer-7 DDoS protection and bot management are often added. A WAF decides based on security rules, not based on load or API logic.

Overlaps. Load balancers and API gateways are usually also reverse proxies. Reverse proxies frequently take on load balancing and are increasingly becoming an insertion point for WAF functions. A service mesh, in turn, brings load balancing, policy and mTLS, but internally between services. Rule of thumb: reverse proxy = forward, load balancer = distribute, API gateway = API logic at the edge, service mesh = service-to-service traffic, WAF = filter attacks.

ASCII diagram
Client
  -> WAF            (filters SQLi/XSS, bots, L7 DDoS)
  -> Reverse Proxy / Load Balancer  (TLS, distributes load)
  -> API Gateway    (AuthN, rate limit, routing, transform)
  -> Service A --[mTLS via sidecar]-- Service B   (service mesh, east-west)

Typical layering from outside to inside

ComponentJobDistinction
Reverse proxyaccepts requests, forwards to backends, hides internal serversthe base layer, worthwhile even with one backend (TLS, caching, routing)
Load balancerdistributes load across multiple similar serversonly useful with multiple instances, often part of the reverse proxy
API gatewayone entry point for many APIs: auth, rate limiting, routing, transformationreverse proxy plus API-specific logic
Service meshcontrols traffic between services (sidecars)internal (east-west), not at the edge
WAFfilters malicious web requests by attack patterna protection layer, not a router or distributor

API gateway vs. API management: enforcement layer and platform

The terms are often used interchangeably but describe two different layers. An API gateway is a runtime component, API management is the overarching platform in which the gateway is embedded.

The API gateway sits in the request path between clients and backend services and forms a single entry point. At runtime it primarily handles:

  • Routing and aggregation of requests to the right backend services
  • Authentication and authorization (e.g. OAuth 2.0, OpenID Connect, API keys)
  • Rate limiting, caching, protocol transformation
  • Generating logs and telemetry for observability

Architecturally, a gateway typically separates a control plane (configuration, policies, routing rules) from a data plane, which processes traffic in real time and enforces the policies.

API management, by contrast, is the entire process of creating, publishing and operating APIs, including access control, usage metering, and possibly monetization. Per IBM, an API management platform combines several building blocks:

  • a gateway that processes requests and security at runtime
  • a developer portal with an API catalog, documentation, and onboarding/keys
  • a reporting or analytics system for usage data
  • lifecycle management, which accompanies an API from creation to retirement, including versioning

The central relationship: the gateway is the enforcement layer of API management. A central control plane sets policies and routing rules, and the gateway enforces exactly these rules, encryption and authentication on every request, and routes dynamically to the backend.

Practical rule of thumb for decision makers: if you only need routing, security and load protection in front of a few services, a gateway is enough. Once many APIs are published, versioned, documented and billed across teams to internal, partner or external consumers (per IBM, very large enterprises with at least USD 10 billion in annual revenue manage an average of around 1,400 APIs, based on an f5 report from 2024), an API management platform is the right layer, with the gateway remaining the runtime building block within it.

ASCII diagram
API Management (platform)
├─ Developer portal   (catalog, docs, key onboarding)
├─ Lifecycle/versioning
├─ Analytics/reporting
└─ API Gateway (runtime / enforcement)
     ├─ Routing & aggregation
     ├─ Auth (OAuth2/OIDC, API keys)
     └─ Rate limiting, caching

The gateway as the runtime building block within the API management platform.

Self-hosted and sovereign gateways: full control over your own API traffic

An API gateway sits at the control point between clients and backends: it terminates authentication, enforces rate limits, routes requests, and collects analytics. That means practically all API traffic, including payloads and metadata, flows through this component. Using a managed SaaS from a third party here hands over part of that control. For digital sovereignty, it is therefore decisive whether the gateway is open source and self-operable.

The main arguments for a self-hosted, open-source gateway:

  • Full data control: API traffic, payloads and metadata never leave your own infrastructure and are not passed on to an external operator.
  • EU hosting of your choice: operation on-premises, in an EU cloud, or on Kubernetes, according to your own compliance requirements.
  • No vendor lock-in: open-source code and declarative configuration can be migrated and kept running independently of the vendor.
  • Auditability: open source code is traceable and verifiable, instead of trusting a black box as a service.

Two widely used, open-source and self-hostable examples:

  • Tyk Gateway: an open-source gateway written in Go that supports REST, GraphQL, TCP and gRPC. It comes without feature lockout (batteries included), with auth, rate limiting, quotas and analytics. Tyk runs natively on Kubernetes via the Tyk Kubernetes Operator and can be self-operated as a self-managed variant via Docker or Docker Compose.
  • Kong Gateway: per the vendor, the most widely adopted open-source API gateway, built on an NGINX engine. It is deployment-agnostic and can run on-premises, in any cloud, on Kubernetes, or serverless, with or without a database, and can be managed via declarative configuration through CI/CD pipelines.

Important for the assessment: for both vendors, the core gateway is open source, while extended management, dashboard and portal functions are partly reserved for enterprise or SaaS editions (such as Kong Konnect or Tyk Cloud). For maximum sovereignty, it's worth checking exactly which functions are actually included in the self-managed, open-source variant.

Shell
git clone https://github.com/TykTechnologies/tyk-gateway-docker
cd tyk-gateway-docker
docker-compose up -d   # Tyk Gateway + Redis locally, no external service

Running Tyk Gateway yourself via Docker Compose, per the project README

Frequently asked questions

Is an API gateway enough for API security?

No. A gateway secures the perimeter with authentication, rate limiting, TLS and schema checks, but doesn't detect authorization errors like BOLA. Only the application, in the context of the user, can judge whether an access is allowed. A gateway is necessary but not sufficient.

What is the difference between an API gateway and a WAF?

A WAF filters known attack patterns in traffic (negative security). An API gateway enforces identity, quotas and the approved API schema (positive security). They complement each other but don't replace one another.

Does a gateway also protect undocumented APIs?

No. A gateway only protects routes registered with it. Shadow, zombie or phantom APIs bypass it. A complete, current inventory through discovery is therefore a precondition.

Sources

Keep reading
Why it mattersWhy API Security Matters RisksOWASP API Security Top 10