AWS has announced Lambda Web Functions, a third way to run code on Lambda built for ordinary HTTP applications: you start a server listening on a port, without rewriting it as an event handler. According to the announcement it works with Express, Hono, Fastify, Next.js or any Node.js framework, and no adapter is needed.
What changes
Until now Lambda meant event functions: one request per execution environment, billed by wall-clock time. Web Functions change that model in several ways:
- Multi-concurrency: up to 128 concurrent requests per execution environment.
- Billing: CPU time is metered, so time spent waiting on I/O uses little billable CPU. Memory is metered for as long as the environment exists.
- Launch runtime: Node.js 24 (
nodejs24.x) on Arm64, and nothing else for now. - Contract: Lambda sets
AWS_LAMBDA_HTTP_ENDPOINTto the host:port your server must bind to. Locally you set it yourself. - Deployment: one CLI command creates the function, publishes a revision and returns an HTTPS URL.
aws lambda-web deploy --name my-api --code ./dist
# several regions behind one global URL (latency-based routing, best-effort)
aws lambda-web deploy --name my-api --code ./dist --regions us-east-1,eu-west-1,ap-northeast-1For canaries there is aws lambda-web update-web-function-endpoint with --revision-weights (the announcement's example is a 90/10 split) and --auto-deployment-mode Disabled. The endpoint can be a CloudFront origin with origin access control, so it only accepts requests from your distribution. VPC connectivity is supported.
Initial regions: N. Virginia, Ohio, Oregon, Tokyo and Ireland. Across Lambda's three forms (event functions, Web Functions and MicroVMs) isolation is still Firecracker.
Why it matters in production
The one-request-per-environment model makes you pay for the time your code waits on a database or an external API. With 128 requests per environment and CPU-based billing, I/O-heavy services may get cheaper and see fewer cold starts, although the announcement gives no price figures and points to the Lambda pricing page.
Multi-concurrency also brings the usual server problems: state shared between requests, connection pools sized for 128 simultaneous clients, memory leaks that now hit many requests at once, and shared CPU. If you come from event functions, any global variable you assumed was "yours" no longer is.
Mind the gaps too: Node.js 24 on Arm64 only, five regions, and best-effort multi-region routing. The announcement does not detail other quotas.
What I would do
- Try it on a low-risk, I/O-heavy service, not the critical path.
- Audit the code for module-level mutable state and size connection pools for real concurrency.
- Put CloudFront with OAC in front from day one so the endpoint is not left open.
- Use revision weights (90/10) to roll out and watch p99 latency, errors and CPU before shifting more traffic.
- Compare cost against your current setup using real traffic and the pricing page, not just the announcement.