Sabbir Amin
A promotional email from AWS landed in my inbox this week. The subject said Lambda now runs web apps. I almost archived it with the rest of the marketing mail, and I'm glad I didn't.
If you have ever folded a perfectly good web server into a Lambda handler, with an adapter in the middle and a quiet hope that local and cloud would behave the same, this one is for you. On October 12, AWS launched Lambda Web Functions. You write your app the way you already do, let it listen on a port, and Lambda runs it.
Why this one made me smile
Lambda has been with me for years. It is one of the AWS services I trust without a second thought: easy to pick up, it scales on its own, and it costs nothing when nobody is calling it. On static-first projects I often pair it with an Astro site. Astro serves the pages, and a handful of Lambda functions take care of forms, webhooks and the small pieces of server logic. That setup has been boring in the way you want production to be boring.
The awkward part was always bringing a normal web app along. A web framework expects to own a port and receive requests. Lambda expected an event object and a handler function. So you added an adapter, tested one way on your laptop and deployed another way to the cloud. Most of the time it worked. When it didn't, you lost an afternoon finding out why.
Web Functions removes that adapter layer, and that is what got me excited.
What Lambda serves now
Lambda is a small family today. The functions you already run are now called Event Functions, and they need no changes. Next to them sit Web Functions and MicroVMs, plus two options from re:Invent 2025 that extend the classic model.
| Option | What it is for | Arrived |
|---|---|---|
| Event Functions | The Lambda we know: one event at a time, triggered by S3, SQS, API Gateway and friends | 2014, renamed in 2026 |
| Web Functions | Standard HTTP servers that handle many requests at once | October 2026 |
| MicroVMs | A Firecracker VM per user or session for untrusted or AI-generated code, stateful, up to 8 hours, can suspend and resume | June 2026 |
| Managed Instances | Lambda running on EC2 in your own account, still patched and scaled by AWS, priced like EC2 for steady, high traffic | re:Invent 2025 |
| Durable Functions | Multi-step workflows that pause on timers, webhooks or human approval and resume with their state | re:Invent 2025 |
AWS gives a neat picture of how they fit together in one product: Event Functions for background jobs, Web Functions for the user-facing API and server-side rendering, and MicroVMs for running code that users or agents write.
How Web Functions differ
Your app stays a web server. Express, Hono, Fastify and Next.js are the frameworks AWS names, and a deploy is one command:
aws lambda-web deploy --name my-web-app --code ./my-appOne execution environment can serve up to 128 requests at the same time. Classic Lambda gives each request its own environment, so a slow database call keeps that environment busy. With Web Functions, the environment keeps serving other requests while one waits, and Lambda starts fewer new environments when traffic climbs.
Billing follows the same idea. You pay for the time the CPU is actually working, so waiting on a database or an LLM API adds no CPU charge. Memory is still billed while the environment is alive, along with requests and data transfer.
It also scales to zero. We used App Runner on several projects over the last few years, and I liked it: hand it a container, get back a URL. It always kept at least one instance running, though, even when nobody was visiting. AWS stopped taking new App Runner customers on April 30, 2026, and existing customers can keep using it. For a new Node.js app, Web Functions is where I would look first.
A few more things come built in. You can list several regions and get one global URL that sends each visitor to the closest one. CloudFront can sit in front, serving static files from cache, with origin access control so only your distribution can reach the function. Streaming responses, server-sent events, webhooks and IAM authentication all work through the same endpoint, which makes it a comfortable home for AI apps that stream tokens back to the browser.
Before you try it on a serious project
I'm excited, and I would still start small. Here is what I would keep in mind:
- It runs Node.js only, on Node.js 24 and Arm64. Python, Java and .NET stay on classic Lambda. Much of my backend work is Python and FastAPI, so for that code nothing changes yet.
- It is live in five regions: N. Virginia, Ohio, Oregon, Tokyo and Ireland. If your users are in South Asia, Tokyo is the nearest of the five.
- You get a Lambda-provided domain. A custom domain, edge caching or AWS WAF means putting CloudFront in front.
- Concurrency changes how you write code. Module-level variables that were safe when one environment served one request are now shared by up to 128 requests at once. Check for per-request data stored in globals before you move an old app over.
- Memory is billed for as long as an environment stays alive. Run the numbers against your own traffic before you assume it will be cheaper.
- It shipped on October 12, 2026. I would give it an internal tool or a side project first and keep the client work on what we already know.
If you have an Express or Hono app on your laptop right now, the hello world takes one command, and it's a gentle way to spend a Saturday morning:
aws lambda-web deploy --name hello-world --hello-worldOriginal story
The full announcement from AWS: Announcing AWS Lambda Web Functions
Further reading: