Was ist ein API Gateway und wie funktioniert es?

In diesem Artikel erfährst du, was ein API Gateway ist, welche Probleme es löst und wie es in der Praxis funktioniert.

Wer benötigt ein API Gateway?

Bei einer kleinen Anzahl von APIs, wenigen Clients und unkritischen Anwendungsfällen wird in der Regel kein API Gateway benötigt. In einfachen Umgebungen können Clients direkt mit Backend-Services kommunizieren, ohne zusätzliche Infrastruktur einzuführen.

Figure 1: Direkte Kommunikation zwischen API-Client und Backend-Service

Mit der Zeit steigt typischerweise die Anzahl der APIs und Clients. Die Anforderungen werden komplexer, und APIs müssen möglicherweise externen Partnern über das öffentliche Internet bereitgestellt werden.

Figure 2: Mit der Anzahl der APIs nimmt auch die Komplexität zu.

Der Betrieb von APIs wird dadurch anspruchsvoller. Sicherheit, Monitoring und Zugriffskontrolle müssen in jedem Backend-Service umgesetzt werden. Diese Services laufen häufig auf unterschiedlichen Plattformen und nutzen verschiedene Mechanismen für Authentifizierung und Logging. Das führt zu doppeltem Aufwand, uneinheitlichen Sicherheitsregeln und höherem Betriebsaufwand.

Ab einem gewisssen Punkt lohnt sich der Einsatz eines API Gateways. Es führt eine zentrale Kontrollschicht ein, die übergreifende Aufgaben wie Sicherheit, Traffic Control und Monitoring übernimmt.

Statt diese Aufgaben in jedem einzelnen Service umzusetzen, verwaltet das API Gateway sie an einer Stelle. Das vereinfacht die Backend-Services und sorgt für einheitliches Verhalten über alle APIs hinweg.

Figure 3: API Gateway als zentrale Kontrollschicht für Sicherheit, Routing und Monitoring

Wie ein API Gateway funktioniert

Ein API Gateway ist der zentrale Einstiegspunkt für die Kommunikation zwischen Clients und Backend-Services. Damit das funktioniert, muss der gesamte API-Traffic über das Gateway laufen.

Dazu wird das API Gateway vor den Backend-Services platziert. Statt ein Backend direkt aufzurufen, werden Clients so konfiguriert, dass sie ihre Requests an das Gateway senden. Anstatt sich mit einem internen Host wie server7.local zu verbinden, ruft ein Client beispielsweise einen Endpunkt wie api.predic8.de auf. Eine eigene Subdomain wie api ist dafür gängige Praxis.

Das API Gateway arbeitet als Proxy, also als Stellvertreter, und stellt nach außen dieselbe Schnittstelle wie das Backend bereit. Aus Sicht des Clients gibt es keinen sichtbaren Unterschied. Das Gateway nimmt Anfragen entgegen, wendet Richtlinien wie Authentifizierung an und leitet sie an die passende Anwendung weiter.

Figure 4: API Gateway als HTTP-Proxy zwischen Client und Backend-Services

Damit wirklich der gesamte Traffic über das Gateway läuft, muss der direkte Zugriff auf Backend-Services eingeschränkt werden. Das kann über Netzwerk-Routing, Firewall-Regeln oder dadurch geschehen, dass nur das Gateway auf die Backend-Services zugreifen darf. Ein verbreiteter Ansatz ist es, Vertrauen zwischen Gateway und Backend-Services über mutual TLS (mTLS) herzustellen.

Im Unterschied zu Netzwerk-Gateways, die auf der IP-Schicht arbeiten, arbeitet ein API Gateway auf der Anwendungsschicht des Netzwerk-Stacks.

Figure 5: Ein API Gateway arbeitet in der Anwendungsschicht

Anstatt nur Netzwerkpakete weiterzuleiten, versteht das API Gateway Anwendungsprotokolle wie HTTP. Dadurch kann es Routing-Entscheidungen anhand von HTTP-Methoden wie GET und POST oder anhand von Request-Pfaden treffen.

Eine Anfrage an den Pfad /products kann zum Beispiel an einen Service geroutet werden, während ein Request an /orders an einen anderen Service weitergeleitet wird.

Auch Funktionen wie Zugriffskontrolle, Rate Limiting und Monitoring werden auf der Anwendungsschicht umgesetzt.

Um interne APIs sicher über das öffentliche Internet bereitzustellen, kann ein API Gateway in einer demilitarisierten Zone (DMZ) betrieben werden, also in einem Netzwerksegment zwischen externen und internen Systemen.

Typischerweise gibt es zwischen diesen Netzwerken kein direktes Routing. Die gesamte Kommunikation muss über ein Application-Layer-Gateway wie ein API Gateway laufen.

Das Gateway besitzt zwei Netzwerk-Interfaces: eines zur externen Seite und eines zu den internen Services. Es routet Traffic zwischen beiden Seiten und wendet dabei Sicherheitskontrollen an. Jede Seite kann zu einem anderen Netzwerk gehören.

Figure 6: API Gateway in der DMZ zwischen externem und internem Netzwerk

Viele dieser Konzepte gelten auch für HTTP Reverse Proxies. Ein API Gateway baut auf dieser Grundlage auf. API Gateways erweitern Reverse Proxies jedoch um API-spezifische Fähigkeiten.

Sie verstehen Technologien wie OpenAPI, JSON, OAuth2 und JSON Web Tokens (JWT). Dadurch können sie Requests validieren, Sicherheitsregeln durchsetzen und API-Traffic auf einer höheren Ebene steuern.

Diese Fähigkeiten werden typischerweise als Komponenten im Request- und Response-Fluss umgesetzt. Je nach Produkt heißen sie Interceptor, Plugin oder Policy.

Aufgaben eines API Gateways

Backend-Services implementieren die Geschäftslogik. Ein API Gateway ergänzt Cross-Cutting Concerns, die helfen, APIs sicher und effizient in größerem Maßstab zu betreiben.

Routing: Weiterleitung von Requests an den passenden Backend-Service.
Sicherheit: Authentifizierung von Clients, z.B. mit OAuth2 oder API Keys, und Autorisierung des Zugriffs. Schutz vor Angriffen auf JSON, XML und GraphQL. Validierung von Requests gegen OpenAPI, GraphQL-Schemas, WSDL oder XML Schema.
Betrieb: Sammeln von Metriken und Logs, um die API-Nutzung zu verstehen. Einstiegspunkt für Distributed Tracing.
Integration: Transformation von Nachrichten, um unterschiedliche Formate und Protokolle zu verbinden.
Legacy-Integration: Bereitstellung bestehender Systeme über moderne Schnittstellen, zum Beispiel durch eine REST-Fassade für einen Legacy-Webservice.
Load Balancing: Verteilung des Traffics auf mehrere Backend-Instanzen.
Accounting und Billing: Nachverfolgung der API-Nutzung und Zuordnung von Kosten, zum Beispiel bei teuren KI- oder externen Service-Aufrufen.

Einige dieser Aufgaben überschneiden sich mit anderen Infrastrukturkomponenten wie Web Application Firewalls und Load Balancern. Das API Gateway stellt jedoch eine einheitliche, API-fokussierte Schicht bereit, die diese Fähigkeiten kombiniert.

Incoming, Outgoing und interne API Gateways

API Gateways werden häufig an den Grenzen zwischen Netzwerken platziert. Je nach Position lassen sie sich als Incoming, Outgoing oder interne Gateways einordnen. Ein einzelnes Gateway kann alle drei Rollen erfüllen. In größeren Architekturen werden sie jedoch oft getrennt betrieben.

Incoming API Gateways stellen APIs für externe Clients wie Kunden oder Partner über das öffentliche Internet bereit. Dadurch wächst die Angriffsfläche. Das Gateway setzt deshalb Sicherheitsmaßnahmen wie Authentifizierung, Autorisierung und Traffic Control durch.

Outgoing API Gateways verwalten Aufrufe von internen Systemen an externe APIs. Sie steuern, welche Anwendungen externe Services nutzen dürfen, welche Operationen erlaubt sind und welche Daten die Organisation verlassen dürfen. Darüber hinaus können sie eine Allow List genehmigter APIs durchsetzen und den Zugriff auf nicht genehmigte Endpunkte blockieren. Ausgehender Traffic wird als Risiko häufig unterschätzt: Sensible Daten können offengelegt werden, und kompromittierte externe Services könnten schädliche Antworten einschleusen.

Interne API Gateways routen Traffic innerhalb der Organisation. Sie werden für Netzwerksegmentierung, die Durchsetzung von Richtlinien, Systemintegration und die Nachverfolgung der API-Nutzung verwendet.

Arten von API Gateways

Früher nutzten Organisationen häufig ein einzelnes, zentrales API Gateway für alle Anwendungsfälle. Die meisten Gateway-Produkte sind flexibel und können mehrere Aufgaben übernehmen. Mit der Zeit zeigte sich jedoch, dass nicht alle Anforderungen durch ein einzelnes Gateway optimal abgedeckt werden. Deshalb sind spezialisierte API Gateways für unterschiedliche Einsatzbereiche entstanden.

Art	Beschreibung
Microgateway	Leichtgewichtiges API Gateway, das für den Betrieb vieler Instanzen mit geringem Ressourcenverbrauch ausgelegt ist. In Container-Umgebungen wie Kubernetes ist es üblich, ein Gateway pro Anwendung oder Service zu deployen.
Legacy Integration Gateway	Konzentriert sich auf die Integration von Legacy-Systemen und Protokollen. Bietet typischerweise starke Unterstützung für XML-Technologien wie XSLT und XPath sowie für Webservice-Standards wie SOAP und WSDL.
AI Gateway	Verwaltet Traffic rund um künstliche Intelligenz und große Sprachmodelle. Hilft, Kosten zu kontrollieren, Fähigkeiten einzuschränken und Interaktionen zu steuern, zum Beispiel bei der Nutzung von Model Context Protocols (MCP).
Cloud Gateway	Steuert API-Traffic zu cloudbasierten Services. Große Cloud-Anbieter wie Amazon Web Services, Microsoft Azure und Google Cloud bieten integrierte API Gateways an. Unabhängige Lösungen können ebenfalls eingesetzt werden.
Edge Gateway	Global verteiltes Gateway, das API-Zugriff mit niedriger Latenz in der Nähe der Nutzer bereitstellt. Verbessert die User Experience und ist besonders nützlich für latenzkritische Anwendungen und Echtzeitanwendungen.

Zusammenfassung

Im API Management dienen API Gateways als Kontrollpunkte an den Grenzen von Systemen und Netzwerken. Sie sorgen dafür, dass definierte Richtlinien eingehalten werden.

Aufgaben wie Sicherheit, Routing und Monitoring werden zentral gelöst. Dadurch können sich Backend-Services auf die Geschäftslogik konzentrieren.

Weitere Details und praktische Beispiele findest du in unserem API Gateway Handbook:

Von: Thomas Bayer
Datum: 30. Mai 2026