Lambda Web Functions — the HTTP server Lambda finally grew

Published

For a long time, "put my Express app on Lambda" meant adapters, API Gateway mapping templates, and a mental model that never quite matched the code you already had. On 12 October 2026 AWS shipped Lambda Web Functions — a second Lambda form factor where your code listens on a port and answers HTTP like any other Node.js server. No handler export. No Lambda Web Adapter. No rewriting the app into an event. Lambda takes cares of all of it.

The official AWS News Blog announcement and the follow-up Compute Blog walkthrough are a must-read to get started. What follows is my understanding and interpretation: what changed, what the bill looks like, and where I would still use classic Lambda.

Three form factors, one isolation story

With this launch, Lambda is no longer one programming model with three marketing names. It is three form factors on the same Firecracker isolation:

  • Event Functions — what you already know as Lambda. One concurrent invocation per environment, wall-clock billing, event in / response out. Queues, S3 triggers, EventBridge, the glue between services.
  • Web Functions — HTTP-native. Your process listens on a port, handles many requests at once, and bills on active CPU plus memory for the life of the environment.
  • MicroVMs — customer-managed lifecycles for sandboxes and untrusted code.

An application can use all three. Event Functions for async work, Web Functions for the user-facing API or SSR layer, MicroVMs when someone else's code needs a box.

The programming model that matters

The entire contract is: start an HTTP server on the address in AWS_LAMBDA_HTTP_ENDPOINT. That's it. From the docs and the News Blog sample:

import express from "express";

const app = express();
const [host, port] = (
  process.env.AWS_LAMBDA_HTTP_ENDPOINT || "127.0.0.1:3000"
).split(":");

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

app.listen(Number(port), host);

Locally you set the variable yourself (or rely on the fallback). On Lambda, the platform sets it, terminates TLS at the endpoint, and forwards plain HTTP into your process. You never configure certificates in the app.

At launch this is Node.js 24 (nodejs24.x) on Arm64, with 2 vCPUs and 2 GB per execution environment. Express, Hono, Fastify, Koa, and Next.js (standalone, with a thin entry that maps host/port) all fit. Python, Java, and .NET stay on Event Functions for now.

Deploy is deliberately boring:

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

One command creates the Web Function, a revision, an HTTPS endpoint, and returns a live URL. Under the covers the model is three resources: the function, immutable revisions, and endpoints that route traffic to one or two revisions — including weighted canaries without a separate release tool.

Why this is not "Lambda + API Gateway again"

Three properties change the conversation for HTTP workloads.

Multi-concurrency. Each warm environment can handle many requests at once — default 64, up to 128 via maxConcurrencyPerEnvironment. A burst shares warm processes instead of mapping one request to one cold container. The Compute Blog's SSE load test is the clearest illustration: hundreds of open streams on a handful of environments, not hundreds of environments.

Active-CPU billing. You pay for requests, memory while the environment exists, and the CPU time the runtime actually burns. Waiting on DynamoDB, an LLM token stream, or a downstream API consumes little CPU. That is the opposite of classic wall-clock Lambda billing, and it is why SSR, API backends, and streaming inference endpoints are the stated sweet spot.

Built-in HTTPS and multi-Region routing. Endpoints give you TLS and a Lambda-owned domain. Add --regions (or a MultiRegion endpoint) and Lambda replicates the revision and puts latency-based routing behind a single global URL (.lambda-web.global.on.aws). No hand-built Route 53 latency records for the first cut.

CloudFront is a first-class companion: use a Web Function endpoint as origin, and attach origin access control so the origin stays private the same way S3 origins already do. For custom domains, WAF, and edge caching, put CloudFront in front — the News Blog calls this out explicitly.

What I would use it for

Straight from the developer guide, and aligned with how I see customers stuck today:

  • Full-stack or SSR apps that already have a production Node server (Next.js standalone, Express/Hono APIs).
  • REST or GraphQL backends that are I/O-heavy and hate cold-start multiplication under burst.
  • Streaming responses — SSE, chunked transfer, LLM token streams — without occupying one Event Function environment per open connection.
  • Small HTTP microservices that should scale to zero and not carry an ALB tax.

Auth is endpoint-level: Application-managed (public URL, your app owns OAuth/JWT/Cognito) or IAM (SigV4 / SigV4a, good for service-to-service). Org admins can ban public endpoints with an SCP on lambda:Request/WebFunctionAuthType.

What I would not use it for

Event Functions remain the right tool when the trigger is not "an HTTP request to my server":

  • SQS, SNS, EventBridge, S3, DynamoDB Streams, scheduled work.
  • Workloads that need a non-Node runtime today.
  • Anything that assumes session affinity or sticky state in the process — multi-Region routing and independent request placement will punish that design.

Also remember the fine print that matters in reviews: memory still accrues for the life of the environment (including idle gaps between requests), scale-to-zero still means the first request after idle can wait on init, and WebSockets are not supported (SSE is). Cap downstream risk with endpoint rateLimit and maxEnvironments — over-limit traffic gets 429, not a queue.

Availability

At announcement: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), Europe (Ireland). VPC connectivity is supported so the app can reach private databases and internal APIs. Pricing lives on the Lambda pricing page; treat the active-CPU story as a workload-specific win, not a universal discount.

The short version

Lambda Web Functions are the straight answer to "How can I host my Node HTTP server on AWS?" — yes, with multi-concurrency and a billing model that fits I/O-bound web work. Read Micah Walter's announcement, then Julian Wood, Kim Wendt, and Samrat Karak's Compute Blog deep dive with the SSE sample. Keep Event Functions for events. Reach for Web Functions when the thing you already wrote is a server.

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

That is enough to form an opinion in under a minute.