AWS Lambda Web Functions run HTTP servers with 128-way concurrency and CPU-based billing

What launched

AWS has announced Lambda Web Functions, a new deployment target for web workloads on its serverless platform. According to a hands-on write-up syndicated to dev.to on October 15, 2026 and originally published on the author's own site, the feature gives Lambda a second execution model alongside what AWS now brands Lambda Event Functions.

The difference is the interface. An Event Function receives an event object and must return a response, which never matched how a production Next.js server behaves — it listens on an HTTP port and serves requests. A Web Function instead just runs an HTTP server: the application listens on a host and port that the Lambda runtime provides, and AWS fronts it with an HTTPS endpoint while handling execution environments and scaling. The author highlights that this removes both the API Gateway translation layer and the framework-specific adapters traditionally needed to put a Node web server on Lambda.

Concurrency and billing

An execution environment that stays warm can handle several requests simultaneously instead of one invocation at a time. AWS sets an upper bound of 128 concurrent requests per environment, with actual concurrency managed dynamically. The author suggests this suits web apps that spend much of their time waiting on databases or downstream AWS services.

The pricing model is new as well: Web Functions bill for active CPU time, memory held over the environment's lifetime, requests and data transfer. Since waiting on a database costs little CPU even though memory stays allocated, the structure could favour I/O-bound applications, though the write-up notes that whether it works out cheaper for any particular app depends on the workload. Native response streaming is also supported.

What it does not cover yet

At launch the runtime is Node.js 24 on Arm64, so this is not a general-purpose option for arbitrary stacks. AWS is shipping supporting tooling from day one, including immutable revisions, endpoints that can route traffic to specific revisions, and optional multi-region routing. The author also cautions that an HTTPS endpoint plus compute is not the same thing as a complete managed hosting platform for a framework like Next.js.

The Amplify friction it answers

The write-up frames the announcement against years of difficulty hosting Next.js on AWS Amplify. The complaints include an infrastructure-as-code experience hampered by provider limitations, API gaps and undocumented behaviour; resources that behave differently when configured through the console versus the API, which undermines reproducibility; and deployments that are hard to debug, although that has reportedly improved recently.

Smaller irritations add up too. AWS documents that Amplify environment variables are not automatically exposed to Next.js server components and must be wired into the app's environment configuration during the build. Per the Amplify documentation cited in the post, Next.js support currently covers up to Next.js 15 while explicitly excluding streaming and on-demand incremental static regeneration. The author had previously weighed ECS containers (too much operational overhead) and splitting server-side logic into Lambda via OpenNext (more integration to own than desired), settling on Amplify as the most tolerable option available.

A like-for-like comparison

To exercise the new feature, the author had an AI coding agent, identified as Codex GPT 6 Astra, build Fin & Feast, a fictional fish-delivery takeaway app on Next.js 15, TypeScript and the App Router. The demo covers dynamic homepage rendering, statically generated dish pages, a checkout API with server-side basket validation and price calculation, and order pages guarded by a signed HttpOnly receipt cookie. The same codebase was deployed to both Amplify and Lambda Web Functions and exercised repeatedly with Playwright, with the source, Terraform and test harness published in a GitHub repository so others can reproduce the experiment.

Why it matters

Serverless has historically offered web developers two unappealing choices: bolt an HTTP server onto an event-driven model using gateways and adapters, or hand everything to a managed platform with opinionated pipelines and rough edges. Lambda Web Functions changes the first option by making the Lambda execution model match how web servers actually work, and the new concurrency limits plus CPU-based billing alter the economics for I/O-heavy sites. For teams frustrated by Amplify's Next.js support — particularly the missing streaming and on-demand ISR — this looks like a credible path to running the framework on AWS with fewer platform-specific quirks. The caveats are real: one runtime at launch, and no built-in CDN, build pipeline or framework integration. It is a foundation for simpler web hosting on AWS rather than a finished Amplify replacement, but it is a foundation many developers have been waiting for.