Amazon Web Services announced AWS Lambda Web Functions on October 12, a new way to run an ordinary HTTP web application on Lambda without rewriting it as an event handler. A server built with Express, Hono, Fastify, Next.js or another Node.js framework listens on a port as it would on a laptop, and Lambda handles scaling, deployment to several regions and billing.

The details come from the AWS News Blog launch post. AWS says the service is available now in five regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) and Europe (Ireland).

Three kinds of Lambda function

With this launch AWS splits Lambda into three “form factors,” all built on the same Firecracker isolation:

  • Lambda Event Functions is the new name for the Lambda functions developers already use: one event in, one response out, one request per environment at a time, billed by wall-clock time.
  • Lambda Web Functions use a plain HTTP programming model. The code listens on a port, and one execution environment can serve several requests at once.
  • Lambda MicroVMs are isolated, stateful sandboxes with a lifecycle the customer manages, aimed at running untrusted or user-generated code.

AWS presents them as complementary. Its example application uses Event Functions for background jobs, Web Functions for the user-facing API and server-side rendering, and MicroVMs for features that execute users’ code.

What changes for a web app

The practical change is that the server code stays as it is. In AWS’s walkthrough, the only Lambda-specific detail is an environment variable, AWS_LAMBDA_HTTP_ENDPOINT, which tells the server which host and port to listen on. Running locally, a developer sets that variable by hand.

Deployment is one AWS CLI command, aws lambda-web deploy. According to the post, it bundles the source, creates the function, publishes a first revision and returns a live HTTPS URL. A revision is an immutable snapshot of the deployed code; an endpoint is the URL that routes traffic to one revision or splits it across several. AWS shows a 90/10 split between two revisions as a canary release done with a single API call.

Adding the --regions flag replicates the code to the listed regions and sets up latency-based routing behind one global URL. AWS describes that routing as “best-effort”: each request goes to the region with the lowest latency for the caller.

For sites that mix static files and dynamic pages, a Web Function endpoint can sit behind Amazon CloudFront as an origin. CloudFront origin access control can be attached to the endpoint, so only that distribution can call it, the same private-origin pattern CloudFront already uses for S3 buckets.

Concurrency and billing

Two numbers in the announcement explain the pitch. One execution environment handles up to 128 concurrent requests, so a burst of traffic can share warm environments instead of starting a new one per request. And Web Functions meter the CPU time the code actually uses, while memory is metered for as long as the environment exists. AWS argues that this lowers costs for I/O-heavy work such as server-side rendering, API backends and AI endpoints that stream tokens, because time spent waiting on a database or another API uses little CPU. That is AWS’s claim; the launch post does not publish prices, and refers readers to the Lambda pricing page.

Limits at launch

At launch Web Functions run only Node.js 24 (nodejs24.x) on Arm64. They support connections into an Amazon VPC, so a function can reach databases and other resources inside a private network. Teams with Python, Go or Java web servers are not covered by this release, and the post gives no date for other runtimes.

Multi-region deployment also does not make an application’s data multi-region. A web tier spread across three regions still depends on wherever its database lives, a point our guide to regions and availability zones works through with real failures. For the record of past cloud incidents, see the major outages tracker.