AWS announced AWS Lambda Web Functions, a new Lambda execution model that enables standard web applications and HTTP servers to run directly, without rewriting code to fit the traditional event-handler model. Applications built with Express, Hono, Fastify, or Next.js, or any Node.js framework, can be deployed with a single command and without special adapters or additional infrastructure management.
The service targets web applications, APIs, server-side rendering, and interactive HTTP workloads that handle concurrent requests and I/O-intensive processing.
A Different Execution Model Within Lambda
AWS now offers three distinct execution models within Lambda, all based on Firecracker isolation technology. Event Functions remain suitable for event processing, message consumption, and invocations originating from AWS services, where the handler receives a single event and returns a response according to the traditional model.
Web Functions use a native HTTP model, in which the application listens on a port and handles standard requests. A single execution environment can process up to 128 concurrent requests. The third model, Lambda MicroVMs, provides isolated environments with persistent state and a customer-managed lifecycle for running untrusted or user-generated code.
What Changes in Practice for Developers?
AWS says Web Functions reduce the need to assemble multiple components to distribute a web application globally. The service handles scaling, cross-Region replication, and latency-based routing, while the code remains closer to the HTTP server that developers run locally.
Web Functions are billed based on processor usage time, while memory is billed for the entire duration of the execution environment's existence. As a result, time spent by the application waiting for a database query or an API call consumes little processor time, a model that may suit I/O-intensive workloads such as server-side rendering, APIs, and AI inference endpoints that stream tokens.
This does not mean the cost will automatically be lower for every application; the outcome depends on the usage pattern, how long environments remain active, memory consumption, and request volume.
Deployment, Distribution, and Versions
The AWS CLI uses a command such as aws lambda-web deploy to package the code, create a Web Function, deploy an initial revision, and connect an HTTPS endpoint. The application can be deployed in multiple Regions, such as us-east-1, eu-west-1, and ap-northeast-1, allowing Lambda to route requests through a single global address to the Region with the lowest response latency on a best-effort basis.
The service treats each version as an immutable snapshot of the code. Endpoints can also distribute traffic between versions, including a canary rollout that directs, for example, 90% of requests to the current version and 10% to the new version.
CloudFront Integration and Initial Availability
A Web Function endpoint can be used as an origin for Amazon CloudFront, allowing static assets to be cached across the network while dynamic requests are sent to the web function. AWS also supports connecting CloudFront origin access control to the endpoint, allowing only the specified distribution to invoke it and avoiding exposure of the endpoint or the addition of a custom authorization mechanism within the application.
The service is available at launch in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). It initially runs using Node.js 24 (nodejs24.x) on Arm64, with support for connecting to Amazon VPC to access resources located within virtual private networks.