Kong vs. APISIX vs. Envoy Gateway: 0 € bis 50.000 $ [2026]

Wer heute ein API-Gateway auswählt, trifft eine Sicherheitsentscheidung und keine reine Infrastrukturfrage mehr. Laut Akamai stieg die Zahl der API-Angriffe pro Unternehmen 2025 auf durchschnittlich 258, ein Sprung von 113 Prozent gegenüber 121 Angriffen im Jahr 2024. Gleichzeitig zeigen die drei relevantesten Open-Source-Gateways am Markt, Kong Gateway, Apache APISIX und Envoy Gateway, sehr unterschiedliche Antworten auf die Frage, wie viel Schutz, Tempo und Kontrolle ein Team tatsächlich bekommt. Dieser Vergleich stützt sich auf Benchmarks von Kong selbst, auf unabhängige Tests und auf CVE-Daten aus 2025 und 2026, dazu Praxisbeispiele von BMW bis Siemens. Stand der Daten: 11. September 2026.

Für Teams in Deutschland, Österreich und der Schweiz kommt eine zusätzliche Dringlichkeit hinzu. Mit dem neuen BSI-Gesetz zur NIS2-Umsetzung müssen deutlich mehr Unternehmen ihre API-Infrastruktur dokumentieren und Vorfälle melden, und auch die europäische DORA-Verordnung im Finanzsektor verlangt inzwischen belastbare Nachweise über die Sicherheit von Programmierschnittstellen. Ein Gateway ist in diesem Kontext nicht nur technisches Werkzeug, sondern liefert auch die Protokolle, die im Ernstfall gegenüber Aufsichtsbehörden vorgelegt werden müssen. Genau deshalb lohnt sich ein Blick, der über reine Performance-Zahlen hinausgeht und CVE-Historie, Lizenzmodell und dokumentierte Referenzkunden gleichberechtigt einbezieht.

Was ist ein API-Gateway und warum ist es eine Sicherheitsentscheidung

Ein API-Gateway sitzt zwischen Client und Backend und übernimmt Routing, Authentifizierung, Rate Limiting und oft auch Verschlüsselung. Genau dort entscheidet sich, ob eine kompromittierte API-Anfrage abgefangen wird oder ungehindert bis zur Datenbank durchdringt. Die drei hier verglichenen Projekte, Kong Gateway, Apache APISIX und Envoy Gateway, decken diese Aufgabe komplett quelloffen ab. Sie unterscheiden sich aber stark darin, wie Sicherheitsfunktionen konfiguriert werden, wie oft Lücken auftauchen und wie schnell Patches erscheinen. Diese drei wurden bewusst ausgewählt, weil sie zusammen die drei dominanten Architekturmodelle abdecken: ein firmengeführtes Produkt mit kommerziellem Unterbau, ein Foundation-Projekt unter Apache-Governance und ein Service-Mesh-natives Projekt aus dem CNCF-Umfeld, während proprietäre Cloud-Gateways wie AWS API Gateway oder Azure API Management bewusst außen vor bleiben, weil sie kein vergleichbares Open-Source-Modell bieten.

Für Sicherheitsteams zählt an dieser Stelle nicht nur der reine Durchsatz. Ein Gateway, das unter Last einbricht, fällt bei einem DDoS-Angriff genau dann aus, wenn Schutz am wichtigsten wäre. Ein Gateway mit schwacher Plugin-Architektur öffnet dagegen die Tür für Fehlkonfigurationen, die laut Salt Security aktuell den größten Anteil realer API-Angriffe ausmachen. Die Wahl des Gateways bestimmt also direkt, wie groß die Angriffsfläche einer Organisation ausfällt, lange bevor der erste Endpoint überhaupt live geht. Hinzu kommt, dass ein Gateway-Wechsel selten isoliert passiert: Er berührt CI/CD-Pipelines, bestehende Monitoring-Verträge und oft auch vertragliche Zusagen gegenüber Kunden zu Verfügbarkeit und Reaktionszeit, weshalb die Entscheidung meist von mehreren Abteilungen gemeinsam getroffen werden sollte.

Alle drei Kandidaten laufen unter der Apache-2.0-Lizenz kostenlos und lassen sich selbst hosten. Der Unterschied liegt im Ökosystem drumherum: Kong verkauft eine kommerzielle Cloud-Plattform namens Konnect, Apache APISIX bleibt komplett unter dem Dach der Apache Software Foundation, und Envoy Gateway baut auf dem CNCF-Graduated-Projekt Envoy auf, ohne selbst eine eigene, separat gelistete CNCF-Reifestufe zu tragen.

Dieser Artikel vergleicht die drei Gateways entlang von sieben Dimensionen: technische Spezifikationen, gemessene Performance, eingebaute Sicherheitsfunktionen, dokumentierte Schwachstellen, Preise und Lizenzmodelle, reale Einsatzbeispiele sowie Betriebsaufwand samt Monitoring. Jede Dimension stützt sich auf öffentlich nachprüfbare Quellen, damit sich die Auswahl nicht auf Marketingversprechen verlassen muss.

Kong, Apache APISIX und Envoy Gateway im Kurzporträt

Kong Gateway

Kong Inc. entwickelt Kong Gateway seit 2015 und positioniert das Produkt heute als API- und KI-Konnektivitätsplattform. Der offene Kern bleibt gratis, während Kong Konnect als verwaltete Cloud-Variante zusätzliche Governance-Funktionen, Audit-Logs und Support verkauft. Am 24. August 2026 erschien Version 3.15.0.5, die aktuelle Enterprise-Linie. Kong veröffentlicht laut eigener Versionsrichtlinie seit März 2025 vier Minor-Releases pro Jahr, jeweils im März, Juni, September und Dezember. Jede Enterprise-Version bleibt laut derselben Richtlinie zwei Jahre lang unter vollem Support, bevor eine zwölfmonatige Sunset-Phase beginnt, ein Modell, das Planungssicherheit für Unternehmen mit langen Freigabezyklen schafft.

Apache APISIX

Apache APISIX gehört zur Apache Software Foundation und wird als dynamisches, hochperformantes API-Gateway vermarktet. Das Projekt arbeitet mit etcd als Konfigurationsspeicher und aktualisiert sich in einem dichten Takt: Am 20. August 2026 erschien Version 3.18.0 mit neuen KI-Sicherheitsplugins, darunter eine Integration von Lakera Guard zum Schutz von LLM-Traffic, sowie semantischem Response-Caching. Zwischen Februar und August 2026 veröffentlichte das Projekt vier Minor-Versionen, ein deutlich schnellerer Takt als bei Kong. Weil APISIX vollständig quelloffen bleibt, fehlt allerdings eine zentrale, herstellereigene Supportlinie, wie sie Kong mit Konnect anbietet. Wer Drittanbieter-Support möchte, wendet sich an Firmen wie API7.ai, die kommerzielle Dienstleistungen rund um den offenen Kern verkaufen, ohne selbst Eigentümer des Codes zu sein.

Envoy Gateway

Envoy Gateway baut auf dem Envoy-Proxy auf, der 2018 als drittes Projekt nach Kubernetes und Prometheus den CNCF-Graduated-Status erreichte. Envoy Gateway selbst erreichte im März 2024 General Availability und wird von mehreren Firmen gemeinsam getragen, darunter Tetrate und Bloomberg. Am 9. September 2026, also fast zeitgleich mit diesem Artikel, veröffentlichte das Projekt Version 1.8.0 mit neuen Funktionen im Traffic-Management und in der Sicherheit. Der jüngste der drei Kandidaten profitiert dabei von der langen Härtungsgeschichte des zugrunde liegenden Envoy-Proxys, der seit 2016 bei Lyft entstand und heute in tausenden Produktionsumgebungen als Service-Mesh-Datenebene läuft, etwa im Rahmen von Istio.

Technische Daten im Vergleich

Die folgende Tabelle fasst die zentralen technischen Eckdaten zusammen, so wie sie Anfang September 2026 öffentlich dokumentiert sind. Sie dient als schneller Referenzpunkt, bevor die einzelnen Kategorien im weiteren Verlauf des Artikels einzeln vertieft werden.

Kriterium	Kong Gateway	Apache APISIX	Envoy Gateway
Aktuelle Version (Stand 11.09.2026)	3.15.0.5 (24.08.2026)	3.18.0 (20.08.2026)	1.8.0 (09.09.2026)
Lizenz Open-Source-Kern	Apache 2.0	Apache 2.0	Apache 2.0
Trägerorganisation	Kong Inc.	Apache Software Foundation	Envoy-Projekt / Tetrate, Bloomberg u. a.
GitHub Stars (ca., Sept. 2026)	44.000	17.100	2.900
CNCF-Status	kein CNCF-Projekt	kein CNCF-Projekt (ASF-Governance)	Teil des Envoy-Ökosystems, Envoy selbst Graduated seit 2018
Konfigurationsmodell	Deklarativ (DB-less) oder Postgres	etcd-basiert	Kubernetes Gateway API
Deployment-Ziele	Standalone, Kubernetes, Hybrid	Standalone, Kubernetes, Docker	primär Kubernetes
mTLS	ja, nativ	ja, nativ	ja, nativ
JWT / OAuth2 / OIDC	ja, über Plugins	ja, inkl. LDAP-Auth-Plugin	ja, über SecurityPolicy-Ressourcen
Rate Limiting	nativ verfügbar	nativ verfügbar	nativ verfügbar
KI-Gateway-Funktionen	Kong AI Gateway (separates Modul)	Semantic Caching, Lakera Guard seit 3.18	Envoy AI Gateway (separates CNCF-nahes Projekt)
Release-Takt 2026	4 Minor-Releases/Jahr	ca. alle 6 bis 8 Wochen	unregelmäßig, mehrere Releases pro Jahr

Auffällig ist die Diskrepanz bei den GitHub-Stars: Kong bringt mit rund 44.000 Stars etwa das 2,6-Fache von APISIX und das 15-Fache von Envoy Gateway auf die Waage. Das sagt wenig über die tatsächliche Produktionsreife aus, zeigt aber, wie unterschiedlich sichtbar die drei Projekte in der breiten Entwickler-Community sind.

Beim Konfigurationsmodell zeigt sich der größte architektonische Unterschied. Kong arbeitet wahlweise datenbankfrei mit deklarativen YAML-Dateien oder mit einer Postgres-Datenbank im Hintergrund, was klassische GitOps-Workflows erleichtert. APISIX setzt zwingend auf etcd als verteilten Konfigurationsspeicher, was in bereits etcd-basierten Kubernetes-Umgebungen kaum zusätzlichen Aufwand verursacht, in reinen VM-Deployments aber eine zusätzliche Komponente einführt. Envoy Gateway wiederum verzichtet auf ein eigenes Konfigurationsformat und bildet Routing- sowie Sicherheitsregeln direkt als Kubernetes-Custom-Resources ab, was außerhalb von Kubernetes praktisch keine sinnvolle Betriebsoption lässt.

Performance-Benchmarks: Durchsatz und Latenz im Test

Kong veröffentlicht eigene, reproduzierbare Benchmarks über sein Open-Source-Testsuite. Eine Basis-Proxy-Konfiguration verarbeitet laut Kong bis zu 133.140,2 Anfragen pro Sekunde bei 3,21 Millisekunden Latenz im 95. Perzentil. Aktiviert man Rate Limiting und Key-Authentifizierung über 100 Routen und 100 Consumer, sinkt der Wert auf 96.259,7 Anfragen pro Sekunde, bleibt damit aber hoch genug für die meisten produktiven Deployments.

Ein unabhängiger Leitfaden zu Open-Source-API-Gateways aus dem Jahr 2025 vergleicht Kong und Envoy Proxy direkt im Durchsatz und kommt zu einem knappen Ergebnis zugunsten von Envoy: Unter Spitzenlast erreicht Envoy dort mehr als 350.000 Anfragen pro Sekunde, Kong mehr als 300.000. Bei der Latenz-Overhead-Messung derselben Quelle liegt APISIX mit 0,8 Millisekunden zusätzlicher Latenz auf eine Baseline von 5 Millisekunden leicht vor Envoy, das mit 1,0 Millisekunden Overhead rund 20 Prozent Performance-Einbußen gegenüber der ungeschützten Baseline zeigt.

Für KI-Workloads liefert Kong eine dritte, spezifischere Zahl: Im Vergleich der Kong-AI-Gateway-Datenebene gegen Portkey OSS 1.9.19 und LiteLLM, alle mit identischen 12 CPU-Kernen ausgestattet, war Kong Konnect laut Kong-Engineering-Blog 228 Prozent schneller als Portkey und 859 Prozent schneller als LiteLLM, bei gleichzeitig 65 beziehungsweise 86 Prozent niedrigerer Latenz. Envoy AI Gateway wiederum, ein separates Projekt auf Envoy-Basis, fügte in einem Tetrate-Benchmark vom Dezember 2025 zwischen 160 und 390 Millisekunden zusätzliche Latenz gegenüber direkten, ungeproxten Aufrufen eines Model-Context-Protocol-Servers hinzu, lag damit aber nur rund 0,2 Millisekunden hinter einer konkurrierenden Gateway-Implementierung.

Messwert	Kong Gateway	Apache APISIX	Envoy (Gateway/Proxy)	Quelle
Peak-Durchsatz (synthetisch)	über 300.000 RPS	nicht in RPS publiziert	über 350.000 RPS	Benchhub-Leitfaden 2025
Basis-Proxy, Kong-eigener Test	133.140 RPS, 3,21 ms p95	–	–	Kong Engineering Blog
Mit Rate Limiting + Key-Auth	96.260 RPS	–	–	Kong Engineering Blog
Gateway-Overhead (Baseline 5 ms)	–	+0,8 ms (ca. 16 %)	+1,0 ms (ca. 20 %)	Benchhub-Leitfaden 2025
AI-Gateway-Durchsatz vs. Portkey/LiteLLM	+228 % / +859 %	nicht getestet	nicht Teil dieses Tests	Kong AI Gateway Benchmark

Wichtig für die Einordnung: Kongs eigene Zahlen stammen aus firmeneigenen Tests und lassen sich nicht eins zu eins mit unabhängigen Messungen vergleichen, weil Hardware, Testaufbau und Lastprofil variieren. Für belastbare Aussagen im eigenen Betrieb bleibt ein eigener Lasttest mit realistischem Traffic-Muster unverzichtbar. Kong veröffentlicht sein Test-Setup als Open-Source-Testsuite, sodass sich die Werte zumindest grundsätzlich nachstellen lassen, während APISIX seine eigenen Lasttests direkt in der Projektdokumentation beschreibt, allerdings ohne vollständig standardisierte Hardware-Angaben.

Sicherheitsfunktionen im Detail

Alle drei Gateways bieten mTLS, JWT-Validierung und Rate Limiting als Grundausstattung. Die Unterschiede zeigen sich im Detail der Plugin-Architektur. Apache APISIX bündelt in Version 3.18.0 nun explizit KI-Sicherheitsfunktionen: eine Lakera-Guard-Integration filtert schädliche Prompts, dazu kommen exaktes, semantisches und streamendes Response-Caching für LLM-Traffic sowie semantisches Modell-Routing. Für klassische APIs bringt APISIX zusätzlich ein LDAP-Auth-Plugin mit, das in Unternehmensumgebungen mit Active Directory gut funktioniert.

Envoy Gateway setzt Sicherheitsrichtlinien über eine eigene SecurityPolicy-Kubernetes-Ressource um und profitiert vom jahrelang gehärteten Envoy-Proxy-Kern darunter. Die enge Kopplung an die Kubernetes Gateway API macht Sicherheitskonfiguration deklarativ und versionierbar, verlangt im Gegenzug aber tiefere Kubernetes-Kenntnisse im Team. Envoy Gateway veröffentlichte im März 2026 die Sicherheitsversionen 1.6.2 und 1.5.7, ein Beleg für einen aktiven Patch-Prozess.

Kong Gateway verlässt sich auf sein breites Plugin-Ökosystem für Authentifizierung, darunter OAuth2, OpenID Connect, JWT und Key-Auth, kombiniert mit rollenbasierter Zugriffskontrolle in der Enterprise-Version. Die Enterprise-Schicht ergänzt Audit-Logs und Single Sign-on, Funktionen, die in regulierten Branchen wie der Automobilindustrie oder im Finanzsektor häufig zur Pflicht werden. Der offene Kern deckt diese Governance-Ebene dagegen nicht ab.

Für DDoS-Abwehr und Bot-Erkennung bieten alle drei Projekte Grundfunktionen, aber keine vollwertige Web Application Firewall im klassischen Sinn. Wer einen dedizierten WAF-Schutz vor OWASP-Top-10-Angriffen wie Injection oder Cross-Site-Scripting benötigt, kombiniert typischerweise eines der drei Gateways mit einer vorgeschalteten WAF-Lösung, statt sich allein auf die Gateway-eigenen Filter zu verlassen. Das gilt besonders für öffentlich erreichbare APIs mit hohem Transaktionsvolumen.

Beim Rate Limiting selbst unterscheiden sich die Algorithmen im Detail. Kong implementiert unter anderem einen Sliding-Window-Zähler, der Lastspitzen sanfter abfedert als ein starres Zeitfenster. APISIX bietet mit dem limit-req-Plugin ein vergleichbares Verhalten und erlaubt zusätzlich eine Kombination aus mehreren Limit-Typen pro Route, etwa gleichzeitig nach IP-Adresse und nach API-Key. Envoy Gateway delegiert komplexere Rate-Limiting-Szenarien häufig an einen externen Envoy-Ratelimit-Service, was mehr Flexibilität bei verteilten, clusterweiten Limits bietet, aber auch eine zusätzliche Komponente im Betrieb bedeutet.

CVEs und Sicherheitslücken 2025/2026

Ein Gateway, das den gesamten API-Traffic bündelt, wird selbst zum attraktiven Ziel. Die CVE-Historie der letzten anderthalb Jahre zeigt das deutlich, vor allem bei Apache APISIX, das mit seinem dichten Release-Takt auch häufiger Schwachstellen offenlegt. Für die Bewertung zählt dabei nicht nur die Zahl der Einträge, sondern auch, wie schnell ein Projekt auf eine gemeldete Lücke reagiert und wie transparent es den Fund kommuniziert, statt ihn stillschweigend in einem Minor-Release zu verstecken.

CVE	Produkt	Schweregrad	Beschreibung	Betroffene Versionen
CVE-2025-24030	Envoy Gateway	nicht öffentlich beziffert	Sicherheitslücke, behoben ab Version 1.2.6	< 1.2.6
CVE-2026-22771	Envoy Gateway	8,8 (Hoch)	Schwachstelle im Gateway-Kern, gemeldet April 2026	diverse 1.x-Linien
CVE-2025-62232	Apache APISIX	Mittel	Klartext-Zugangsdaten im Logfile bei Basic-Auth-Plugin auf INFO/DEBUG-Level	1.0 bis 3.14
CVE-2026-31923	Apache APISIX	7,5 (Hoch)	Klartextübertragung im OIDC-Plugin	0.7 bis 3.15.0
CVE-2026-31924	Apache APISIX	Mittel	Klartext-HTTP-Datenübertragung in Logs	< 3.16.0
CVE-2026-63041	Apache APISIX	Hoch	Unsanitisierte Consumer-Label-Header ermöglichen Rechteausweitung	3.11.0 bis 3.17.0
CVE-2026-39999	Apache APISIX	9,1 (Kritisch)	gemeldet 22.06.2026	mehrere 2.x/3.x-Linien

Laut stack.watch verzeichnete Apache APISIX allein 2026 drei Schwachstellen mit einem durchschnittlichen CVSS-Wert von 7,3. Fast alle drei APISIX-Lücken drehen sich um dasselbe Muster: sensible Daten landen im Klartext in Logs oder werden bei der OIDC-Authentifizierung unverschlüsselt übertragen, obwohl die externe Verbindung selbst per TLS abgesichert ist. Das zeigt, dass die Kern-Proxy-Engine der drei Gateways relativ stabil bleibt, während Plugins für Logging, Auth und KI-Traffic die häufigste Fehlerquelle darstellen. Wer eines dieser Gateways betreibt, sollte Patch-Zyklen daher genauso ernst nehmen wie bei jeder anderen kritischen Infrastruktur-Komponente.

Bei der Reaktionsgeschwindigkeit unterscheiden sich die Projekte in der Praxis kaum: Sowohl Apache APISIX als auch Envoy Gateway lieferten in den dokumentierten Fällen Patches innerhalb weniger Tage bis Wochen nach der Entdeckung, meist gebündelt mit dem nächsten regulären Minor-Release. Für Kong Gateway sind im untersuchten Zeitraum keine vergleichbar schweren CVEs öffentlich dokumentiert, was teils am geschlosseneren Enterprise-Modell liegen dürfte, teils schlicht Zufall im Beobachtungsfenster sein kann. Ein Fehlen öffentlicher CVEs beweist für sich genommen keine höhere Sicherheit, sondern kann auch bedeuten, dass Schwachstellen seltener öffentlich gemeldet werden.

Preise und Lizenzmodelle

Der Open-Source-Kern aller drei Gateways kostet nichts. Die Unterschiede beginnen erst, sobald ein Team verwaltete Infrastruktur, Enterprise-Support oder Governance-Funktionen braucht. Gerade für Finanzdienstleister und öffentliche Auftraggeber in Deutschland, die Ausschreibungen mit festen Budgetobergrenzen planen, macht der Unterschied zwischen einer öffentlich kalkulierbaren Preisliste und einem individuellen Angebot auf Anfrage einen spürbaren Unterschied im Beschaffungsprozess.

Modell	Kong	Apache APISIX	Envoy Gateway
Open-Source-Kern	0 € (Apache 2.0)	0 € (Apache 2.0)	0 € (Apache 2.0)
Kostenlose Testphase	Konnect Free Trial, 0 $ für 30 Tage	entfällt, kein herstellereigenes SaaS	entfällt, kein herstellereigenes SaaS
Einstiegstarif Managed-Gateway	Serverless: 25 $/Monat je Gateway (bis 5)	Support über Drittanbieter wie API7.ai, Preise auf Anfrage	Support über Drittanbieter wie Tetrate, Preise auf Anfrage
Hybrid-Gateway	200 $/Monat je Gateway (bis 2)	–	–
Dedicated-Cloud-Gateway	500 $/Monat je Gateway (bis 2), plus 0,15 $/GB Bandbreite	–	–
Inkludierte Requests	1 Million/Monat je Gateway, danach 20 bis 200 $ je weitere Million	abhängig vom Supportvertrag	abhängig vom Supportvertrag
Enterprise-Jahresvertrag	individuell, laut Marktanalysen ab rund 30.000 bis 50.000 $/Jahr, bei großen Deployments 150.000 bis 300.000+ $/Jahr	keine öffentliche Preisliste	keine öffentliche Preisliste

Kong ist damit das einzige der drei Projekte mit einer öffentlich einsehbaren, gestaffelten Preisliste, nachzulesen auf der offiziellen Kong-Preisseite. Das schafft Planbarkeit, treibt aber bei wachsendem Traffic auch die laufenden Kosten spürbar nach oben. APISIX und Envoy Gateway bleiben in der Kostenkontrolle des eigenen Betriebsteams, verlangen dafür aber auch mehr internes Know-how für Betrieb, Monitoring und Patch-Management.

Die Gesamtbetriebskosten hängen deshalb stark davon ab, wie ein Team die eigene Zeit bewertet. Ein selbst gehostetes APISIX- oder Envoy-Gateway-Cluster kostet zwar keine Lizenzgebühr, bindet dafür aber Engineering-Kapazität für Updates, Monitoring und Incident Response, die bei Kong Enterprise zumindest teilweise im Vertrag enthalten ist. Für ein kleines Team ohne dediziertes Plattform-Engineering kann die scheinbar teurere Kong-Enterprise-Lösung unterm Strich günstiger ausfallen als die eigene Betreuung eines kostenlosen Gateways, sobald man die Personalkosten mit einrechnet.

Praxisbeispiele aus Deutschland und Europa

Für den DACH-Markt zählt weniger die globale Nutzerzahl als die Frage, wer aus der Region bereits produktiv auf welches Gateway setzt. Hier zeigt sich ein klares Bild zugunsten von Kong bei deutschen Großkonzernen, was vor allem an der frühen Marktpräsenz und am gezielten Vertrieb in die Automobil- und Industriebranche liegt, zwei Sektoren mit traditionell hohem IT-Budget und langen Beschaffungszyklen.

• BMW steuert über Kong Gateway mehr als 24 Millionen vernetzte Fahrzeuge über 140 dezentrale Gateway-Instanzen. Die Migration dauerte laut Kong-Fallstudie sieben Wochen, senkte die Antwortzeit von 200 auf 95 Millisekunden, und die Zahl jährlicher Releases stieg von drei auf 24, bei angeblich null Ausfallzeit während der Umstellung.
• Mercedes-Benz Connectivity Services nutzt Kong Gateway für Rate Limiting im Rahmen seiner vernetzten Fahrzeugdienste in Europa.
• Siemens verbindet über Kong Kafka-Event-Streams mit API-Endpunkten und nutzt das Gateway als zentrale Governance-Schicht für Legacy- und moderne Systeme gleichermaßen.
• GfK SE setzte Kong ein, um Legacy-Systeme schrittweise auf ein modernes Sicherheitskonzept mit OAuth2 und OpenID Connect zu migrieren.
• Das Copernicus-Erdbeobachtungsprogramm der EU nutzt Apache APISIX als Ingress-Controller für seine Referenzsystem-Infrastruktur.
• Airwallex, ein Fintech mit Europa-Geschäft, erreicht über APISIX bei aktivem Multi-Tenant-Rate-Limiting und Authentifizierung 99 Prozent seiner Antwortzeiten innerhalb von 23 Millisekunden, über mehr als 50 Währungen und 130 Länder hinweg.
• Laut BuiltWith-Trends laufen aktuell rund 129.474 deutsche Websites auf Servern mit Envoy als zugrundeliegender Proxy-Technologie, ein Indikator für die breite, aber oft unsichtbare Verbreitung von Envoy in europäischer Infrastruktur.
• Unity Group, ein europäischer Systemintegrator mit Sitz in Polen, entschied sich laut eigenem Erfahrungsbericht für APISIX wegen der nativen Unterstützung der Kubernetes Gateway API und der im eigenen Test gemessenen Performance-Vorteile gegenüber dem vorherigen Gateway.
• Lenovo migrierte von einer zentralisierten Gateway-Architektur zu Apache APISIX, nachdem wiederholte Ausfälle des alten, zentralen Gateways sämtliche Services gleichzeitig lahmgelegt hatten.

Envoy AI Gateway, ein eigenständiges, CNCF-nahes Projekt auf Envoy-Basis, zählt laut Tetrate mittlerweile mehr als 1.500 GitHub-Stars und über 95 Mitwirkende, mit Bloomberg, Tencent Cloud und Nutanix als genannten Anwendern. AWS empfiehlt es zudem als bevorzugtes KI-Gateway für Amazon EKS. Für klassische Envoy-Gateway-Einsätze außerhalb dieses KI-Zweigs finden sich dagegen kaum öffentlich benannte europäische Referenzkunden, was die insgesamt jüngere Marktposition des Projekts widerspiegelt.

GitHub-Community, CNCF-Status und Ökosystem

Kong führt mit rund 44.000 GitHub-Stars deutlich vor Apache APISIX mit etwa 17.100 und Envoy Gateway mit knapp 2.900 Stars (Stand September 2026). Sterne allein sagen nichts über Produktionsreife, doch sie korrelieren meist mit der Größe der Community, die Bugs meldet, Plugins schreibt und bei Problemen im öffentlichen Issue-Tracker hilft.

Beim formalen Governance-Status liegt der eigentliche Envoy-Proxy-Kern vorn: Er erreichte am 28. November 2018 den CNCF-Graduated-Status und war damit erst das dritte Projekt überhaupt nach Kubernetes und Prometheus, das diese höchste Reifestufe der Cloud Native Computing Foundation erreichte. Envoy Gateway selbst taucht in der offiziellen CNCF-Projektliste jedoch nicht als eigenständiges, separat graduiertes Projekt auf, sondern gilt als Teil des breiteren Envoy-Ökosystems. Apache APISIX wiederum unterliegt der Governance der Apache Software Foundation und damit einem eigenen, unabhängigen Open-Source-Modell ohne CNCF-Bezug. Kong Gateway schließlich bleibt vollständig firmengetragen, mit Kong Inc. als alleinigem Steuermann für Roadmap und Release-Zyklen.

Für Einkaufsentscheidungen in regulierten Branchen macht dieser Unterschied etwas aus: Ein CNCF-Graduated-Kernprojekt wie Envoy durchläuft strengere Foundation-Audits zu Sicherheit, Lizenzhygiene und Governance-Transparenz als ein rein firmengetriebenes Produkt. Das reduziert zumindest formal das Risiko einer plötzlichen Lizenzänderung, wie sie andere Infrastrukturprojekte in den letzten Jahren erlebt haben.

Für das Ökosystem an Plugins und Integrationen zählt zusätzlich die Größe des Marktplatzes. Kong verweist auf sein umfangreiches Angebot an vorgefertigten und community-gepflegten Plugins, was gerade für Standardanforderungen wie Logging-Anbindungen an Splunk oder Datadog Entwicklungszeit spart. APISIX bietet ein vergleichbares, wenn auch kleineres Plugin-Verzeichnis, während bei Envoy Gateway ein Großteil der Erweiterungen über Kubernetes-native Custom-Resources statt über klassische Plugins erfolgt, was die Lernkurve für Teams ohne Kubernetes-Erfahrung zusätzlich erhöht.

Wie gefährdet sind APIs wirklich? Aktuelle Bedrohungsdaten

Die Zahlen aus aktuellen Branchenberichten zeichnen ein ungewöhnlich einheitliches Bild. Laut dem Salt-Security-Report für das erste Quartal 2025 erlebten 99 Prozent der befragten Organisationen innerhalb von zwölf Monaten mindestens ein API-Sicherheitsproblem. Als größte Einzelursachen nennt der Report Schwachstellen, die APIs für Angriffe wie Injection oder Broken Object Level Authorization öffnen (37 Prozent), gefolgt von der Offenlegung sensibler Daten (34 Prozent) und schwacher Authentifizierung (29 Prozent).

Der Folgereport für die zweite Jahreshälfte 2025, basierend auf 386 befragten API-Verantwortlichen, präzisiert das Bild: Ein Drittel der Unternehmen (33 Prozent) erlebte im vergangenen Jahr konkret einen API-bezogenen Sicherheitsvorfall, die Hälfte verschob deswegen die Einführung neuer Anwendungen. 96 Prozent aller beobachteten Angriffsversuche kamen dabei von bereits authentifizierten Quellen, ein Hinweis darauf, dass klassische Perimeter-Firewalls hier oft ins Leere laufen. Fehlkonfiguration, in der OWASP-API-Top-10-Systematik als API8 geführt, steckte laut Salt Security hinter 78 Prozent aller registrierten Angriffsversuche.

Wallarm liefert ergänzende Zahlen speziell zum Zusammenspiel von KI und APIs: In Agentic-AI-Projekten waren 65 Prozent aller beobachteten Sicherheitsprobleme API-bezogen (1.858 von 2.869 Fällen), und 98,9 Prozent aller KI-bezogenen CVEs hingen direkt mit API-Sicherheit zusammen. Von den 59 Schwachstellen, die CISA zwischen April und Juni 2025 in seinen KEV-Katalog aufnahm, betrafen 13, also 22 Prozent, direkt APIs. Akamai wiederum beobachtete, dass 2025 bei 61,18 Prozent aller API-Angriffe unautorisierte Workflows oder ungewöhnliches Verhalten eine Rolle spielten, ein starker Anstieg gegenüber 30,01 Prozent im Vorjahr. Diese Zahlen erklären, warum die Wahl des Gateways heute Teil jeder Sicherheitsstrategie sein muss und nicht länger eine reine Performance-Frage der Infrastrukturabteilung ist.

Besonders schnell wächst das Risiko rund um KI-Traffic selbst. Wallarms ThreatStats-Report für das dritte Quartal 2025 registrierte einen Anstieg API-bezogener Schwachstellen von 20 Prozent im Quartalsvergleich, während Risiken rund um das Model Context Protocol, über das viele KI-Agenten heute mit Werkzeugen und APIs kommunizieren, im selben Zeitraum um 270 Prozent zunahmen. Für Gateways, die wie APISIX oder Kong AI Gateway aktiv KI-Traffic terminieren, verschiebt das die Priorität: Klassische REST-Sicherheit reicht nicht mehr aus, wenn ein wachsender Anteil des Traffics aus autonomen KI-Agenten statt aus menschlich gesteuerten Anwendungen stammt.

Für welchen Anwendungsfall welches Gateway?

• Regulierte Konzerne mit Compliance-Pflichten (Automobil, Finanzsektor, Behörden mit NIS2-Bezug) fahren mit Kong Enterprise am sichersten, weil Audit-Logs, RBAC und vertragliche SLAs bereits mitgeliefert werden, wie das BMW-Beispiel zeigt.
• Kubernetes-native Plattformteams, die bereits auf die standardisierte Kubernetes Gateway API setzen, profitieren von Envoy Gateway, weil sich Routing- und Sicherheitsregeln direkt als Kubernetes-Ressourcen versionieren lassen.
• Fintech- und Zahlungsplattformen mit Multi-Region-Anforderungen finden in Apache APISIX, wie bei Airwallex demonstriert, eine Lösung mit niedriger Latenz und feingranularem, dynamischem Routing über etcd.
• Budgetbewusste Start-ups und kleine Teams sollten auf den kostenlosen Kern von APISIX oder Kong OSS setzen, da beide ohne Lizenzkosten produktionsreif einsetzbar sind, solange kein Enterprise-Support nötig ist.
• Teams mit LLM- und KI-Workloads profitieren aktuell am stärksten von Apache APISIX 3.18 mit seinem semantischen Caching und der Lakera-Guard-Integration, oder alternativ vom spezialisierten Kong AI Gateway für höheren reinen Durchsatz.
• Organisationen mit bestehender Envoy- oder Istio-Service-Mesh-Infrastruktur sparen sich mit Envoy Gateway eine zweite Proxy-Technologie im Stack, weil beide Systeme dieselbe Datenebene nutzen.
• Behörden und Betreiber kritischer Infrastruktur mit NIS2-Meldepflichten sollten die vertraglich fixierten SLAs und den dokumentierten Patch-Prozess von Kong Enterprise gegenüber dem community-getragenen Support von APISIX und Envoy Gateway abwägen.
• Agenturen und Systemintegratoren, die für mehrere Kunden parallel Gateways betreiben, profitieren von Kongs deklarativem DB-less-Modus, weil sich Konfigurationen als versionierte Dateien pro Mandant getrennt verwalten lassen, ohne für jeden Kunden eine eigene Datenbank zu pflegen.

Monitoring und Betriebsaufwand im Alltag

Ein Gateway, das im Ernstfall keine verwertbaren Metriken liefert, verzögert die Reaktion auf einen laufenden Angriff um wertvolle Minuten. Alle drei Kandidaten unterstützen Prometheus-kompatible Metrik-Endpunkte nativ, was sich gut in bestehende Grafana-Dashboards oder ein Setup wie Wazuh einbinden lässt. Kong ergänzt in der Enterprise-Version zusätzlich ein eigenes Analytics-Dashboard innerhalb von Konnect, das Latenz, Fehlerraten und Traffic-Anomalien pro Service visualisiert, ohne dass ein Team ein eigenes Observability-Stack aufbauen muss.

Apache APISIX bringt ebenfalls native Prometheus-Instrumentierung mit und lässt sich zusätzlich an OpenTelemetry für verteiltes Tracing anschließen, was bei komplexen Microservice-Landschaften mit vielen Hops hilft, den genauen Ursprung einer fehlerhaften Anfrage zu finden. Envoy Gateway profitiert an dieser Stelle am stärksten vom Envoy-Unterbau: Envoy gilt seit Jahren als Referenzimplementierung für detaillierte L7-Metriken und liefert von Haus aus feingranulare Daten zu Verbindungsstatus, Retry-Verhalten und Circuit-Breaker-Ereignissen, die andere Proxys oft erst über Zusatzmodule nachrüsten.

Für den laufenden Betrieb bedeutet das: Teams ohne bestehende Observability-Infrastruktur sparen mit Kong Enterprise Einrichtungszeit, weil das Dashboard bereits mitgeliefert wird. Teams mit einem etablierten Prometheus- und Grafana-Stack, wie er in vielen deutschen Mittelstandsunternehmen und Konzernen bereits läuft, ziehen aus der offenen Instrumentierung von APISIX und Envoy Gateway keinen Nachteil, sondern integrieren beide Projekte in der Regel innerhalb weniger Stunden.

Migrationsleitfaden: Vom Legacy-Gateway zum modernen API-Gateway

Ein Gateway-Wechsel im laufenden Betrieb verträgt keine Hauruck-Aktion. BMW brauchte für seine Kong-Migration laut eigener Fallstudie sieben Wochen, verteilt über 140 Gateway-Instanzen, und erreichte dabei null Ausfallzeit. Der folgende Ablauf orientiert sich an diesem und vergleichbaren Praxisberichten.

1. Bestandsaufnahme aller aktiven Endpunkte, Auth-Methoden und Rate-Limit-Regeln im Altsystem erstellen.
2. Ein unkritisches, klar abgegrenztes Service-Cluster für das Pilotprojekt auswählen.
3. Zielkonfiguration im neuen Gateway parallel zum Altsystem aufbauen, ohne produktiven Traffic umzuleiten.
4. Canary-Rollout starten: zunächst 1 bis 5 Prozent des Traffics über das neue Gateway leiten und Fehlerraten sowie Latenz engmaschig beobachten.
5. Monitoring und Alerting auf die neue Gateway-Metrik-Schnittstelle umstellen, bevor der Traffic-Anteil weiter steigt.
6. Traffic-Anteil schrittweise über mehrere Tage oder Wochen erhöhen, mit fest definierten Rollback-Kriterien für jede Stufe.
7. Nach vollständigem Cutover das Altsystem für eine Übergangsfrist im Standby-Modus belassen, bevor es endgültig abgeschaltet wird.

Für den ersten Testschritt hilft eine minimale, deklarative Routendefinition, wie sie sich in ähnlicher Form für alle drei Gateways umsetzen lässt. Das folgende Beispiel zeigt eine einfache APISIX-Routenkonfiguration mit aktiviertem Rate Limiting als Ausgangspunkt für den Piloten.

{
  "uri": "/api/v1/orders",
  "upstream": {
    "type": "roundrobin",
    "nodes": { "orders-backend:8080": 1 }
  },
  "plugins": {
    "limit-req": {
      "rate": 200,
      "burst": 50,
      "key_type": "var",
      "key": "remote_addr"
    },
    "jwt-auth": {}
  }
}

Wichtig bei jeder Migration: Die Sicherheitsregeln des Altsystems, etwa IP-Whitelists oder spezielle CORS-Ausnahmen, gehen bei einer reinen Funktionsmigration leicht verloren. Ein separates Audit der Auth-Regeln vor dem Cutover verhindert, dass mit dem neuen Gateway auch neue Lücken entstehen.

Für den Rollback-Fall empfiehlt sich ein DNS- oder Load-Balancer-Schalter, der sich innerhalb von Sekunden zurückdrehen lässt, statt einer erneuten Code-Deployment-Pipeline. Nur so lässt sich im Ernstfall, etwa bei einer unerwarteten Latenzspitze mitten im Cutover, sofort auf das bewährte Altsystem zurückwechseln, ohne dass Kunden den Ausfall überhaupt bemerken.

Vor- und Nachteile im Überblick

Nach Technik, Preis und Praxisbeispielen bündelt die folgende Übersicht die wichtigsten Argumente noch einmal kompakt für die interne Entscheidungsvorlage.

Kong Gateway

• Vorteil: öffentliche, gestaffelte Preisliste und etablierter Enterprise-Support
• Vorteil: nachgewiesene Großkunden-Referenzen in Deutschland (BMW, Mercedes-Benz, Siemens)
• Vorteil: größtes Plugin-Ökosystem der drei Kandidaten
• Nachteil: Governance-Funktionen wie Audit-Logs bleiben der kostenpflichtigen Enterprise-Version vorbehalten
• Nachteil: laufende Kosten bei Konnect steigen mit Traffic-Volumen spürbar

Apache APISIX

• Vorteil: kompletter Funktionsumfang, inklusive KI-Sicherheitsplugins, bleibt kostenlos
• Vorteil: sehr kurzer Release-Takt bringt neue Funktionen schnell in Produktion
• Vorteil: niedriger Latenz-Overhead im unabhängigen Benchmark
• Nachteil: höchste Zahl dokumentierter CVEs der drei Projekte in 2025/2026
• Nachteil: kein herstellereigener Enterprise-Support, nur Drittanbieter

Envoy Gateway

• Vorteil: baut auf dem CNCF-Graduated-Kern Envoy auf, mit entsprechend strengem Governance-Prozess
• Vorteil: höchster gemessener Peak-Durchsatz im Drittanbieter-Benchmark
• Vorteil: native Integration in die Kubernetes Gateway API
• Nachteil: kleinste Community und wenigste öffentlich benannte europäische Referenzkunden
• Nachteil: steilere Lernkurve außerhalb reiner Kubernetes-Umgebungen

Das Urteil: Welches API-Gateway gewinnt 2026?

Es gibt keinen einzelnen Gewinner, aber eine klare Datenlage für jede Situation. Wer Enterprise-Governance, Vertragssicherheit und einen belastbaren Track Record bei deutschen Großkonzernen sucht, kommt an Kong kaum vorbei. Der Preis dafür sind Lizenzkosten, die bei wachsendem Traffic schnell in den sechsstelligen Jahresbereich klettern können.

Wer dagegen maximale Funktionalität ohne Lizenzkosten will und ein eigenes Team für Patch-Management mitbringt, fährt mit Apache APISIX gut, muss aber die mit 7,3 durchschnittlichem CVSS-Wert überdurchschnittliche CVE-Historie aus 2026 aktiv im Blick behalten. Für Kubernetes-native Architekturen mit Fokus auf rohen Durchsatz und Governance nach CNCF-Standard bleibt Envoy Gateway die technisch konsequenteste Wahl, allerdings mit der kleinsten Community und den wenigsten öffentlich dokumentierten Praxisfällen in Europa. Die Benchmark-Zahlen sprechen bei Spitzenlast leicht für Envoy, bei KI-Workloads mit vorgegebener Hardware für Kong, und beim Preis-Leistungs-Verhältnis für APISIX. Am Ende entscheidet weniger die reine Rohleistung als die Frage, welches Risiko ein Team bewusst eingehen will: Lizenzkosten, Patch-Aufwand oder eine kleinere Community.

Angesichts von 258 API-Angriffen pro Unternehmen im Jahr 2025 und einer Fehlkonfigurationsquote von 78 Prozent aller Angriffsversuche lohnt sich eine nüchterne Faustregel für die Praxis: Wer die eigene Betriebsreife realistisch einschätzt und ein Gateway wählt, das zum vorhandenen Team passt, senkt das Risiko stärker als jede zusätzliche Performance-Optimierung. Ein perfekt konfiguriertes, aber selten gepatchtes APISIX-Cluster ist riskanter als ein solide betriebenes, wenn auch teureres Kong-Enterprise-Setup, und umgekehrt gilt dasselbe für Teams, die Lizenzkosten ohne echten Bedarf zahlen, statt das Budget in eigenes Know-how zu investieren.

Häufig gestellte Fragen

Ist Kong Gateway komplett kostenlos nutzbar?

Der Kong-Gateway-Kern steht unter Apache 2.0 und kostet dauerhaft nichts. Kostenpflichtig werden nur die verwaltete Konnect-Cloud-Plattform und die Enterprise-Funktionen wie Audit-Logs, SSO und vertraglicher Support.

Welches Gateway ist am schnellsten?

Bei synthetischer Spitzenlast liegt Envoy im unabhängigen Benchhub-Vergleich mit über 350.000 Anfragen pro Sekunde knapp vor Kong mit über 300.000. Bei aktivierten Sicherheits-Plugins und realistischerer Konfiguration meldet Kong in eigenen Tests rund 96.000 Anfragen pro Sekunde. Die tatsächliche Reihenfolge hängt stark vom eigenen Traffic-Profil ab.

Unterstützen alle drei Gateways mTLS und OAuth2?

Ja. Kong, Apache APISIX und Envoy Gateway bringen mTLS und OAuth2/OIDC-Unterstützung jeweils nativ oder über offizielle Plugins beziehungsweise Ressourcen mit.

Ist Envoy Gateway ein eigenständiges CNCF-Projekt?

Nein. Der zugrundeliegende Envoy-Proxy erreichte 2018 den CNCF-Graduated-Status, doch Envoy Gateway selbst führt die CNCF-Projektliste nicht als separat graduiertes Projekt, sondern als Teil des Envoy-Ökosystems.

Welche deutschen Unternehmen setzen auf diese Gateways?

BMW, Mercedes-Benz Connectivity Services, Siemens und GfK SE nutzen laut öffentlichen Kong-Fallstudien Kong Gateway. Für Apache APISIX und Envoy Gateway sind aktuell keine vergleichbar prominenten, öffentlich benannten deutschen Referenzkunden dokumentiert.

Wie sicher sind Open-Source-API-Gateways angesichts der CVEs 2025/2026?

Alle drei Projekte veröffentlichen regelmäßig Sicherheitspatches. Apache APISIX weist die höchste Zahl dokumentierter Schwachstellen auf, meist im Zusammenhang mit Logging- und Auth-Plugins statt im Kern-Proxy. Entscheidend ist in der Praxis weniger die reine CVE-Zahl als die Geschwindigkeit, mit der ein Team Patches tatsächlich einspielt.

Kann ich zwischen den drei Gateways migrieren, ohne API-Verträge zu ändern?

Ja, solange die externen API-Schnittstellen (Pfade, Methoden, Antwortformate) unverändert bleiben. Intern unterscheiden sich Konfigurationssprache und Plugin-Namen jedoch deutlich zwischen den drei Gateways, weshalb sich Regelwerke nicht automatisch übertragen lassen und manuell nachgebaut werden müssen.

Welches Gateway eignet sich am besten für KI- und LLM-Traffic?

Apache APISIX bringt seit Version 3.18.0 dedizierte KI-Sicherheitsfunktionen wie Lakera-Guard-Integration und semantisches Caching mit. Kong AI Gateway punktet dagegen mit höherem gemessenem Durchsatz gegenüber Alternativen wie Portkey OSS und LiteLLM. Envoy AI Gateway wiederum eignet sich vor allem für Teams, die bereits auf Envoy als Service-Mesh-Basis setzen.

Lässt sich der Gateway-Betrieb ohne eigenes Kubernetes-Team stemmen?

Bei Kong und Apache APISIX ja, beide laufen auch als Standalone-Deployment auf klassischen virtuellen Maschinen. Envoy Gateway setzt dagegen zwingend auf die Kubernetes Gateway API voraus und eignet sich damit praktisch nur für Teams, die bereits produktiv mit Kubernetes arbeiten.

Was kostet der Wechsel von einem Cloud-eigenen API-Gateway wie AWS API Gateway zu einem der drei Open-Source-Projekte?

Die Softwarekosten sinken durch den Wechsel meist deutlich, da alle drei Projekte quelloffen sind, während Cloud-eigene Gateways nutzungsbasiert abgerechnet werden. Dem stehen jedoch einmalige Migrationskosten für Konfiguration, Tests und Schulung gegenüber, die je nach Anzahl der Endpunkte und vorhandenem Kubernetes-Know-how stark variieren und sich pauschal nicht seriös beziffern lassen.