Lambda Web Functions vs Event Functions: Where the New Model Saves Money, and Where It Doesn't

Web Functions bill active CPU and held memory; Event Functions bill wall-clock time multiplied by memory. For AWS's own three example workloads, classic Lambda at 512 MB is cheaper. Once requests spend seconds waiting (LLM streaming, slow APIs, long polls) Web Functions win by 40 times or more: a 10-second stream costs about $3 per million requests instead of $134. The arithmetic, the crossover and a checklist.

Lambda now has two ways to run request handlers. Event Functions are the classic model: one request per environment, billed on duration multiplied by configured memory. Web Functions, launched in October 2026, run your HTTP server with many requests per environment, billed on the CPU time your code actually uses plus the memory the environment holds. Which is cheaper depends on one ratio: how long a request waits compared with how long it computes.

The crossover: wall-clock time

Event Functions charge for every millisecond a request is open, so cost grows with waiting. Web Functions charge for CPU, so a request that spends 10 seconds waiting on a model and 50 ms computing costs the same as one that answers in 100 ms, plus its share of the environment's memory. With a 10-second stream that is about $1.68 per million requests in requests and CPU, plus memory: around $3 in total for a steadily used environment, against $134 on Event Functions.

AWS's own examples, priced both ways

At short durations the comparison turns on memory. If your function runs comfortably at 512 MB, classic Lambda is cheaper for these shapes. If it needs 1 GB or more for CPU (Lambda allocates CPU in proportion to memory), Web Functions come out ahead even here.

The idle tail: what an environment costs after its last request

Memory is billed for as long as an environment runs, and an environment does not stop when its last request ends. Easel, a hosting platform, measured how long: in its tests in us-east-1, Web Function environments kept running, and accruing memory charges, for 313 to 411 seconds after their last request. There was no setting to shorten that. Memory came to about 88% of Easel's compute and request costs, and making environments exit after 10 idle seconds cut metered time by roughly 20 times, but Lambda recorded every one of those exits as a runtime failure.

• One tail of about 400 seconds at 1 GB costs about $0.0015 in memory. A single 200 ms request on Event Functions at 1 GB costs about $0.0000027, so for occasional traffic the tail alone costs several hundred times the request it followed.

• If requests arrive more often than every five minutes or so, the environment never stops, and memory runs all month: about $9.50 per GB for each environment, before any request is served.

• The model above treats that memory as a floor shared by many requests. That only holds with steady traffic. For bursty or occasional traffic, price the tails as well.

Easel's full write-up, with its measurements, its burst test and a benchmark against its own compute: Why we chose our own compute over AWS Lambda Web Functions, by Sean Whiteman, November 11, 2026.

Where Web Functions win

• Streaming LLM responses, where requests stay open for seconds while the model generates.

• APIs that call slow downstream services: third-party APIs, payment providers, legacy systems.

• Server-sent events and long polling.

• Frameworks that already are an HTTP server (Express, Hono, Next.js), where an adapter added latency and cold starts.

• Steady traffic, where one environment's memory is shared across many requests.

Where Event Functions still win

• Short, CPU-light handlers that fit in 512 MB or less.

• Event processing: queues, streams, schedules, S3 notifications. Web Functions are for HTTP.

• Rarely called endpoints, where a Web Function environment's held memory would be the whole bill.

• Code with module-level state that isn't safe to share between simultaneous requests.

And against containers

The same I/O-heavy API on Fargate needs at least two small tasks for availability (0.25 vCPU, 0.5 GB on Arm: about $14 a month together) plus a load balancer (about $16 a month in hourly charges, before capacity units): roughly $35 a month before it serves a request, against about $20 on Web Functions. Containers win back ground at sustained high load, or when you need long-running processes, sidecars or more control than Lambda gives.