AWS Lambda Web Functions: Deploy HTTP Apps Without Rewriting Code

AWS has unveiled Lambda Web Functions, a fresh approach to running HTTP-based applications on its serverless platform. Unlike traditional Lambda functions, this form factor accepts standard port-listening servers built with frameworks such as Express, Hono, Fastify, Next.js, or any Node.js framework. Developers can deploy such applications with a single command, and the platform automatically manages scaling, multi-region distribution, and active CPU billing—all without code rewrites or infrastructure management.

Three Lambda Form Factors

Lambda now provides three distinct form factors, all built on Firecracker isolation technology but tailored to different programming models. Event Functions represent the traditional Lambda model: event-driven, single-concurrent handlers with wall-clock billing. These suit event processing, queue consumption, and service-triggered invocations. Web Functions introduce an HTTP-native model with multi-concurrent execution and active CPU billing, designed for web applications, API backends, and interactive workloads. Lambda MicroVMs offer isolated, stateful sandboxes with customer-managed lifecycles for running untrusted or user-generated code. These three complement each other within a single AWS account and operational model.

Why Web Functions Matter

Modern web applications serving global audiences typically require assembling multiple infrastructure components, configuring multi-region deployments, setting up latency-based routing, and optimizing billing models to avoid charges for I/O wait time. Developers frequently must adapt their application code to fit a specific compute model rather than deploying the HTTP server they already have. Web Functions eliminates this friction.

Each execution environment handles multiple requests simultaneously—up to 128 concurrent requests per environment—allowing traffic bursts to share warm environments instead of triggering new instances for each request. The platform meters CPU time based on actual usage, so time spent waiting on database queries or API calls consumes minimal CPU. Memory is metered for the duration the execution environment exists. For I/O-heavy workloads like server-side rendering, API backends, and AI inference endpoints streaming token responses, this billing approach can reduce compute costs.

Getting Started

A simple Express.js server demonstrates the minimal code changes required. The application runs identically to local execution with node index.js, with one addition: the AWS_LAMBDA_HTTP_ENDPOINT environment variable, which Lambda sets to specify the host and port the server must listen on.

import express from 'express';

const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');

app.get('/', (req, res) => {
  res.json({ message: 'Hello from Lambda Web Functions!' });
});

app.listen(port, host, () => {
  console.log(`Server running on port ${port}`);
});

Deployment happens through the AWS CLI with a single command:

aws lambda-web deploy --name my-web-app --code ./my-app

The CLI bundles the source code, creates the Web Function, publishes its first revision, attaches a Web Function endpoint, and returns a live HTTPS URL in under a minute. A revision represents an immutable snapshot of deployed code, while the endpoint serves as the HTTPS URL that routes traffic to a revision or distributes traffic across multiple revisions.

Multi-Region Deployment and Traffic Management

Extending an application to serve users across multiple regions requires redeploying with region specifications:

aws lambda-web deploy --name my-web-app --code ./my-app \
    --regions us-east-1,eu-west-1,ap-northeast-1

Lambda Web Functions automatically replicates code to all specified regions and configures latency-based routing. Each request routes to the region with the lowest latency for the caller on a best-effort basis through a single global URL. Code updates deploy in seconds when running the same command again.

Production workflows requiring gradual rollouts can shift traffic between revisions using a single API call:

aws lambda-web update-web-function-endpoint \
    --function-name my-web-app \
    --endpoint-name dev \
    --auto-deployment-mode Disabled \
    --revision-weights '[{"revisionId": "", "weight": 90}, {"revisionId": "", "weight": 10}]'

This configuration sends 90 percent of endpoint traffic to the current revision and 10 percent to a new one, enabling canary deployments without additional tooling.

Integration with Amazon CloudFront

Applications combining static and dynamic content benefit from pairing Web Functions with Amazon CloudFront. A Web Function endpoint can serve as the origin for a CloudFront distribution, with static assets delivered from cache and dynamic requests routed to the Web Function for CDN performance on static content and serverless compute on dynamic parts.

Web Functions improves the private-origin experience with CloudFront by allowing developers to attach CloudFront origin access control (OAC) directly to a Web Function endpoint. CloudFront signs requests to the origin, and the endpoint permits only the distribution to invoke it. This replicates the private-origin pattern CloudFront provides for Amazon S3 without exposing the endpoint or requiring custom authorization in the application.

Availability and Getting Started

AWS Lambda Web Functions is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). Web Functions run Node.js 24 (nodejs24.x) on Arm64 at launch and support Amazon Virtual Private Cloud (VPC) connectivity, enabling functions to access resources within a VPC.

Developers can deploy their first Web Function in under a minute using:

aws lambda-web deploy --name hello-world --hello-world

Pricing details are available on the AWS Lambda pricing page, with additional information in the Lambda Web Functions documentation.