Announcing AWS Lambda Web Functions

Lambda Web Functions is a new form factor that lets you run standard HTTP web applications on Lambda without rewriting your code into an event handler. Take a standard port-listening server built with Express, Hono, Fastify, Next.js, or any Node.js framework, deploy it with a single command, and Lambda handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, no framework lock-in.

Three form factors, one Firecracker foundation

With this launch AWS Lambda offers three distinct form factors, all built on the same Firecracker isolation technology, each targeting a different programming model:

• Lambda Event Functions are what you already knew as plain Lambda functions: the event-driven, single-concurrent handler model with wall-clock billing. Now given an explicit name — your function receives an event, processes it, returns a response. Ideal for event processing, queue consumers, and invocations triggered by other AWS services.

• Lambda Web Functions use an HTTP-native programming model with multi-concurrent execution and active CPU billing (you pay for the CPU you actually use, not wall-clock time). Your code listens on a port and handles standard HTTP requests. Ideal for web applications, API backends, and interactive HTTP workloads where multiple concurrent requests and I/O-heavy processing are the norm.

• Lambda MicroVMs provide isolated, stateful sandbox environments with customer-managed lifecycles for running untrusted or user-generated code.

The three complement each other — a single application might use Event Functions for asynchronous backend processing, Web Functions for the user-facing API and server-side rendering, and MicroVMs for interactive code-execution features, all in the same account with the same operational model.

Why this matters

The previous model forced a mental modal switch: HTTP frameworks think in connections and concurrent requests, Lambda functions think in events and single invocations. Web Functions remove that impedance mismatch — you bring your existing Node.js framework, your existing middleware, your existing request lifecycle, and Lambda runs it with serverless scaling.

The active-CPU billing is the quiet headline: HTTP workloads spend much of their time waiting on I/O, and wall-clock billing charged you for that waiting even when the CPU was idle. Active CPU billing aligns cost with actual compute consumed, which changes the economics of serverless web workloads meaningfully.

Bottom line

Lambda Web Functions close the gap between "serverless" and "ordinary web framework." If you've been avoiding Lambda because your Express/Fastify/Hono/Next.js app didn't fit the event-handler model — or because wall-clock billing made I/O-heavy HTTP expensive — this removes both objections. The framework you deploy keeps its normal programming model; Lambda just runs it.