AWS Lambda now runs plain Node.js web servers, and the billing model changes with it

For a decade, running a normal web app on AWS Lambda meant translating it into something Lambda understood: an event handler, an adapter library, or an API Gateway mapping in front of it. Lambda Web Functions, launched on October 12, remove that translation step. Your Node.js server listens on a port, and Lambda routes HTTP requests to it. That is a meaningful change in how Lambda fits web workloads, and it arrives with a billing model that rewards some apps and quietly penalizes others.

What AWS shipped

AWS describes Web Functions as a new form factor that lets developers “run standard HTTP web applications on Lambda without rewriting your code into an event handler.” The launch post names Express, Hono, Fastify, and Next.js, and the developer guide adds React Router. Deployment is a single CLI call, aws lambda-web deploy, which returns an HTTPS endpoint. The server reads its host and port from an environment variable Lambda sets, and AWS says no adapters are required.

The runtime model is the larger shift. Classic Lambda gives each execution environment one request at a time. A Web Function environment handles up to 128 concurrent requests, closer to how a conventional Node server behaves. Endpoints support response streaming, scale to zero when idle, can be deployed across multiple Regions behind one endpoint with latency-based routing, and split traffic between two revisions for canary releases.

AWS is also renaming things. Existing functions become “Lambda Event Functions,” a name-only change that AWS says needs no code changes or redeployments. A third form factor, Lambda MicroVMs, covers isolated, stateful sandboxes for untrusted code.

The billing model is the real story

Event Functions bill for wall-clock duration multiplied by configured memory. Web Functions split that apart. AWS’s pricing page lists active vCPU time at $0.0000276944 per vCPU-second and memory at $0.0000036667 per GB-second in US East (N. Virginia), with requests at $0.30 per million against $0.20 per million for Event Functions.

The developer guide is explicit about the trade: a request waiting on a database or external API “consumes little CPU while it waits. However, memory continues to accrue while the execution environment exists, including idle time between requests.”

That favors I/O-heavy services. An API endpoint that spends most of its time waiting on an LLM response, a payment provider, or a slow upstream service no longer pays full price for waiting, and it shares one environment with other in-flight requests instead of claiming a fresh one. Classmethod’s hands-on review reached a similar reading, and also noted the reverse case: for infrequent workloads where cold starts do not matter, the author suggests classic Lambda may still cost less. The higher per-request price and idle memory billing both point the same way. Teams should model their own traffic shape rather than assume the new form factor is cheaper.

Independent testing

Classmethod’s DevelopersIO team deployed both the generated sample and a custom Express 5.3.0 app in the Tokyo Region the day after launch. Each deploy took roughly 25 seconds, and a server-sent events endpoint delivered five events at intervals of 993 to 1002 milliseconds, which suggests streaming works without extra configuration. They also found a practical gotcha: the deploy command does not install dependencies, so node_modules must exist before you deploy. The review did not measure cold starts or concurrency under load, so those remain untested by anyone outside AWS so far.

Where it fits, and where it does not yet

The launch is narrow in a few ways that matter for planning:

• Node.js only. Web Functions run Node.js 24 on Arm64. Python, Java, Go, and .NET teams are pointed back to Event Functions or MicroVMs.
• Five Regions. US East (N. Virginia and Ohio), US West (Oregon), Tokyo, and Ireland.
• Custom domains need CloudFront. Each endpoint gets an AWS HTTPS domain. Custom domains and WAF protection require a CloudFront distribution in front.

The competitive context is hard to miss. Multi-request environments and CPU-based billing are already familiar from platforms such as Vercel’s Fluid compute, Cloudflare Workers, and container services like Google Cloud Run. AWS appears to be closing that gap inside Lambda rather than leading it, and for teams already committed to AWS for IAM, VPC access, and data gravity, that may matter more than who shipped first.

What it means for developers

For Node teams on AWS, the immediate change is that frameworks no longer need a Lambda-specific build target. An Express or Hono app can run locally and on Lambda with the same entry point, which removes a translation layer where header, streaming, and binary-response handling could diverge from local behavior. For teams that chose Vercel, Cloudflare, or a container platform because Lambda’s model fit web apps poorly, this is a reason to re-run the comparison, especially for streaming AI endpoints that sit idle on upstream calls.

The next test is whether Web Functions hold up beyond launch demos. The signals to watch over the next quarter are independent cold-start and concurrency measurements, support for runtimes beyond Node.js, expansion past five Regions, and whether frameworks such as Next.js and React Router ship first-party deployment guides. Stackmaven’s follow-up coverage will land on or around January 16.

Sources cited

1. Announcing AWS Lambda Web Functions (AWS News Blog) aws.amazon.com
2. I tried out Lambda Web Functions, which became GA, in the Tokyo region (Classmethod DevelopersIO) dev.classmethod.jp
3. AWS Lambda announces Lambda Web Functions (What's New with AWS) aws.amazon.com
4. AWS Lambda Web Functions (AWS Lambda Developer Guide) docs.aws.amazon.com
5. AWS Lambda pricing aws.amazon.com