You Don't Pay for the Wait: Lambda Web Functions for AI
I priced AWS's own Lambda Web Functions examples under both billing models. The LLM endpoint got 3x cheaper. The other three got up to 2x more expensive. Here is the rule that tells them apart.
AWS launched Lambda Web Functions on October 12: your code listens on a port, serves HTTP like any web server, and one warm environment handles up to 128 requests at once. Existing functions are now called Event Functions.
The part I care about most is the bill. Event Functions charge for wall-clock time. Web Functions charge for active CPU time plus the memory your environment holds. For an AI endpoint that spends most of its life waiting for a model to stream tokens, that is a big change.
So I took the four pricing examples AWS published for Web Functions and priced each of them as an Event Function too. The LLM streaming endpoint came out three times cheaper on Web Functions. The other three came out between 1.5 and 2.2 times more expensive.
Two billing models in one paragraph
An Event Function pays for every millisecond the request is open, multiplied by its memory: $0.0000133334 per GB-second on Arm, plus $0.20 per million requests. A Web Function pays $0.0000276944 per second of active vCPU, $0.0000036667 per GB-second of memory for as long as the environment exists, and $0.30 per million requests. Waiting on a database, an API or a model uses almost no CPU, so on a Web Function it is nearly free.
In other words: the Event Function price is per second of waiting, and the Web Function price is per second of working. Which one is cheaper depends on how much of each request your code actually works.
AWS's examples, priced both ways
AWS's pricing page lists four Web Functions workloads in us-east-1 on Arm, each running on a single environment for a month. I kept everything the same, memory and end-to-end duration included, and priced them as Event Functions.
| Workload (from the AWS pricing page) | Requests / month | Time per request | Active CPU | Event Function | Web Function |
|---|---|---|---|---|---|
| Server-side rendered web app | 15M | 150 ms | 40 ms (27%) | $17.70 | $25.78 |
| I/O-heavy API backend | 10M | 200 ms | 50 ms (25%) | $9.73 | $19.61 |
| Authorization middleware | 100M | 50 ms | 12 ms (24%) | $29.33 | $64.56 |
| LLM streaming endpoint | 5M | 3,000 ms | 200 ms (7%) | $101.00 | $33.94 |
What I read from this
The LLM endpoint is the case Web Functions were built for. A request is open for 3 seconds but works for 200 ms. An Event Function bills all 3 seconds; a Web Function bills the 200 ms and lets six concurrent streams share one environment's memory. $101 becomes $34.
For short requests, active CPU is the expensive part. A vCPU-second on a Web Function costs about twice a GB-second on an Event Function. When a request works a quarter of its time, as in the other three examples, the cheaper unit of time loses to the more expensive unit of CPU.
High request volume adds up. Web Functions charge $0.30 per million requests instead of $0.20. For the authorization middleware with 100 million requests, that difference alone is $10 a month.
The rule of thumb
Divide the Event Function price per GB-second by the Web Function price per vCPU-second and you get 0.48. That gives a simple break-even:
A Web Function is cheaper when the share of time your code is busy on the CPU is lower than 0.48 times its memory in GB.
At 512 MB, that is about 24%. If your code spends less than a quarter of each request working and the rest waiting, Web Functions win. Most AI endpoints that call Bedrock or any other model API wait far longer than that. A typical REST API that does a quick database read and some JSON does not.
The rule ignores the memory charge and the request charge, which both favour Event Functions slightly, so treat it as a first filter, not a quote.
The decision I would argue for
Move your AI endpoints first: streaming chat, agent APIs, anything that holds a request open while a model thinks. Leave short, CPU-bound handlers on Event Functions until you have measured them, even if the HTTP programming model is nicer.
Cost is not the only reason to switch. One environment serving many requests also means far fewer cold starts, and the HTTP model means no adapters around Express or Hono. Those benefits can be worth paying more for. Just know you are paying.
The limits of this comparison
These are AWS's example workloads, not my production traffic, and I priced them in us-east-1. I assumed the same memory and the same end-to-end time in both models. In reality an Event Function with little memory also gets less CPU, so its requests can take longer, and the AWS examples run one environment all month, which suits steady traffic better than spiky traffic. The Web Functions pricing page does not say how long an idle environment stays alive and billed.
Next I will deploy the same Bedrock streaming endpoint as both an Event Function and a Web Function and measure the real numbers: cold starts, environments, billed time and cost per 1,000 AI requests.
Event Functions bill the wait. Web Functions bill the work. Before you migrate, find out which one your code mostly does.
Sources
- Announcing AWS Lambda Web Functions (AWS News Blog): https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/
- AWS Lambda announces Lambda Web Functions (What's New): https://aws.amazon.com/about-aws/whats-new/2026/10/aws-lambda-web-functions/
- AWS Lambda pricing (Web Functions examples and rates): https://aws.amazon.com/lambda/pricing/
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article