AWS Lambda Web Functions: 128 Requests per Environment

A single AWS Lambda execution environment has always served one request at a time. With AWS Lambda Web Functions, announced on October 12, one environment handles up to 128 concurrent requests, and you pay for active CPU rather than wall-clock time. For platform teams running web APIs that spend most of their time waiting on databases, that changes both the cost math and the case for moving those apps off containers.

What Happened

AWS now describes three Lambda form factors: Event Functions, the standard event-driven model; Web Functions; and MicroVMs. Web Functions run a standard HTTP app, such as Express, Hono, Fastify, or Next.js, “without rewriting your code into an event handler.” There are no adapters or wrappers. The only Lambda-specific detail, per AWS, is the AWS_LAMBDA_HTTP_ENDPOINT environment variable, which tells the server which host and port to listen on.

Deployment uses a new CLI namespace. aws lambda-web deploy creates the function, publishes an immutable revision, and attaches an HTTPS endpoint. Redeploying publishes a new revision and points the endpoint at it, and update-web-function-endpoint splits traffic between revisions by weight for canary rollouts. Passing --regions replicates the code to several regions behind one global URL, with latency-based routing on a best-effort basis. For a first look before porting an app, aws lambda-web deploy --name hello-world --hello-world deploys a sample function.

At launch, the runtime is Node.js 24 on Arm64, with VPC connectivity. Web Functions are available in US East (N. Virginia and Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). An endpoint can be a CloudFront origin, locked down with origin access control. The Web Functions documentation covers setup.

Why It Matters

The billing model is the real change. AWS explains that CPU time is metered, so time spent waiting on a database query or API call consumes little CPU, while memory is metered for as long as the environment exists. A typical web API is mostly I/O wait. Under one-request-per-environment billing, every waiting request paid for its own environment. Under Web Functions, up to 128 requests share one, and the wait is cheap.

That also changes the code. Multi-concurrent execution means shared in-process state, connection pools, and module-level caches now serve many requests at once, which is how the same app already behaves in a container. AWS gives no per-unit prices or latency benchmarks in the announcement, so the savings for a given workload have to be measured against the Lambda pricing page.

What This Means for Builders

Web Functions sit between Event Functions and the stateful Lambda MicroVMs form factor. They look aimed at teams who kept web apps on containers because Lambda’s handler model meant rewriting the app. Node.js-only support at launch limits who can move today.

Source: AWS News Blog

Content created with AI assistance and reviewed for accuracy.