API Gateway oder Application Load Balancer? Was braucht eine normale API auf AWS?

Soll ein HTTP-Service auf AWS öffentlich erreichbar sein, landet man schnell bei einer scheinbar einfachen Frage: API Gateway oder Application Load Balancer?

Meine Voreinstellung ist nicht automatisch API Gateway, nur weil „API" im Namen steht. Läuft hinter dem Endpunkt ein normaler HTTP-Service auf ECS, EKS oder EC2, und brauche ich im Wesentlichen Routing, TLS und Lastverteilung, starte ich mit einem Application Load Balancer. API Gateway nehme ich, wenn die API selbst zum Produkt oder zur Kontrollgrenze wird: wenn ich nicht nur HTTP weiterleiten will, sondern Autorisierung, Drosselung, Nutzungsregeln, API-Schlüssel, Prüfungen oder verschiedene Backends bewusst auf dieser Schicht brauche.

Beide können HTTP. Die wichtigere Frage lautet deshalb: Brauche ich einen Load Balancer vor meiner Anwendung oder eine API-Management-Schicht vor meinen Clients?

Ein ALB ist mehr als ein Verteiler

Der Application Load Balancer wird manchmal dargestellt, als könne er nur Verkehr gleichmäßig auf Server verteilen. Das Bild ist ziemlich unvollständig. Ein ALB verteilt HTTP und HTTPS anhand von Listener-Regeln, also nach Host, Pfad, Header oder Methode, auf verschiedene Target Groups:

api.example.com/orders/*    -> Orders Service
api.example.com/users/*     -> User Service
admin.example.com/*         -> Admin Service

Ziele können ECS-Tasks, EC2-Instanzen, IP-Adressen oder Lambda-Funktionen sein. Auch Authentifizierung liegt nicht außerhalb seiner Möglichkeiten: Ein ALB kann Benutzer über OpenID Connect oder Amazon Cognito anmelden, bevor eine Anfrage die Anwendung erreicht.

Für viele klassische Anwendungen ist damit sehr viel vorhanden. Ich beginne Architektur gern mit der kleinsten ausreichenden Schicht, und wenn Internet, HTTPS, ALB und ECS-Service reichen, will ich erklären können, warum davor noch eine API-Schicht stehen soll.

API Gateway löst ein anderes Problem

API Gateway kann Anfragen ebenfalls an Backends weiterleiten, aber das ist nur ein Teil seines Modells. Es behandelt eine API als verwaltete Schnittstelle, mit Funktionen für Autorisierung, Drosselung, Anfrageverarbeitung, API-Management und Integrationen in andere AWS-Dienste.

Dabei unterscheidet AWS zwei Arten. HTTP APIs sind die schlankere, günstigere Variante mit JWT-, IAM- und Lambda-Authorizern und Drosselung je Stage und Route. REST APIs bieten das volle API-Management: API-Schlüssel, Nutzungspläne mit Limits je Client, Anfrageprüfung gegen ein Schema, Umformung von Anfragen und Antworten und eine direkte Anbindung an AWS WAF.

Selbst „API Gateway" ist also keine einzelne Architekturentscheidung. Bevor ich zwischen ALB und API Gateway wähle, muss ich wissen, welche Gateway-Funktionen ich tatsächlich brauche, und das entscheidet oft schon, welche der beiden Arten es wäre.

Für einen normalen ECS-Service reicht ein ALB

Nehmen wir ein Backend aus einer Go-API auf ECS Fargate, PostgreSQL und Redis, erreichbar unter https://api.example.com. Der Service authentifiziert seine Benutzer selbst und skaliert horizontal. Gebraucht werden TLS, Gesundheitschecks, Routing, Lastverteilung und Deployments ohne Ausfall. Meine erste Architektur wäre:

Route 53
   |
  ALB
   |
ECS Service
   |
Fargate Tasks

Was würde API Gateway hier zusätzlich lösen? „Es ist eine API" reicht mir als Antwort nicht. Ich hätte eine weitere Komponente im Anfragepfad, weitere Konfiguration und eine weitere Stelle, die ich bei Fehlern und Kosten verstehen muss. Eine zusätzliche Schicht muss eine zusätzliche Aufgabe übernehmen, sonst lasse ich sie weg.

Ein ALB passt genau zu dieser Art Service: Er läuft dauerhaft, hat einen HTTP-Port und einen Gesundheitscheck, und mehrere Tasks sollen Verkehr bekommen. Das gilt für eine Go-API genauso wie für eine PHP-Anwendung, ein Java-Backend oder einen Node-Service. Dazu kommt ein praktischer Punkt, der in Vergleichen oft fehlt: API Gateway begrenzt eine Anfrage auf 10 MB Nutzlast und die Wartezeit auf das Backend auf rund 30 Sekunden. Große Uploads, lange Berichte oder Streaming passen besser hinter einen ALB, der diese Grenzen so nicht setzt.

Warum der Service darunter auf ECS Fargate läuft und nicht auf Kubernetes, steht in ECS Fargate oder Kubernetes.

Wenn die Schnittstelle selbst Regeln bekommt

Jetzt ändern wir das Beispiel. Dieselbe API nutzen 50 externe Kunden. Einer darf 100 Anfragen pro Sekunde senden, ein anderer 1.000. Es soll Nutzungspläne geben, vielleicht API-Schlüssel, vielleicht unterschiedliche Autorisierungsmodelle, und Anfragen sollen begrenzt werden, bevor sie die Anwendung erreichen.

Jetzt ist die API nicht mehr nur ein HTTP-Eingang, sondern ein Produkt mit Regeln. Die Architektur kann dann so aussehen, oder, je nach Backend, mit Lambda, einem AWS-Dienst oder einer privaten Integration über einen VPC Link statt des ALB:

Clients
   |
API Gateway
   |
  ALB
   |
ECS Services

Jetzt bezahlt API Gateway seinen Platz im Anfragepfad. Es übernimmt Verantwortung, die ich sonst in mehreren Anwendungen selbst bauen müsste.

Die Drosselung ist dafür das beste Beispiel, weil hinter dem Wort zwei verschiedene Probleme stecken. Will ich meine Infrastruktur vor Überlast schützen, habe ich viele Ebenen: Auto Scaling, Limits in der Anwendung, WAF-Regeln, Backpressure, Queues, bewusst gesetzte Kapazitätsgrenzen. Dafür brauche ich nicht automatisch API Gateway. Etwas anderes ist eine Regel je Kunde:

/orders:  höchstens X Anfragen pro Sekunde      Schutz des Backends

Kunde A:  100 Anfragen pro Sekunde               Teil des Produkts
Kunde B:  500 Anfragen pro Sekunde
Kunde C:  2.000 Anfragen pro Sekunde

Die erste Zeile kann eine HTTP API je Route abbilden. Die zweite braucht Nutzungspläne, und die gibt es nur bei REST APIs. Sind solche Regeln Teil meines API-Produkts, kommt API Gateway für mich sehr schnell in Betracht.

Authentifizierung allein entscheidet nicht

Früher wäre Authentifizierung ein klareres Argument für API Gateway gewesen. Heute unterstützen HTTP APIs JWT-, IAM- und Lambda-Authorizer, REST APIs noch weitergehende Modelle, und gleichzeitig meldet ein ALB Benutzer über OIDC oder Cognito an. „Wir brauchen Login" ist deshalb kein ausreichendes Argument.

Ich frage stattdessen: Welche Art von Identität schützen wir? Bei einer internen Webanwendung hinter einem zentralen OIDC-Anbieter kann die Anmeldung am ALB sehr elegant sein. Bei einer öffentlichen Entwickler-API mit Tokens, verschiedenen Clients, Scopes, Nutzungsregeln und einem klaren Lebenszyklus passt API Gateway deutlich besser. Wieder entscheidet nicht das einzelne Feature, sondern der Kontext.

Lambda und verschiedene Backends

Anders sieht es aus, wenn hinter der API gar kein einzelner HTTP-Service steht. POST /invoice führt zu einer Lambda-Funktion, GET /report zu einer anderen, und POST /events schreibt direkt in einen AWS-Dienst oder geht an ein privates Backend:

                          /invoice -> Lambda
                        /
Client -> API Gateway ----- /users   -> Service im VPC
                        \
                          /events  -> AWS-Integration

Hier tut API Gateway mehr als ein Load Balancer. Es bildet die API als eigene Architekturkomponente vor mehreren unterschiedlichen Backends ab, und das ist ein starker Anwendungsfall.

„Serverless" allein reicht mir trotzdem nicht als Begründung, denn auch ein ALB kann Lambda-Funktionen als Ziel verwenden. Bei APIs, die im Kern aus Lambda-Funktionen bestehen, prüfe ich trotzdem zuerst API Gateway, weil API-Modell, Autorisierung, Routing und Integration dort meist natürlicher zusammenpassen. Featurelisten allein entscheiden das nicht, denn beide können teilweise dasselbe. Die Frage ist: Welches Betriebsmodell bildet meine Architektur natürlicher ab?

Routing und Umformung sind keine Gründe für sich

Drei Pfade wie /api/users/*, /api/orders/* und /api/payments/* auf drei Services zu verteilen, kann ein ALB sehr gut. Ist Routing mein einziges Problem, bleibe ich beim ALB. API Gateway kommt dazu, wenn die Routing-Schicht zugleich Dinge besitzen soll wie API-spezifische Autorisierung, Drosselung je Client, Nutzungsregeln, API-Schlüssel, Anfrageprüfung, einen eigenen Lebenszyklus oder verschiedene Arten von Backends.

Mit der Umformung von Anfragen und Antworten bin ich vorsichtiger. Braucht mein Gateway zehn Umformungen, weil das Backend eine schlechte Schnittstelle hat, habe ich das Problem vielleicht nur verschoben, und es entstehen drei Modelle statt einem: das des Clients, das des Gateways und das des Backends. Manchmal ist genau das richtig, etwa wenn eine bestehende Legacy-API nicht geändert werden kann und eine stabile öffentliche Schnittstelle davorliegen soll. Dann wirkt das Gateway als Anti-Corruption Layer. Bei einem neuen System prüfe ich zuerst, ob die API selbst sauberer werden kann. Ein Gateway übernimmt Infrastruktur- und API-Verantwortung, keine Geschäftslogik.

Wie eine stabile Schnittstelle vor ein Altsystem kommt, ohne dass die Logik ins Gateway wandert, steht in Eine API vor den Monolithen setzen.

Kosten und Bestand entscheiden mit

API Gateway und ALB haben unterschiedliche Preismodelle: API Gateway rechnet je Anfrage ab, der ALB je Stunde und nach verbrauchten Kapazitätseinheiten. Welches günstiger ist, hängt deshalb vom Lastprofil ab, von der Zahl der Anfragen, der Datenmenge, der Dauer der Verbindungen, dem Gateway-Typ und den genutzten Funktionen. Regeln wie „ALB ist immer billiger" oder „API Gateway ist für kleine APIs günstiger" können für ein konkretes Profil stimmen, als allgemeine Regel sind sie mir zu einfach. Ich rechne mit der realen Last: Anfragen im Monat, durchschnittliche Nutzlast, Spitzen pro Sekunde, Zahl der Services, und ob es schon einen ALB gibt.

Der letzte Punkt verändert die Entscheidung am stärksten. Läuft bereits ein ALB vor den Services A, B und C, und kommt Service D dazu, lautet die Frage nicht mehr „ALB oder API Gateway bei null?". Routing, TLS, Monitoring, Security Groups, Deployment und Betriebserfahrung sind schon da, und der Aufwand für einen weiteren Service ist gering. Vorhandene Infrastruktur ist Teil der Entscheidung.

Umgekehrt gilt dasselbe. Hat eine Organisation bereits eine zentrale API-Plattform mit eigenen Domains, Authorizern, Logging, Richtlinien, Entwicklerportal und Nutzungsplänen, wäre ein einzelner ALB-Endpunkt für einen neuen Service der Sonderweg, auch wenn er für sich betrachtet einfacher ist. Ich optimiere deshalb nicht darauf, welcher Dienst theoretisch simpler ist, sondern darauf, welche Lösung in dieser Organisation die geringste zusätzliche Komplexität erzeugt.

Außen und innen, und nicht jede Schicht vor jede

Eine öffentliche API für Kunden oder Partner hat andere Anforderungen als eine interne Schnittstelle. Außen interessieren mich Kontingente, Client-Identität, Scopes, Versionierung, Dokumentation, Missbrauchsschutz, Onboarding und Nutzungspläne. Innen eher Latenz, Verfügbarkeit, Netzwerk, Service Discovery, Authentifizierung zwischen Workloads und Observability. Dieselbe Organisation kann deshalb sinnvoll beides nutzen:

Externe Clients
      |
 API Gateway
      |
     ALB
      |
+-----+-----+
|           |
Orders   Payments

Intern sprechen die Services direkt oder über einen internen Load Balancer. Das ist keine Doppelung, es sind zwei Grenzen mit unterschiedlichen Aufgaben.

Dieselbe Trennung zwischen öffentlicher und interner Grenze trägt auch die Protokollwahl: REST oder gRPC für Backend-Services?

Was ich nicht tue: API Gateway reflexhaft vor jeden ALB setzen. Eine Standardarchitektur aus CloudFront, API Gateway, ALB und ECS, dazu WAF, ist schnell gebaut, und jede einzelne Komponente lässt sich begründen. Das Problem entsteht, wenn niemand mehr fragt, welche davon diese Anwendung braucht. Jede Netzwerkschicht bringt Konfiguration, Kosten, Limits, Logs, Fehlerquellen, Latenz und Abhängigkeiten im Deployment mit. Die einzelne Schicht mag günstig und zuverlässig sein, das Ganze kann trotzdem unnötig kompliziert werden.

Ich arbeite solche Entwürfe deshalb rückwärts ab: Welche Verantwortung besitzt diese Schicht? Kann ich das für eine Komponente nicht beantworten, nehme ich sie gedanklich heraus und prüfe, was dann fehlt. Fehlt nichts, war sie wahrscheinlich nicht nötig.

Wann ich womit starte

Mit einem ALB, wenn ein klassischer HTTP-Service auf ECS, EKS oder EC2 dahinterliegt, ich vor allem TLS, Routing, Gesundheitschecks und Lastverteilung brauche, die Anwendung ihre API-Regeln selbst besitzt, bereits ein ALB läuft und die API Teil der Anwendung ist und kein eigenes Produkt. Typisch: ein SaaS-Backend in Go auf ECS Fargate, zehn Millionen Anfragen im Monat, JWT-Prüfung im Service, ein öffentliches Frontend.

Mit API Gateway, wenn externe Kunden oder Partner die API nutzen, Autorisierung zentral durchgesetzt werden soll, Drosselung oder Nutzungsregeln Teil des Produkts sind, verschiedene Backends unter einer API zusammenlaufen, Lambda oder AWS-Integrationen eine große Rolle spielen, die Schnittstelle einen eigenen Lebenszyklus hat, Prüfung oder Umformung bewusst am Gateway stattfinden soll, oder eine zentrale API-Plattform schon existiert. Typisch: eine Partner-API mit hundert externen Integrationen, unterschiedlichen Limits, mehreren Backends aus Lambda und ECS und eigener Versionierung.

Die Frage, mit der ich anfange

Wenn jemand sagt „Vor eine API gehört API Gateway", frage ich: Welche Aufgabe übernimmt API Gateway hier, die nicht schon sinnvoll gelöst ist? Lautet die Antwort „Limits je Client, Autorisierung und eine einheitliche externe API vor mehreren Backends", gut, dann löst es ein Problem. Lautet sie „weil es eine API ist", reicht mir das nicht. Genauso wenig ist „ALB ist einfacher" ein Grund, wenn wir eigentlich ein API-Management-Problem haben. Die Architektur soll das Problem sichtbar machen.

Für eine normale HTTP-Anwendung auf ECS oder EC2 beginne ich deshalb meistens mit einem Application Load Balancer. Er übernimmt genau die Aufgaben, die ich dort brauche: TLS, Routing, Gesundheitschecks, Lastverteilung und die Anbindung an die laufenden Services. API Gateway setze ich davor oder stattdessen, wenn die Schnittstelle selbst Verantwortung bekommt: wenn ich Clients verwalten, API-Regeln zentral durchsetzen oder mehrere unterschiedliche Backends unter einer API zusammenführen muss, oder wenn die API ein eigenes Produkt wird. Dann ist die zusätzliche Schicht kein Ballast, sondern Architektur.

Ein HTTP-Service braucht nicht automatisch ein API Gateway. Eine echte API-Plattform braucht meistens mehr als einen Load Balancer.

Wer gerade vor dieser Entscheidung steht, findet das Vorgehen auf der Seite zur AWS-Migration.