AWS Launches Lambda Web Functions, Letting Express and Hono Run Natively on Lambda

In October 2026, AWS announced Lambda Web Functions, a new Lambda function category built to run web applications in Node.js without needing an adapter layer. Frameworks like Express, Hono, Fastify, and Next.js now run directly on the platform, as if they were a standard HTTP server listening on a port.

Until now, anyone who wanted to run an Express API on Lambda had to wrap the app in a translation layer between the Lambda event and the format expected by the framework (libraries like serverless-http exist for exactly this purpose). Lambda Web Functions eliminates that step: you deploy the standard HTTP server itself, without rewriting routes or swapping the router for an event handler.

What changes in the billing and performance model

The most relevant difference for anyone running production workloads is billing. According to the official Lambda Web Functions documentation, the new model charges for active CPU time and memory, not for CPU time spent waiting on responses from external services, such as databases or other APIs.

This directly benefits workloads that spend much of their execution time waiting on I/O: server-side rendering (SSR), API backends that query a database, and AI inference with streaming responses. Today, in those cases, the traditional Lambda model charges for the entire invocation time, including the wait.

Other relevant technical changes:

• A single "warm" execution environment now handles multiple concurrent requests, which significantly reduces the occurrence of cold starts.
• There's native support for response streaming, including incremental output from language models.
• Multi-region routing automatically directs each request to the region closest to the user.
• Existing Lambda functions are now called Lambda Event Functions; nothing changes for those already using the traditional model.

Micah Walter, senior solutions architect at AWS, sums up the appeal of the change:

You can take a standard port-listening server built with Express, Hono, Fastify, or any Node.js framework, deploy it with a single command, and Lambda automatically handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, and no framework lock-in.

Micah Walter, senior solutions architect at AWS

Heads up: the concurrency model really changed

Here's the point that deserves care from anyone migrating existing code. In the traditional Lambda model, each invocation runs isolated, one at a time per execution environment. With Lambda Web Functions, the same warm environment processes several concurrent requests at once, exactly as a regular Express server running in a container would.

That's good for performance, but it breaks an assumption many teams had carried for years without realizing it: that they didn't need to worry about state shared between requests, because each invocation was isolated. User magnetik79, in a Hacker News thread, summed up the problem:

This is a big one - and nice to see something not entirely honed in AI. What looks great: Many workloads can now skip API Gateway entirely (...) this totally changes the current Lambda HTTP programming model - now you're no longer working with one invoke/one request - now you might need to be sync/mutex aware.

magnetik79, user on Hacker News

In practice, anyone migrating an existing Express app needs to review global variables, in-memory caches, and any state that assumed isolation per invocation. Code that never had to think about race conditions now does.

What happens to deployment and the domain

By default, the Lambda Web Functions endpoint uses a domain provided by AWS itself. For a custom domain, edge caching, or protection with AWS WAF, AWS's recommendation is to put Amazon CloudFront in front, using Lambda Web Functions as the origin.

In an article published about the launch, Julian Wood, Kim Wendt, and Samrat Karak built a sample application to show how a single execution environment handles many requests at once and how the application serves users globally. They sum it up:

Lambda Web Functions bring the serverless operating model to web applications without adapter layers. You write a standard Node.js HTTP server, deploy it with one command or CloudFormation, and get a scalable, pay-per-use HTTPS endpoint with global routing built in.

Julian Wood, Kim Wendt, and Samrat Karak

Who's left out, for now

Lambda Web Functions supports only Node.js. Python, Java, and .NET remain available only through the traditional Lambda model (now called Lambda Event Functions). According to the source, there's no announced date for extending support to other languages.

It's worth remembering that, in early 2026, AWS had already launched Lambda MicroVMs, aimed at isolated, stateful sandbox environments, for running untrusted or user-generated code, with a lifecycle managed by the customer itself. These are complementary products: one solves isolation for arbitrary code, the other solves serving HTTP traffic with the programming model of a conventional framework.

What about developers in Brazil?

Here's the most practical point for Brazilian teams evaluating the migration: Lambda Web Functions is available, for now, in only five regions: Northern Virginia, Ohio, Oregon, Tokyo, and Ireland. São Paulo isn't on the list.

This means that, today, any app migrated to the new model and serving users in Brazil will operate with extra latency until AWS expands availability to sa-east-1, or until the team chooses to put CloudFront in front to mitigate part of the network impact (CloudFront has a point of presence in Brazil, but the origin remains in one of the five current regions). For internal APIs or workloads that already have most of their infrastructure hosted in the US, the impact is smaller; for apps that mostly serve Brazilian users with tight latency requirements, it's worth waiting for the regional expansion before migrating critical workloads.

Not exclusive to AWS

The model that Lambda Web Functions adopts (no adapter layer, automatic scaling, and configurable concurrency) already exists in other clouds. Google Cloud Run and Azure Container Apps offer similar propositions: running web applications without an adapter, with scale-to-zero and configurable concurrency, aimed at intermittent or bursty traffic loads.

The practical difference lies in the billing details and the networking model. Anyone already evaluating Cloud Run or Container Apps for Node.js workloads now has one more concrete comparison option within the AWS ecosystem itself, without needing to leave the platform to gain this simpler programming model.