AWS Lambda Web Functions: Node.js-Webserver ohne Lambda-Adapter betreiben
Express, Hono und React Router lauschen direkt auf einem Port, während Lambda HTTPS, Streaming, Revisionen und die serverlose Skalierung übernimmt.
AWS erweitert Lambda um ein Ausführungsmodell für vollständige Node.js-Webserver. Bei Lambda Web Functions lauscht die Anwendung direkt auf einem Netzwerkport und verarbeitet reguläre HTTP-Anfragen. Frameworks wie Express, Hono und React Router benötigen dafür keinen Lambda-spezifischen Adapter. Lambda ergänzt den HTTPS-Endpunkt, unterstützt Streaming sowie mehrere gleichzeitige Anfragen pro Ausführungsumgebung und skaliert ungenutzte Kapazität bis auf null.
Das ist vor allem für Anwendungen interessant, deren natürliche Schnittstelle bereits HTTP ist: REST- oder GraphQL-APIs, Microservices, Full-Stack-Anwendungen und serverseitig gerenderte Seiten. Statt die Webschicht in ein ereignisspezifisches Lambda-Format zu übersetzen, kann der vorhandene Server zum eigentlichen Funktionscode werden. Bereitgestellt wird er als ZIP-Datei.
Was an Web Functions neu ist
Eine klassische Lambda-Integration denkt vom einzelnen Aufruf aus: Ein Ereignis erreicht einen Handler, der daraus ein Ergebnis erzeugt. Web Functions verschieben diese Grenze. Der Code startet einen normalen HTTP-Server, bindet sich an einen Port und bleibt innerhalb seiner Ausführungsumgebung für eingehende Anfragen verfügbar. Den zu verwendenden Port stellt Lambda über den Wert PORT bereit.
Dadurch bleibt die HTTP-Semantik im Anwendungscode erhalten. Routing, Middleware, Header, Statuscodes und die Erzeugung des Response-Bodys liegen weiterhin beim eingesetzten Webframework. Lambda übernimmt die verwaltete Außenseite mit einem HTTPS-Endpunkt und leitet die Anfragen an eine aktive Revision weiter. Die AWS-Dokumentation zu Web Functions nennt derzeit ausschließlich Node.js-Runtimes und führt Express, Hono sowie React Router als direkt nutzbare Frameworks auf.
Der technische Gewinn besteht damit nicht in einem neuen Router oder einem zusätzlichen Framework. Neu ist die Möglichkeit, den ohnehin vorhandenen Node.js-Server zum nativen Lambda-Workload zu machen. Das reduziert die Distanz zwischen einer lokal gestarteten Webanwendung und ihrer serverlosen Bereitstellung.
Express, Hono und React Router behalten ihr Servermodell
Bei einer Express-Anwendung bleibt der zentrale Einstiegspunkt vertraut: Die App registriert Routen und Middleware und startet anschließend den Server auf dem von Lambda vorgegebenen Port. Auch eine Hono-API kann ihre HTTP-Routen in diesem Modell weiterverwenden. Für React Router ist vor allem die serverseitige Ausführung relevant, weil nicht nur einzelne API-Antworten, sondern auch gerenderte Seiten über den Endpunkt ausgeliefert werden können.
Das eröffnet einen direkten Migrationspfad für kleinere bestehende Node.js-Dienste. Eine REST-API mit Routen wie /products und /orders muss nicht in mehrere einzelne Handler zerlegt werden. Eine GraphQL-Anwendung kann ihren einzigen HTTP-Endpunkt samt bestehender Middleware behalten. Ein Full-Stack-Projekt kann serverseitig erzeugtes HTML und zugehörige API-Routen aus derselben Webanwendung liefern.
Die Gemeinsamkeit dieser Beispiele ist konkret: Sie besitzen bereits einen HTTP-Server als stabile Anwendungsgrenze. Web Functions bewahren diese Grenze, während Lambda die Ausführungsumgebungen nach Bedarf bereitstellt. Andere Laufzeiten nennt AWS für Web Functions derzeit nicht; eine Anwendung muss deshalb in einer unterstützten Node.js-Runtime laufen.
Von der HTTPS-Anfrage bis zur gestreamten Antwort
Der Auslöser ist eine Anfrage an den von Lambda verwalteten HTTPS-Endpunkt. Dieser Endpunkt leitet den HTTP-Verkehr an eine aktive, unveränderliche Revision der Web Function weiter. Die Anwendung empfängt die üblichen Bestandteile einer HTTP-Anfrage – Methode, Pfad, Header und Body – über ihr Framework und erzeugt daraus eine normale HTTP-Antwort.
Für lange oder schrittweise erzeugte Antworten ist Streaming besonders wichtig. Der Server kann Daten ausgeben, bevor die vollständige Antwort fertig berechnet ist. Das passt etwa zu serverseitig gerenderten Seiten, bei denen der Browser früh mit dem Aufbau beginnen soll, oder zu APIs, die Resultate fortlaufend übertragen. Die Web Function muss dafür nicht auf ein separates, Lambda-spezifisches Antwortobjekt umgestellt werden.
Eine Ausführungsumgebung kann zudem mehrere Anfragen gleichzeitig bearbeiten. Damit hängt das Verhalten unter Last nicht allein von der Zahl neu gestarteter Umgebungen ab, sondern auch davon, wie gut der Node.js-Server parallele, häufig I/O-lastige Anfragen verarbeitet. Fehler bleiben dabei Teil der HTTP-Schnittstelle: Die Anwendung antwortet mit passenden Statuscodes und Response-Bodys; kann die aktive Revision eine Anfrage nicht erfolgreich bearbeiten, erscheint das nach außen als fehlgeschlagene HTTP-Anfrage.
Revisionen trennen Codeänderungen vom Endpunkt
AWS modelliert eine Web Function nicht nur als hochgeladenes Archiv. Sie besteht aus Code und Konfiguration, daraus erzeugten unveränderlichen Revisionen sowie mindestens einem Endpunkt. Ein Endpunkt verweist jeweils auf eine aktive Revision. Dadurch erhält eine veröffentlichte Fassung eine feste Identität, während die Adresse als eigener Baustein verwaltet wird.
Das ist für Aktualisierungen nützlich: Eine neue ZIP-Datei und eine geänderte Konfiguration erzeugen eine neue Revision, ohne die vorherige Fassung nachträglich umzuschreiben. Anschließend lässt sich der Endpunkt auf die gewünschte aktive Revision ausrichten. AWS dokumentiert dafür sowohl die Bedienung über die Konsole als auch über die AWS CLI in der Anleitung zum Erstellen einer Lambda Web Function.
Der Zugriff auf Endpunkte wird über Ressourcenrichtlinien verwaltet. Damit ist die veröffentlichte Webadresse nicht von der Berechtigungskonfiguration losgelöst. Eigene Domainnamen werden allerdings nicht direkt von Web Functions unterstützt. Wer statt des bereitgestellten Endpunkts eine eigene Domain benötigt, setzt laut AWS CloudFront oder API Gateway davor.
Drei Anwendungen, die unmittelbar passen
Ein kompakter API-Dienst ist der naheliegendste Einsatz. Eine Express- oder Hono-Anwendung kann REST-Routen, Validierung und Middleware in einem Paket bündeln. Weil Lambda bei Leerlauf bis auf null skaliert, eignet sich das Modell besonders für unregelmäßig aufgerufene interne Dienste, Prototypen oder APIs mit ausgeprägten Lastspitzen.
Eine zweite Variante ist ein GraphQL-Backend. GraphQL bündelt viele Operationen unter einem HTTP-Endpunkt; genau dieses langlebige Servermodell lässt sich als Web Function bereitstellen. Die Anwendung behält Schema, Resolver und HTTP-Middleware, während der Lambda-Endpunkt die öffentliche HTTPS-Adresse liefert.
Der dritte Fall sind serverseitig gerenderte Anwendungen. React Router kann serverseitig erzeugte Seiten ausgeben, und Streaming ermöglicht eine frühe Übertragung bereits verfügbarer Bestandteile. API-Routen und Seitenrendering können dabei in derselben Node.js-Anwendung liegen. Für eine eigene Domain oder eine zusätzliche Verteilungsschicht wird der Lambda-Endpunkt mit CloudFront oder API Gateway verbunden.
Web Functions sind dagegen kein allgemeiner Containerdienst. Der dokumentierte Bereitstellungsweg verwendet ZIP-Dateien, und die Laufzeit ist auf Node.js beschränkt. Entscheidend ist daher nicht nur, ob eine Anwendung HTTP spricht, sondern auch, ob sie in dieses Laufzeit- und Paketmodell passt.
Der eigene CLI-Bereich macht die Bausteine sichtbar
Für Web Functions stellt AWS in der CLI den separaten Befehlsbereich lambda-web bereit. Seine Struktur bildet das Ressourcenmodell ab: Funktionen, Revisionen und Endpunkte werden getrennt erstellt, aufgelistet, aktualisiert oder gelöscht. Weitere Befehle verwalten Ressourcenrichtlinien und Tags sowie die Kontingente und deren Nutzung.
Das ist mehr als eine alternative Oberfläche zur Konsole. Die Trennung macht Veröffentlichungen reproduzierbar: Zuerst wird die Funktion mit Code und Konfiguration vorbereitet, daraus entsteht eine unveränderliche Revision, und ein Endpunkt wird mit der aktiven Fassung verbunden. Der Endpunkt kann damit bestehen bleiben, obwohl sich die dahinterliegende Revision ändert.
Die vollständige Befehlsübersicht steht in der AWS CLI Command Reference für lambda-web. Für automatisierte Bereitstellungen sind insbesondere die getrennten Operationen für Revisionen, Endpunkte und Richtlinien relevant, weil sie jede Änderung an einer klar benannten Ressource festmachen.
Feste Kontingente setzen den Einsatzrahmen
AWS nennt für jede Web Function höchstens 10 Endpunkte und 50 Revisionen. Pro Endpunkt sind bis zu 10.000 Anfragen pro Sekunde vorgesehen. Auf Kontoebene gilt innerhalb einer Region ein Kontingent von bis zu 100.000 Anfragen pro Sekunde; das regionale Ausführungskontingent beträgt insgesamt 2.000 Arm-vCPUs. Diese Web-Function-Kontingente sind laut AWS nicht anpassbar.
Die Zahlen erlauben eine klare Einordnung: Ein einzelner Endpunkt kann eine hohe Anfragerate bedienen, doch zusätzliche Endpunkte heben weder das regionale Kontingent des Kontos noch die verfügbare Rechenkapazität auf. Auch die 50 Revisionen sind eine feste Obergrenze. Wer häufig veröffentlicht, muss deshalb die Zahl vorgehaltener Fassungen im Blick behalten. Die Werte führt AWS in der Übersicht zu Lambda-Endpunkten und Kontingenten.
Bei der Abrechnung nennt AWS die aktive Rechenzeit und den verbrauchten Arbeitsspeicher. Die Skalierung bis auf null vermeidet laufende Kapazität für eine ungenutzte Webanwendung, beseitigt aber nicht die Kosten tatsächlich bearbeiteter Anfragen. Für die Wahl des Modells zählt deshalb das Lastprofil: Schwankende oder zeitweise aussetzende Nutzung spielt die serverlose Skalierung stärker aus als dauerhaft gleichmäßige Volllast.
Verschlüsselung und eigene Domains ergänzen das Betriebsmodell
Code-Artefakte und Umgebungsvariablen werden serverseitig verschlüsselt. Standardmäßig verwendet Lambda dafür einen von AWS verwalteten Schlüssel. Alternativ lässt sich ein eigener AWS-KMS-Schlüssel einsetzen, wenn Rotation, Zugriffsrichtlinien und Audits selbst kontrolliert werden sollen. Dafür entstehen zusätzliche KMS-Kosten.
Bei regionsübergreifenden Endpunkten muss der eigene Schlüssel in jeder Zielregion verfügbar und zugänglich sein. Diese Vorgabe betrifft nicht die HTTP-Logik der Anwendung, wohl aber die Konfiguration eines über mehrere Regionen verteilten Angebots. AWS beschreibt die Varianten in der Dokumentation zur Verschlüsselung von Web Functions.
Damit ergibt sich ein klar umrissenes Einsatzprofil: Web Functions passen zu Node.js-Anwendungen, die bereits als HTTP-Server gebaut sind, als ZIP-Paket bereitgestellt werden können und von bedarfsgerechter Skalierung profitieren. Express, Hono und React Router bleiben auf ihrer vertrauten Abstraktionsebene. Lambda übernimmt Endpunkt, Revisionen und Rechenkapazität – ohne aus dem Webserver einen Lambda-spezifischen Handler zu machen.