By ByteBot
AWS shipped a new Lambda function type on October 12. Lambda Web Functions lets you run a standard HTTP server — Express, Hono, Fastify, Next.js — directly on Lambda. No adapter library. No JSON event handler wrappers. Your framework code runs as-is. That’s the easy part. The more interesting part: AWS changed Lambda’s billing model and concurrency model at the same time, and for the right workloads, the cost difference lands around four-to-one.
One Environment Variable, One Command
The entire code change to make an existing Express app work on Lambda Web Functions:
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(Number(port), host);Replace your hardcoded app.listen(3000) with this. Locally, AWS_LAMBDA_HTTP_ENDPOINT is unset, so your server still binds to localhost:3000 the way it always did. On Lambda, it reads the host and port Lambda provides. Your routes, middleware, and error handlers are untouched.
Deploy with:
aws lambda-web deploy --name my-api --code ./my-appAWS bundles your source, creates the Web Function, publishes a revision, attaches an HTTPS endpoint, and returns a live URL. The whole process takes roughly 25 seconds. Classmethod tested it in Tokyo and confirmed streaming responses work reliably — server-sent events arrived at 993 to 1002ms intervals consistently.
This replaces the previous approach of bolting on serverless-http, @vendia/serverless-express, or configuring the Lambda Web Adapter layer — all of which required framework-specific wiring and added their own failure surface. That tooling is now effectively obsolete for Node.js teams on Lambda.
The Concurrency Shift
The old Lambda model runs one request per execution environment. If 50 users hit your API simultaneously, Lambda may spin up 50 separate environments — 50 cold starts. The warm environment that handled request 1 cannot handle request 2 if they arrive at the same time.
Lambda Web Functions changes this. A single execution environment handles up to 64 concurrent requests by default (configurable up to 128). Fifty simultaneous requests typically require one warm environment. Cold start frequency drops by roughly the same factor as your concurrency-per-environment setting.
For bursty APIs, streaming endpoints, or anything that holds open connections, this matters. Cold starts have been the most common Lambda production complaint for years. Web Functions reduces the problem by roughly 64x without any code changes.
Where the Billing Model Changes
Traditional Lambda (“Event Functions” in the new naming) bills on wall-clock time. Every millisecond your function waits on a database query, downstream API call, or streaming response counts against your bill. Lambda Web Functions bills on active CPU time only. Idle I/O wait time costs almost nothing.
The difference shows up most dramatically for LLM inference endpoints. A function streaming tokens for three seconds might use 200ms of actual CPU. Event Functions bill for three seconds. Web Functions bill for 200ms. A detailed cost analysis shows what this looks like at scale:
| Workload | Web Functions | Event Functions |
|---|---|---|
| LLM streaming (5M req/month, 3s total, 200ms CPU) | $33.94 | $126 |
| I/O-heavy API (10M req, 200ms total, 50ms CPU) | $19.61 | $18.67 |
| SSR app (15M req, 50ms CPU per request) | $25.78 | $21.75 |
Web Functions win when most of a request’s wall-clock time is spent waiting. For CPU-intensive work — image processing, computation — where request time is mostly CPU time, the billing advantage disappears or reverses. The SSR row shows Web Functions costing slightly more when CPU usage per request is high relative to total duration.
If your Lambda functions spend significant time waiting on external services, a database, or streaming output, calculate your specific workload against these numbers before assuming savings.
Read This Before You Deploy
The aws lambda-web deploy command creates a public, unauthenticated endpoint by default. The auth type is ApplicationManaged, which means anyone with the URL can call it. For a production account or shared team environment, specify IamAuth explicitly:
aws lambda-web deploy --name my-api --code ./my-app --auth-type IamAuthAWS has published Service Control Policies to enforce authentication across an organization via the lambda:Request/WebFunctionAuthType condition key. Set that up before your team starts testing so no one accidentally exposes an endpoint.
Current Limitations
Lambda Web Functions is genuinely useful at GA, but the initial release has real constraints:
- Runtime: Node.js 24 on Arm64 only. No Python, Java, or Go at launch.
- Regions: Five regions: us-east-1, us-east-2, us-west-2, ap-northeast-1, eu-west-1. No South America or other Asia Pacific.
- Memory: 2 GB per environment, shared across all in-flight concurrent requests. V8’s default heap is 1,024 MB — watch this under high concurrency.
- Global state: With 64+ concurrent requests per environment, mutable module-level state becomes a race condition. Write stateless handlers.
- IaC: CloudFormation and Terraform support exists but documentation is sparse. SAM and CDK work better.
- Cleanup: Deleting a Web Function leaves behind IAM roles, S3 source packages, and CloudWatch log groups. Manual cleanup required.
LocalStack 2026.10.0 already emulates Lambda Web Functions for local testing — useful to know if your team runs LocalStack in CI. AWS also released Lambda MicroVMs earlier this year as a separate compute primitive for agent sandboxing — a different use case but relevant context for teams building on Lambda’s expanded form factors.
When to Switch
Lambda Web Functions makes sense now if your team works in Node.js, you’re already using or planning Express, Hono, or Fastify on Lambda, and you have workloads with significant I/O wait time — particularly AI inference endpoints or streaming APIs. The combination of fewer cold starts and active-CPU billing makes the case clearly for those patterns.
Wait if you need Python, Java, or Go runtimes (no timeline announced), deploy to regions not on the current list, rely heavily on Terraform or CloudFormation, or run CPU-bound workloads where wall-clock time and CPU time are roughly equal.
The larger shift here is that AWS is gradually unbundling Lambda’s pricing model. Web Functions is the first Lambda form factor where you pay for what the CPU actually does — and for the workloads driving most serverless adoption in 2026 (AI inference, streaming APIs, I/O-heavy microservices), the difference is large enough to check your numbers now.
