Was ist ein API Gateway?

Ein API Gateway nimmt API-Anfragen von Clients entgegen, wendet definierte Regeln an, leitet sie an den richtigen Backend-Dienst weiter und bündelt die Antworten. AWS nennt es treffend die „Vordertür", durch die Anwendungen auf Daten und Funktionen der Dienste zugreifen. Statt Zugriff, Sicherheit und Governance in jedem Dienst einzeln zu lösen, bündelt das Gateway sie an einer kontrollierten Stelle.

Kernfunktionen

• Routing und Aggregation: Anfragen an den passenden Dienst leiten, mehrere Antworten zusammenführen.
• Authentifizierung: Identität prüfen, etwa über API-Keys, JWT, OAuth/OIDC oder mTLS.
• Zugriffskontrolle: grobe Rechteprüfung, bevor weitergeleitet wird.
• Rate Limiting und Quotas: Anfragevolumen pro Client, Nutzer oder API-Key begrenzen.
• TLS-Terminierung: Ver- und Entschlüsselung am Rand übernehmen und Backends entlasten.
• Transformation und Protokollübersetzung: Payloads und Header umschreiben, zwischen HTTP, gRPC, WebSocket oder GraphQL übersetzen.
• Observability: Metriken, Logging und Tracing für allen API-Verkehr an einer Stelle.

Wo es in der Architektur sitzt

Das Gateway sitzt als Reverse Proxy am Rand der Architektur und steuert den Nord-Süd-Verkehr, also von außen nach innen. Die interne Dienst-zu-Dienst-Kommunikation (Ost-West) übernimmt meist ein Service Mesh. Es verbirgt die interne Dienstlandschaft hinter einer einheitlichen API-Fassade und entkoppelt so Backends, Versionen und Protokolle. Anders als ein Load Balancer, der rohen Netzwerkverkehr auf Server verteilt, arbeitet ein Gateway auf API-Ebene.

Sicherheit: notwendig, aber nicht hinreichend

Ein Gateway erzwingt grobgranulare Kontrollen am Perimeter: Authentifizierung, Rate Limits sowie Schema- und Protokollprüfungen. Es kennt aber nicht den Geschäftskontext einzelner Objekte. Genau deshalb fängt es Broken Object Level Authorization (BOLA, OWASP API1:2023) nicht: ob ein eingeloggter Nutzer auf genau dieses Objekt zugreifen darf, kann nur der Dienst selbst entscheiden. Laut OWASP wird objektbezogene Autorisierung üblicherweise auf Code-Ebene implementiert.

Beispiel: Tyk

Tyk ist ein quelloffenes API-Gateway, geschrieben in Go. Der Kern steht unter der MPL-2.0-Lizenz, daneben gibt es kommerzielle Komponenten. Zu Tyk gehören das Gateway selbst, ein Dashboard und ein Developer-Portal. Es unterstützt viele Authentifizierungsverfahren (API-Keys, JWT, OAuth2/OIDC, mTLS, HMAC), dazu Rate Limiting, Quotas und Analytics, und versteht REST, GraphQL, gRPC und TCP.

Für die Datensouveränität relevant: Tyk ist self-hostable, lässt sich also on-premise oder in einer EU-Umgebung selbst betreiben (als Datenspeicher wird Redis benötigt). Damit eignet es sich auch dort, wo Daten den eigenen Rechtsraum nicht verlassen sollen.

Einsatzmuster für API Gateways: Edge-Gateway, BFF und Micro-Gateway

Ein API Gateway ist ein zentraler Einstiegspunkt, der als Reverse Proxy Client-Anfragen an die passenden Dienste leitet und übergreifende Aufgaben wie Authentifizierung, SSL-Terminierung, mTLS und Rate Limiting bündelt. Wie es ausgerollt wird, hängt vom Schnitt der Architektur ab. Drei Muster dominieren, ergänzt um die Frage managed vs. self-hosted.

Zentrales Edge-/Perimeter-Gateway. Ein einziges Gateway am Rand des Systems nimmt den gesamten Nord-Süd-Verkehr entgegen. Microsoft beschreibt dazu drei Kernmuster: Gateway Routing (Layer-7-Routing hinter einem Endpunkt), Gateway Aggregation (mehrere Backend-Calls zu einer Antwort bündeln, weniger Chattiness) und Gateway Offloading (übergreifende Funktionen wie SSL-Terminierung, WAF, Logging an einer Stelle).

• Vorteile: entkoppelt Clients von Diensten, reduziert Client-Komplexität und Latenz durch Aggregation, zentralisiert Sicherheit.
• Nachteile: Routing-Regeln müssen laut Microsoft bei jedem Service-Wechsel sowie bei Änderungen an SSL-Zertifikaten, IP-Allow-Lists und Sicherheitsregeln gepflegt werden (eigene Prozesse bzw. Infrastructure-as-Code empfohlen). Architektonisch gilt zudem das generelle Risiko eines Single Point of Failure und Engpasses, das durch Redundanz abzufedern ist.

Backend for Frontend (BFF). Statt eines generischen Backends bekommt jede Client-Art (z.B. Web, Mobile) ein eigenes, maßgeschneidertes Gateway/Backend. Das Muster geht auf Sam Newman zurück.

• Vorteile: auf den jeweiligen Client zugeschnitten, kleinere und einfacher wartbare Dienste; Frontend-Teams steuern Sprache, Release-Takt und Features autonom; Störungen eines Clients bleiben isoliert.
• Nachteile: mehr Dienste bedeuten höheren Betriebsaufwand und Code-Duplizierung; zusätzlicher Netzwerk-Hop. Nicht sinnvoll, wenn nur ein Client existiert oder alle Clients gleiche Anfragen stellen; bei GraphQL erübrigt sich eine separate BFF-Schicht oft.

Micro-Gateway / Sidecar im Service Mesh. Statt eines dedizierten Gateways übernimmt das Ingress-Gateway eines bereits laufenden Service Mesh die Aufgabe. Nord-Süd-Verkehr tritt sofort in die Mesh-Dataplane ein und nutzt dieselbe mTLS, Workload-Identität, Autorisierungs-Policy und Telemetrie wie der Ost-West-Verkehr (Beispiele: Istio, Linkerd, Consul; für AKS ist das Istio-basierte Add-on die unterstützte managed Option).

• Vorteile: einheitliche Sicherheit und Beobachtbarkeit für internen und externen Verkehr; keine separate Gateway-Schicht nötig, wenn das Mesh bereits läuft.
• Nachteile: Mesh-Ingress-Gateways sind bei WAF, API-Produktisierung, Request-Transformation und globalem Routing meist schwächer als dedizierte API Gateways; bei solchen Anforderungen kombinieren oder ersetzen.

Kubernetes Ingress als Gateway. General-Purpose-Reverse-Proxies wie NGINX oder HAProxy lassen sich als Ingress Controller im Cluster betreiben. Microsoft rät, eingebaute Gateway-/Ingress-Lösungen der Plattform (etwa Azure Container Apps, AKS) zu bevorzugen und eigene Gateways nur bei fehlender Flexibilität zu nutzen. Wer das Gateway zur Isolation außerhalb des Clusters betreibt, erhöht die Verwaltungskomplexität.

Managed vs. self-hosted. Managed-Dienste (z.B. Azure Application Gateway, Azure API Management, Azure Front Door) senken den Betriebsaufwand; self-hosted Reverse Proxies (NGINX, HAProxy) bieten reife, erweiterbare Feature-Sets und freie wie kommerzielle Editionen, erfordern aber eigenes Lifecycle-Management. Hinweis: API Management übernimmt kein Load Balancing und sollte mit einem Load Balancer oder Reverse Proxy kombiniert werden.

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 im Mesh)

Schematische Gegenüberstellung der drei Hauptmuster

Gateway, Reverse Proxy, Load Balancer, Service Mesh und WAF klar abgegrenzt

Die fünf Begriffe überschneiden sich technisch (alle sind Vermittler im Datenverkehr), erfüllen aber unterschiedliche Aufgaben. Eine saubere Trennung hilft bei Architektur- und Beschaffungsentscheidungen.

Reverse Proxy. Ein Reverse Proxy sitzt vor den Webservern, nimmt Client-Anfragen entgegen, leitet sie an einen passenden Backend-Server weiter und gibt dessen Antwort zurück. Er ist die öffentliche Adresse einer Site und verbirgt die internen Server (Abstraktion, Sicherheit). Laut NGINX lohnt sich ein Reverse Proxy schon bei einem einzigen Backend-Server, etwa für TLS-Terminierung, Caching oder Routing nach Gerät, Standort oder Anwendungszustand.

Load Balancer. Ein Load Balancer verteilt eingehende Anfragen auf eine Gruppe gleichartiger Server, um Last auszugleichen, Ausfälle einzelner Server abzufangen und Skalierung zu ermöglichen. Er ist also eine spezialisierte Funktion und ergibt nur Sinn, wenn mehrere Server vorhanden sind. Themen wie Session Persistence (Anfragen eines Clients zur selben Instanz) gehören hierher. In der Praxis bringen Reverse Proxies oft Load-Balancing mit, weshalb beide Begriffe verschwimmen.

API Gateway. Ein API Gateway ist ein einzelner Eintrittspunkt für viele APIs (typisch in Microservice-Landschaften). Es erledigt API-spezifische Logik:

• Authentifizierung und Zugriffskontrolle
• Rate Limiting beziehungsweise Throttling und Quotas
• Routing nach Pfad sowie Request-Composition
• Protokoll- und Format-Transformation

Ein Reverse Proxy leitet im Kern nur weiter, ein API Gateway versteht und steuert die API-Semantik. Es ist damit eine fachlich erweiterte Form des Reverse Proxy.

Service Mesh. Ein Service Mesh adressiert den Ost-West-Verkehr, also die Kommunikation der Services untereinander, nicht den Nord-Süd-Verkehr von außen. Es zieht die Kommunikationslogik aus den Services heraus in eine Infrastrukturschicht: ein Sidecar-Proxy pro Service-Instanz (zum Beispiel Envoy in Istio) fängt allen Ein- und Ausgangsverkehr ab (Data Plane), gesteuert von einer Control Plane. Funktionen sind mTLS-Verschlüsselung, Traffic-Management (etwa Canary-Deployments), zentrale Policy-Durchsetzung und Observability. Neuere Ansätze (Istio Ambient) ersetzen Sidecars durch Node-Level-Proxies.

WAF (Web Application Firewall). Eine WAF filtert bösartige Web-Requests auf Anwendungsebene (Layer 7). Sie blockiert oder begrenzt Angriffsmuster wie SQL-Injection oder Cross-Site-Scripting (XSS) und kann nach IP, HTTP-Headern, Body oder URI filtern; oft kommen Layer-7-DDoS-Schutz und Bot-Management dazu. Eine WAF entscheidet anhand von Sicherheitsregeln, nicht anhand von Last oder API-Logik.

Überschneidungen. Load Balancer und API Gateway sind in der Regel auch Reverse Proxies. Reverse Proxies übernehmen häufig Load-Balancing und werden zunehmend Einfügepunkt für WAF-Funktionen. Service Mesh wiederum bringt Load-Balancing, Policy und mTLS mit, jedoch intern zwischen Services. Faustregel: Reverse Proxy = weiterleiten, Load Balancer = verteilen, API Gateway = API-Logik am Rand, Service Mesh = Service-zu-Service-Verkehr, WAF = Angriffe filtern.

Client
  -> WAF            (filtert SQLi/XSS, Bots, L7-DDoS)
  -> Reverse Proxy / Load Balancer  (TLS, verteilt Last)
  -> API Gateway    (AuthN, Rate Limit, Routing, Transform)
  -> Service A --[mTLS via Sidecar]-- Service B   (Service Mesh, Ost-West)

Typische Schichtung von außen nach innen

API Gateway vs. API Management: Durchsetzungsebene und Plattform

Die Begriffe werden oft synonym verwendet, beschreiben aber zwei verschiedene Ebenen. Ein API Gateway ist eine Laufzeit-Komponente, ein API Management ist die übergreifende Plattform, in die das Gateway eingebettet ist.

Das API Gateway sitzt im Anfragepfad zwischen Clients und Backend-Diensten und bildet einen einzigen Eintrittspunkt. Zur Laufzeit übernimmt es vor allem:

• Routing und Aggregation von Anfragen an die passenden Backend-Services
• Authentifizierung und Autorisierung (z. B. OAuth 2.0, OpenID Connect, API-Keys)
• Rate Limiting, Caching, Protokoll-Transformation
• Erzeugen von Logs und Telemetrie für Observability

Architektonisch trennt ein Gateway typischerweise eine Control Plane (Konfiguration, Policies, Routing-Regeln) von einer Data Plane, die den Verkehr in Echtzeit verarbeitet und die Policies durchsetzt.

API Management ist dagegen der gesamte Prozess, APIs zu erstellen, zu veröffentlichen und zu betreiben, inklusive Zugriffskontrolle, Nutzungsmessung und ggf. Monetarisierung. Laut IBM kombiniert eine API-Management-Plattform mehrere Bausteine:

• ein Gateway, das Anfragen und Sicherheit zur Laufzeit verarbeitet
• ein Developer-Portal mit API-Katalog, Dokumentation und Onboarding/Keys
• ein Reporting- bzw. Analytics-System für Nutzungsdaten
• Lifecycle-Management, das eine API von der Erstellung bis zur Stilllegung samt Versionierung begleitet

Die zentrale Beziehung: Das Gateway ist die Durchsetzungsebene des API Managements. Eine zentrale Control Plane setzt Richtlinien und Routing-Regeln fest, und das Gateway setzt genau diese Regeln, Verschlüsselung und Authentifizierung pro Anfrage durch und routet dynamisch zum Backend.

Praktische Faustregel für Entscheider: Wer nur Routing, Security und Lastschutz vor wenigen Services braucht, kommt mit einem Gateway aus. Sobald viele APIs über Teams hinweg veröffentlicht, versioniert, dokumentiert und gegenüber internen, Partner- oder externen Konsumenten abgerechnet werden sollen (laut IBM verwalten sehr große Unternehmen mit mindestens 10 Mrd. USD Jahresumsatz im Schnitt rund 1.400 APIs, gestützt auf einen f5-Bericht von 2024), ist eine API-Management-Plattform die passende Ebene, das Gateway bleibt darin der Laufzeit-Baustein.

API Management (Plattform)
├─ Developer-Portal   (Katalog, Doku, Key-Onboarding)
├─ Lifecycle/Versionierung
├─ Analytics/Reporting
└─ API Gateway (Laufzeit / Durchsetzung)
     ├─ Routing & Aggregation
     ├─ Auth (OAuth2/OIDC, API-Keys)
     └─ Rate Limiting, Caching

Das Gateway als Laufzeit-Baustein innerhalb der API-Management-Plattform.

Self-hosted und souveräne Gateways: volle Kontrolle über den eigenen API-Verkehr

Ein API Gateway sitzt im Kontrollpunkt zwischen Clients und Backends: Es terminiert Authentifizierung, erzwingt Rate Limits, routet Anfragen und sammelt Analytics. Damit fließt praktisch der gesamte API-Verkehr inklusive Payloads und Metadaten durch diese Komponente. Wer hier ein verwaltetes SaaS eines Drittanbieters einsetzt, gibt einen Teil dieser Kontrolle aus der Hand. Für digitale Souveränität ist deshalb entscheidend, ob das Gateway quelloffen und selbst betreibbar ist.

Die wesentlichen Argumente für ein selbst gehostetes, quelloffenes Gateway:

• Volle Datenkontrolle: API-Traffic, Payloads und Metadaten verlassen die eigene Infrastruktur nicht und werden nicht an einen externen Betreiber weitergereicht.
• EU-Hosting nach eigener Wahl: Der Betrieb erfolgt on-premises, in einer EU-Cloud oder auf Kubernetes, je nach eigenen Compliance-Anforderungen.
• Kein Vendor-Lock-in: Quelloffener Code und deklarative Konfiguration lassen sich migrieren und unabhängig vom Hersteller weiterbetreiben.
• Auditierbarkeit: Offener Quellcode ist nachvollziehbar und prüfbar, statt einer Blackbox als Service zu vertrauen.

Zwei verbreitete, quelloffene und self-hostbare Beispiele:

• Tyk Gateway: in Go geschriebenes Open-Source-Gateway, das REST, GraphQL, TCP und gRPC unterstützt. Es kommt ohne Feature-Lockout (batteries included) mit Auth, Rate Limiting, Quotas und Analytics. Tyk läuft nativ auf Kubernetes über den Tyk Kubernetes Operator und lässt sich als Self-Managed-Variante per Docker bzw. Docker Compose selbst betreiben.
• Kong Gateway: laut Hersteller das meistverbreitete Open-Source-API-Gateway, basierend auf einer NGINX-Engine. Es ist deployment-agnostisch und kann on-premises, in jeder Cloud, auf Kubernetes oder serverless betrieben werden, mit oder ohne Datenbank, und lässt sich per deklarativer Konfiguration über CI/CD-Pipelines verwalten.

Wichtig für die Bewertung: Bei beiden Anbietern ist das Kern-Gateway quelloffen, während erweiterte Management-, Dashboard- und Portal-Funktionen teils Enterprise- oder SaaS-Editionen (etwa Kong Konnect oder Tyk Cloud) vorbehalten sind. Für maximale Souveränität ist daher zu prüfen, welche Funktionen tatsächlich in der self-managed Open-Source-Variante enthalten sind.

git clone https://github.com/TykTechnologies/tyk-gateway-docker
cd tyk-gateway-docker
docker-compose up -d   # Tyk Gateway + Redis lokal, kein externer Dienst

Tyk Gateway laut Projekt-README per Docker Compose selbst betreiben

Häufige Fragen

Quellen

• What is Amazon API Gateway? Amazon Web Services, 2024
• What Is an API Gateway? F5 / NGINX, 2024
• About API Gateway Google Cloud, 2024
• What is an API Gateway? Kong, 2023
• What does an API gateway do? Red Hat, 2024
• API1:2023 Broken Object Level Authorization (BOLA) OWASP, 2023
• Tyk Gateway (Quellcode, Go) Tyk Technologies
• Tyk Lizenz (MPL 2.0) Tyk Technologies
• Tyk Components (Gateway, Dashboard, Portal) Tyk, Dokumentation
• Use API gateways in microservices Microsoft Azure Architecture Center
• Backends for Frontends pattern Microsoft Azure Architecture Center
• What Is a Reverse Proxy? NGINX (F5)
• What Is a Load Balancer? NGINX (F5)
• What is a service mesh? Red Hat
• AWS WAF - Web Application Firewall Amazon Web Services
• Amazon API Gateway Amazon Web Services
• What is an API gateway? IBM
• What is API management? IBM
• What is an API Gateway? Tyk
• Kong Gateway: The world's most adopted open source API gateway Kong Inc.