AWS Lambda Web Functions run Express and Next.js servers without event-handler rewrites

AWS has launched Lambda Web Functions, a new form factor that runs ordinary HTTP servers — built with frameworks such as Express, Hono, Fastify or Next.js — without forcing developers to recast their code as event handlers. According to AWS's announcement, an application that listens on a port locally can be deployed as-is, with Lambda taking care of scaling, multi-region distribution and a billing model based on CPU use rather than elapsed time.

Three ways to run Lambda

The launch reorganizes Lambda into three form factors, all built on the same Firecracker isolation technology.

Event Functions are the Lambda model customers already know, now given a formal name: a handler receives one event, processes it and returns a response, with single-concurrent execution and billing by elapsed wall-clock time.

Web Functions are the new HTTP-native option: code listens on a port and serves standard requests, each execution environment handles many requests at once, and billing follows the CPU time the code actually consumes.

MicroVMs provide isolated, stateful sandbox environments with customer-managed lifecycles, aimed at running untrusted or user-generated code.

AWS presents the three as complementary rather than competing. A single application might use Event Functions for asynchronous backend processing, Web Functions for the user-facing API and server-side rendering layer, and MicroVMs for features that execute user-submitted code.

How deployment works

The only code change AWS requires is reading an AWS_LAMBDA_HTTP_ENDPOINT environment variable, which the platform populates with the host and port the server must bind; running locally means setting that variable yourself.

From there, deployment is one CLI command: aws lambda-web deploy --name my-web-app --code ./my-app. According to AWS, the CLI packages the source, creates the Web Function, publishes an immutable snapshot of the code called a revision, attaches an HTTPS endpoint and returns a live URL in under a minute, with no prior resource setup.

Adding a regions flag such as --regions us-east-1,eu-west-1,ap-northeast-1 replicates the code across all three regions and configures latency-based routing, on a best-effort basis, behind one global URL. Redeploying after a code change uploads a new revision and repoints the endpoint, with AWS putting the turnaround at seconds. For slower rollouts, revision weights can split endpoint traffic — for example 90 percent to the current revision and 10 percent to the new one — giving canary deployments without additional tooling.

Concurrency and billing

Each execution environment can serve up to 128 concurrent requests, so a burst of traffic is absorbed by warm environments instead of mapping every request to a fresh one. Web Functions meter the CPU time the code uses, meaning waits on a database query or an upstream API call accrue little charge, while memory is billed for as long as the environment exists. AWS says this can reduce compute costs for I/O-heavy workloads such as server-side rendering, API backends and AI inference endpoints that stream token-by-token responses.

CloudFront integration

Web Function endpoints can serve as origins for CloudFront distributions, so static assets come from the CDN cache while dynamic requests reach the function. Origin access control has also been extended to these endpoints: CloudFront signs its requests to the origin, and the endpoint admits only the attached distribution. AWS likens this to the private-origin pattern already available for S3, obtained without exposing the endpoint or adding custom authorization to the application.

Launch scope

Web Functions are available in N. Virginia, Ohio, Oregon, Tokyo and Ireland. At launch they run Node.js 24 (nodejs24.x) on Arm64 and support VPC connectivity, so functions can reach resources inside a VPC. Pricing details sit on the Lambda pricing page. The announcement also gained traction on Hacker News, reaching the site's front page.

Why it matters

AWS describes the status quo this launch targets: building a globally responsive web application today typically means assembling several infrastructure components, configuring multi-region deployment and latency-based routing, and tuning the billing model to avoid paying for I/O wait — and often bending application code to fit the compute model instead of shipping the HTTP server you already have. Web Functions attack that problem on all fronts: portable code, CPU-based billing, built-in routing and revision-weighted rollouts in a single CLI. The launch scope is narrow — one Node.js runtime, Arm64 only, five regions — but the programming model change signals where AWS wants serverless compute to go for web workloads.