For about ten years, putting a normal web app on Lambda meant bending it out of shape. You wrapped Express in an adapter, accepted that each environment handled one request at a time, and paid for every millisecond your function sat waiting on a database. Plenty of teams looked at that deal and stayed on containers.
On 12 October AWS announced Lambda Web Functions, and most of that friction is gone.
A Web Function is a plain HTTP server. Your Express, Hono, Fastify or Next.js app listens on the port Lambda gives it, and that is it. No handler rewrite, no adapter library. One environment can serve up to 128 requests at the same time, so a burst of traffic lands on warm environments instead of spinning up a new one per request.
The billing change is the part we keep coming back to. Web Functions charge for CPU time, not wall-clock time. If your API spends most of each request waiting on Postgres or a third-party service, that waiting is now cheap. Memory is still charged for as long as the environment is alive, so this is not free money, but for typical I/O-heavy web traffic the maths moves a long way in Lambda's favour.
The fine print
At launch it is Node.js 24 on Arm only. Python, Java and Go shops will have to wait. It is available in five regions: North Virginia, Ohio, Oregon, Tokyo and Ireland. Mumbai is not on the list, which matters for Indian teams with data residency rules or latency budgets that assume an Indian region.
You can deploy to several regions and AWS will put them behind one global URL with latency-based routing. AWS describes this as best effort, so read that as a convenience rather than a disaster recovery plan. Traffic splitting between revisions is built in, which makes canary releases simpler than they are today with aliases.
AWS did not publish new prices in the announcement. It points to the standard Lambda pricing page. Until real bills come in, any claim that this is cheaper than Fargate or ECS for your workload is a guess.
So, containers or this?
If you run a handful of Node APIs on ECS or a small Kubernetes cluster mostly because the old Lambda model did not fit, this is worth a proper trial. You lose cluster upgrades, node patching and capacity planning. You also lose some control, and you take on a new form factor that is days old.
If your web tier is polyglot, needs long-lived connections, or already runs well on Kubernetes with a team that knows it, there is no rush. Nothing here forces a move.
What we would do this month is boring and useful. Pick one internal Node service with spiky traffic, run it as a Web Function next to its current home for two weeks, and compare the bills and the p99 latency. That gives you a real number to put in front of whoever signs off cloud spend, instead of a vendor blog post.
It also gives you an early read on cold starts, which AWS did not talk about in the launch post. That silence is worth testing for yourself.
