AWS Lambda Web Functions: Run Express and Next.js Without Rewriting

On 12 October 2026, AWS announced AWS Lambda Web Functions: a new way to run standard HTTP web apps on Lambda without rewriting them into event handlers. If you already ship Express, Hono, Fastify, or Next.js as a port-listening server, you can deploy that same pattern with a single CLI command. No adapters. No framework lock-in. This guide covers what changed, when Web Functions beat classic Event Functions, and how to adopt them without the usual serverless footguns.

What Are AWS Lambda Web Functions?

Lambda Web Functions use an HTTP-native programming model. Your code listens on a port and handles standard HTTP requests. AWS meters active CPU rather than wall-clock time for the request path, and each execution environment can serve many concurrent requests. That model fits web applications, API backends, and interactive HTTP workloads where I/O wait and concurrency are normal (AWS News Blog, Micah Walter, 12 Oct 2026).

With this launch, Lambda now has three form factors, all built on Firecracker isolation:

• Event Functions — the classic event-driven, single-concurrent handler model with wall-clock billing. Ideal for queue consumers, S3 triggers, and other AWS service events.
• Web Functions — HTTP-native, multi-concurrent, active CPU billing. Ideal for SSR, APIs, and streaming HTTP responses.
• MicroVMs — isolated, stateful sandboxes with customer-managed lifecycles for untrusted or user-generated code.

Real systems often mix them: Event Functions for async backend work, Web Functions for the user-facing API or SSR layer, and MicroVMs where you must isolate untrusted code (AWS).

Why This Matters for Web Teams

Until now, putting a standard Node.js HTTP server on Lambda usually meant adapters and paying for time spent waiting on databases or upstream APIs. Web Functions remove that friction: keep your framework, deploy with aws lambda-web deploy, and get HTTPS endpoints, scale-to-zero, and optional multi-region latency-based routing behind one global URL (.lambda-web.global.on.aws).

Each execution environment can handle up to 128 concurrent requests, so bursts can share warm environments. Active CPU billing means I/O wait (a DB query or API call) consumes little CPU; memory is metered while the environment exists. That fits SSR, API backends, and AI inference endpoints that stream token responses (AWS News Blog; Lambda Web Functions docs).

Event Functions vs Web Functions: When to Use Which

AWS is explicit: for queues or file-upload processing, keep Event Functions. Use Web Functions when the workload speaks HTTP directly (docs). Web Functions currently support Node.js only — Event Functions or MicroVMs remain the path for Java, Python, and .NET.

A Minimal Express Example

The only Lambda-specific detail is the AWS_LAMBDA_HTTP_ENDPOINT environment variable. Lambda sets it to the host and port your server must listen on. Locally, set it yourself (for example 127.0.0.1:3000). This pattern comes straight from the AWS announcement:

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}`);
});

Deploy with:

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

The CLI bundles the source, creates the Web Function, publishes the first revision, attaches an endpoint, and returns a live HTTPS URL. For a multi-region rollout with latency-based routing:

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

Revisions are immutable snapshots of code and config. Endpoints route traffic to one or two revisions. For a canary, shift weights — for example 90% on the current revision and 10% on the new one — with aws lambda-web update-web-function-endpoint and --revision-weights (AWS).

Scaling, Billing, and Platform Details

Docs note that the default maxConcurrencyPerEnvironment is 64, configurable in the range 1–128 (scaling docs). You pay for requests, active CPU time, memory over the life of each execution environment, and data transfer. Idle environments scale to zero; the first request after idle may wait while a new environment starts (docs).

At launch, Web Functions run Node.js 24 (nodejs24.x) on Arm64, support VPC connectivity, and are available in us-east-1, us-east-2, us-west-2, ap-northeast-1, and eu-west-1 (AWS News Blog). Teams with data residency needs in India or the UAE should confirm region availability against compliance requirements before committing production traffic.

CloudFront, OAC, and Production Edges

Web Functions work as a CloudFront origin: cache static assets at the edge and send dynamic requests to the function. For private origins, attach CloudFront OAC so only your distribution can invoke the endpoint — the same pattern CloudFront uses for S3 (AWS). Endpoints also support request rate limits and maxEnvironments caps per Region to protect downstream databases and APIs.

When modernising a Node.js estate on AWS, pair this with serverless and automation practices and, where needed, DevOps on AWS managed services so deploys, canaries, and observability stay boring.

Practical Adoption Checklist

1. Prove the listen pattern locally — set AWS_LAMBDA_HTTP_ENDPOINT and confirm the same app.listen path you will deploy.
2. Start with one Region, then add multi-region only when latency or resilience needs justify it.
3. Use revisions and weighted endpoints for canaries instead of big-bang cutovers.
4. Tune concurrency — start near the default of 64 per environment; raise toward 128 only after you measure event-loop and downstream load.
5. Put CloudFront in front for custom domains, WAF, and static/dynamic split; use OAC for private origins.
6. Keep Event Functions for async work — do not force every Lambda into the Web model.

Pitfalls to Avoid

• Blocking the Node.js event loop with CPU-heavy synchronous work. Multi-concurrency only helps if the process stays responsive under concurrent I/O. Offload heavy CPU to workers, Step Functions, or separate Event Functions.
• Assuming global availability. At announcement, Web Functions launched in five Regions only. Check the list before you promise a region to a customer.
• Ignoring package size and cold starts. Large Node bundles still hurt first-request latency after scale-to-zero. Keep dependencies lean.
• Forgetting memory still accrues while an environment exists, including idle gaps. Active CPU savings do not make memory free.

Frequently Asked Questions

Do I need API Gateway or a Lambda adapter for Express?

No. Web Functions are designed so a standard port-listening Node.js server deploys without adapters or framework lock-in. Listen on the host and port from AWS_LAMBDA_HTTP_ENDPOINT (AWS).

How is billing different from classic Lambda?

Web Functions use active CPU billing for compute work, plus charges for requests, memory over the life of each execution environment, and data transfer. Time spent waiting on I/O consumes little CPU (docs).

Can I run Next.js or only Express?

AWS lists Express, Hono, Fastify, Next.js, and any Node.js framework that listens on a port. SSR and streaming responses are called out as good fits.

Which Regions are available today?

At launch: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland) — us-east-1, us-east-2, us-west-2, ap-northeast-1, and eu-west-1. Runtime is Node.js 24 on Arm64, with VPC supported (AWS News Blog).

Ready to Modernise Your Serverless HTTP Stack?

Shanav is an AWS Advanced Tier Partner with offices in India and the UAE. We help teams design, migrate and operate production serverless and DevOps workloads on AWS. Explore our cloud and DevOps services, or when you want a concrete adoption plan for Lambda Web Functions, talk to our AWS experts.