--- title: "Lambda Web Functions: AWS startet einen neuen Serverless-Typ für HTTP-Workloads" description: AWS Lambda Web Functions laufen Node.js-Webserver ohne Adapter direkt serverless. Was das neue Modell kostet, wo es passt – und wo nicht. Jetzt lesen. image: https://dmoove.com/hubfs/blog/agent-images/lambda-web-functions-serverless-http-featured-040109.png --- [Zum Inhalt springen](https://dmoove.com/blog/lambda-web-functions-serverless-http#main-content) [![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo.svg)](https://dmoove.com/) Menü - Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/amazon-quick-ki) - [Migration & DevOps](https://dmoove.com/migration-devops) - Lösungen - [GuardAudit](https://dmoove.com/dmoove-guardaudit) - [Cloud Kosten optimieren](https://dmoove.com/cloud-kosten-optimieren) - [EC2 Image Builder](https://dmoove.com/ec2-image-builder) - [Case Study](https://dmoove.com/case-study-kubernetes-cluster) - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) [Termin buchen](https://dmoove.com/meetings/yannick-tresch) 1. [Blog](https://dmoove.com/blog) 2. [Cloud Computing](https://dmoove.com/blog/tag/cloud-computing) Cloud Computing # Lambda Web Functions: AWS startet einen neuen Serverless-Typ für HTTP-Workloads [Yannick Tresch](https://dmoove.com/blog/author/yannick-tresch) 15\. Oktober 2026 · Min. Lesezeit ![Serverrack mit geöffnetem Einschub, aus dem ein Netz gleichzeitiger HTTP-Verbindungen strömt – symbolisch für Lambda Web Functions und Multi-Concurrency](https://dmoove.com/hs-fs/hubfs/blog/agent-images/lambda-web-functions-serverless-http-featured-040109.png?width=1200&height=750&name=lambda-web-functions-serverless-http-featured-040109.png) Wer bisher eine Express- oder Hono-Applikation auf AWS Lambda betreiben wollte, brauchte einen Adapter. Die Bibliothek übersetzte den Lambda-Event in ein HTTP-Request-Objekt, die Antwort zurück in das Lambda-Format – und jede neue Framework-Version konnte diesen Mechanismus brechen. Seit dem 12. Oktober 2026 gibt es eine Alternative: **Lambda Web Functions**, ein neuer Ausführungstyp innerhalb von AWS Lambda, bei dem der eigene Code direkt auf einem Port lauscht und HTTP-Requests verarbeitet – so wie auf jedem anderen Webserver auch. Dieser Artikel erklärt, was sich konkret geändert hat, wie das neue Abrechnungsmodell funktioniert und für welche Workloads Lambda Web Functions sinnvoll sind – und für welche nicht. ## Was sich geändert hat und was nicht Mit dem Launch von Lambda Web Functions hat AWS gleichzeitig die bisherigen Lambda-Funktionen umbenannt: Sie heißen jetzt **Lambda Event Functions**. Laut der offiziellen AWS-Ankündigung handelt es sich dabei um eine reine Namensänderung – kein Code-Change, kein Redeployment ist erforderlich. Bestehende Funktionen laufen unverändert weiter. AWS Lambda besteht damit aus drei Ausführungstypen, alle auf derselben Firecracker-Isolationstechnologie aufgebaut: - **Lambda Event Functions** (bisher: Lambda Functions) – das bekannte event-getriebene Modell, ein Request pro Execution Environment, Wall-Clock-Billing. - **Lambda Web Functions** – HTTP-nativer Webserver, Multi-Concurrency, Active-CPU-Billing. - **Lambda MicroVMs** – isolierte, zustandsbehaftete Sandbox-Umgebungen für nicht vertrauenswürdigen oder KI-generierten Code. ![Drei unterschiedlich geformte Container auf einem Förderband, die verschiedene Lambda-Ausführungsmodelle symbolisieren: Event Functions, Web Functions und MicroVMs](https://dmoove.com/hubfs/blog/agent-images/lambda-web-functions-serverless-http-inline-040123.png) ## Wie Lambda Web Functions funktionieren Eine Web Function läuft als normaler HTTP-Server. Der Code lauscht auf dem Port, den Lambda über die Umgebungsvariable `AWS_LAMBDA_HTTP_ENDPOINT` setzt. Der einzige Unterschied zur lokalen Entwicklung ist diese eine Variable – das Framework selbst bleibt unverändert. Express, Hono, Fastify und Next.js (im Standalone-Modus) laufen laut AWS-Dokumentation ohne Anpassungen. Das Ressourcenmodell besteht aus drei Ebenen: - **Web Function** – die übergeordnete Ressource mit Name und Konfiguration. - **Revision** – ein unveränderlicher Snapshot von Code und Konfiguration. Jedes Deployment erzeugt eine neue Revision; Traffic lässt sich zwischen zwei Revisionen aufteilen. - **Endpoint** – der HTTPS-Einstiegspunkt, der Traffic auf eine oder zwei Revisionen verteilt. Jede Execution Environment verarbeitet bis zu 128 gleichzeitige Requests. Das reduziert Cold Starts erheblich: Ein Burst eingehender Anfragen verteilt sich auf bereits warme Environments, statt für jeden Request eine neue Umgebung hochzufahren. Zum Launch laufen Web Functions auf Node.js 24 (nodejs24.x) auf Arm64, mit 2 vCPUs und 2 GB Arbeitsspeicher pro Execution Environment. Deployment-Pakete können bis zu 512 MB groß sein – deutlich mehr als bei Event Functions. Das erlaubt vollständige Runtimes mit größeren Abhängigkeitsbäumen. Ein erster Deploy geht per CLI: ``` aws lambda-web deploy --name my-web-app --code ./my-app ``` Der Befehl bündelt den Quellcode, erstellt die Web Function, veröffentlicht die erste Revision, hängt einen Endpoint an und gibt eine Live-HTTPS-URL zurück. Multi-Region-Deployment ist optional und funktioniert durch Angabe mehrerer Regionen: ``` aws lambda-web deploy --name my-web-app --code ./my-app \ --regions us-east-1,eu-west-1,ap-northeast-1 ``` Lambda repliziert den Code in alle angegebenen Regionen und konfiguriert Latency-Based-Routing automatisch. Jeder Request wird an die Region mit der niedrigsten Latenz für den Aufrufer weitergeleitet. ## Das neue Abrechnungsmodell: Active CPU Billing Lambda Event Functions rechnen nach Wall-Clock-Zeit ab: Die Uhr läuft, solange die Funktion aktiv ist – auch wenn sie auf eine Datenbankantwort oder einen API-Call wartet. Bei I/O-lastigen Workloads zahlt man damit für Wartezeit. Lambda Web Functions verwenden stattdessen **Active CPU Billing**: Abgerechnet wird die Zeit, in der der Code tatsächlich CPU verbraucht. Wartezeit auf I/O – Datenbankabfragen, Downstream-API-Calls, KI-Inferenz-Antworten – schlägt kaum zu Buche. Zusätzlich wird der Arbeitsspeicher für die Lebensdauer der Execution Environment berechnet, unabhängig davon, ob gerade ein Request verarbeitet wird. Für wen sich das rechnet: Server-Side-Rendering-Applikationen, REST- und GraphQL-APIs mit Datenbankzugriffen und LLM-Gateway-APIs, die Token-Responses streamen, sind typische Kandidaten. Breadcrumb.ai berichtet auf der AWS-Produktseite von rund 30 % Performance-Verbesserung durch Multi-Concurrency; Marketing Evolution nennt eine viermal niedrigere First-Request-Latenz für seinen Multi-Agent-Dienst. Diese Zahlen stammen aus Kundenaussagen auf der AWS-Seite, nicht aus unabhängigen Benchmarks – die eigene Workload kann abweichen. Für CPU-intensive Batch-Verarbeitung, bei der kaum I/O-Wartezeit anfällt, ist der Vorteil geringer. Hier können Event Functions mit Managed Instances die bessere Wahl sein. ## Lambda Web Functions vs. Lambda Event Functions: Wann was passt Die Entscheidung hängt weniger an der Sprache als am Auslöser und am Verarbeitungsmuster: - **Web Functions** passen, wenn der Workload direkt HTTP-Traffic empfängt: Web-Apps, API-Backends, SSR-Seiten, Streaming-Endpoints, Webhooks. Besonders dann, wenn Requests viel Zeit mit I/O verbringen. - **Event Functions** bleiben die richtige Wahl für event-getriebene Verarbeitung: SQS-Consumer, S3-Trigger, Kinesis-Streams, Scheduled Jobs. Und für alle Sprachen außer Node.js – zum Launch unterstützen Web Functions ausschließlich Node.js. Java-, Python- und .NET-Workloads laufen weiterhin als Event Functions. Zum Launch sind Lambda Web Functions in fünf Regionen verfügbar: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) und Europe (Ireland). Wer Workloads in Frankfurt oder anderen europäischen Regionen betreibt, muss auf die Ausweitung warten oder mit eu-west-1 (Irland) als nächstgelegener Option planen. Die aktuelle Regionsverfügbarkeit listet AWS auf der [What's-New-Seite](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-lambda-web-functions/). Ein weiterer Punkt für Plattform-Teams: Custom Domains erfordern eine vorgelagerte CloudFront-Distribution. Der Web-Function-Endpoint selbst liefert eine AWS-eigene Domain (`*.lambda-web.*.on.aws`). WAF-Schutz ist ebenfalls nur über CloudFront möglich. ## Was das für Ihre Plattform bedeutet Lambda Web Functions lösen kein grundsätzliches Architekturproblem – sie vereinfachen einen konkreten Schritt: den Betrieb von Node.js-Webservern auf serverloser Infrastruktur ohne Adapter-Schicht. Wer heute `serverless-http` oder ähnliche Wrapper einsetzt, um Express auf Lambda zu betreiben, hat jetzt eine direktere Alternative. Für Teams, die bereits auf EKS oder ECS setzen, ändert sich zunächst nichts. Lambda Web Functions sind kein Ersatz für containerisierte Workloads mit komplexen Abhängigkeiten, langen Laufzeiten oder Sprachen jenseits von Node.js. Sie sind ein zusätzliches Werkzeug für HTTP-Workloads, bei denen serverlose Skalierung und Active-CPU-Billing einen messbaren Unterschied machen. Konkret empfiehlt sich folgendes Vorgehen: Identifizieren Sie Node.js-basierte HTTP-Services in Ihrem Portfolio, die heute als Event Functions mit API-Gateway-Adapter laufen oder auf kleinen ECS-Tasks betrieben werden. Prüfen Sie, ob diese Services I/O-lastig sind. Wenn ja, ist ein Proof-of-Concept mit Lambda Web Functions in eu-west-1 ein sinnvoller nächster Schritt – bevor die Funktion in weiteren Regionen verfügbar ist und eine breitere Migration Sinn ergibt. Wie AWS Lambda und serverlose Architekturen in eine moderne AWS-Plattform eingebettet werden, beschreibt unser Artikel [Was ist eine CI/CD Pipeline?](https://dmoove.com/blog/cloud-computing/was-ist-eine-ci-cd-pipeline). Wer den Zusammenhang mit GitOps-Workflows verstehen möchte, findet in [Warum DevOps ohne GitOps unvollständig bleibt](https://dmoove.com/blog/warum-devops-ohne-gitops-unvollständig-bleibt) einen guten Einstieg. Yannick Tresch In diesem Artikel Fragen zu Ihrer Plattform? 30 Minuten, direkt mit dem Gründer. [Termin buchen](https://dmoove.com/meetings/yannick-tresch) Weiterlesen ## Weitere Artikel. - ### [![Kalenderseite mit dem 2. Dezember, umkreist in Rot, neben drei ineinandergreifenden Zahnrädern mit Schloss-Symbol – symbolisch für die EU AI Act Dezember 2026 Compliance-Fristen](https://dmoove.com/hs-fs/hubfs/blog/agent-images/eu-ai-act-dezember-2026-neue-verbote-featured-205033.png?width=800&height=500&name=eu-ai-act-dezember-2026-neue-verbote-featured-205033.png) Cloud Computing EU AI Act Dezember 2026: Zwei neue Verbote und eine Kennzeichnungspflicht – was Unternehmen jetzt tun müssen 13\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/eu-ai-act-dezember-2026-neue-verbote) - ### [![](https://dmoove.com/hs-fs/hubfs/AI-Generated%20Media/Images/Technicians%20Analyzing%20Kubernetes%20Metrics%20In%20Modern%20Data%20Center.png?width=800&height=500&name=Technicians%20Analyzing%20Kubernetes%20Metrics%20In%20Modern%20Data%20Center.png) Cloud Computing HPA Scale-to-Zero in EKS: Wie Kubernetes 1.37 GPU-Kosten senkt – und was Sie beachten müssen 8\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/hpa-scale-to-zero-eks-gpu-kosten) - ### [![](https://dmoove.com/hubfs/Gemini_Generated_Image_9v2nv29v2nv29v2n.jfif) Cloud Computing AWS Digital Sovereignty Lens: Was das neue Well-Architected Framework für souveräne Workloads bedeutet 6\. Oktober 2026 · Min. Lesezeit](https://dmoove.com/blog/aws-digital-sovereignty-lens-well-architected-framework) ![DMoove](https://dmoove.com/hubfs/raw_assets/public/dmoove-2026/images/logo-white.svg) DMoove Solutions GmbH Damaschkestraße 23 10711 Berlin Leistungen - [AWS Landing Zone](https://dmoove.com/aws-landing-zone) - [Kubernetes auf AWS](https://dmoove.com/kubernetes-auf-aws) - [European Sovereign Cloud](https://dmoove.com/european-sovereign-cloud) - [Amazon Quick & KI](https://dmoove.com/de/amazon-quick-ai-essentials) - [Migration & DevOps](https://dmoove.com/migration-devops) Unternehmen - [Über uns](https://dmoove.com/ueber-uns) - [Blog](https://dmoove.com/blog) - [Termin buchen](https://dmoove.com/meetings/yannick-tresch) - [LinkedIn](https://www.linkedin.com/company/dmoove) Rechtliches - [Impressum](https://dmoove.com/impressum) - [Datenschutz](https://dmoove.com/datenschutz) © 2026 DMoove Solutions GmbH ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Yannick Tresch", "url" : "https://dmoove.com/blog/author/yannick-tresch" }, "dateModified" : "2026-10-15T11:27:00.304Z", "datePublished" : "2026-10-15T11:27:00.000Z", "headline" : "Lambda Web Functions: AWS startet einen neuen Serverless-Typ für HTTP-Workloads", "image" : [ "https://dmoove.com/hubfs/blog/agent-images/lambda-web-functions-serverless-http-featured-040109.png" ], "mainEntityOfPage" : { "@id" : "https://dmoove.com/blog/lambda-web-functions-serverless-http", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://dmoove.com/hubfs/dmo_logo450.png" }, "name" : "DMoove Solutions GmbH" } } ``` ```json { "@context" : "https://schema.org", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://dmoove.com/blog", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/tag/cloud-computing", "name" : "Cloud Computing", "position" : 2 }, { "@type" : "ListItem", "item" : "https://dmoove.com/blog/lambda-web-functions-serverless-http", "name" : "Lambda Web Functions: AWS startet einen neuen Serverless-Typ für HTTP-Workloads", "position" : 3 } ] } ```