It isn't clear what you mean by this: "The cold-start comparison has only two paired samples" Are you saying these results are based on a sample size of 2 coldstarts? If so, that's way too small to draw any conclusions. I don't know whether the web functions fleet is currently homogeneous, but I know that for ARM, the event functions fleet has a mix of Graviton2/3/4 of varying percentages. You probably need a sample size of at least 100 for each cpu generation to see trends.
It's not documented but if you make one request with event functions, the Lambda runtime lives for about 7 minutes before it's reaped. I assume this is why the Web Function bills you for about 7 minutes of memory, it needs to hold that memory while it's running in case another request comes in. If you have a lot of rarely invoked functions, it is cheaper to use Lambda Event Functions. There you'll pay for GB/s for the duration of your function.
For Event Functions with node, your best possible E2E coldstart time with an AWS service call is sub 500 ms https://speedrun.nobackspacecrew.com/blog/2025/07/21/the-fas... I have not benchmarked web functions yet, but if they are running on the same infrastructure, I would assume the lower limit is similar.
Yes, the sample was two cold starts. The warm request benchmarks used 100 samples per route.
You raise a good point about the hardware generations. I would like to do a larger sample, though I'm not so concerned about benchmarking each cpu separately since deployers can't control the hardware their functions run on.
IMO your thought about the idle lifetime is plausible. But the distinction between how Event and Web functions handle idle time (outside of billing) is that Event functions are frozen after the invocation completes. No code can execute while frozen. Whereas Web functions stay alive during that entire period. They can do anything they want after the invocation completes and before they are shut down.
I confirmed this by logging heartbeats during the idle period.
That is true for traditional Lambda Event Functions, but this post concerns the newly released Lambda Web Functions.
And you can exit Web Functions early, but AWS records it as a failure and I can’t say what would happen to requests in flight but haven’t reached your function yet. It’s not something I was comfortable relying on.
I still wonder why people use lambda over something like GCP's cloud run, although based on my conversations with peers that come from AWS shops they've been living in Amazon's world so long they don't even know it exists.
Lambda is built for the generic case. Amazon was kind enough to open source firecracker, which is what they built Lambda on. If you want to run workloads that are more specific than what Lambda supports, it's pretty straightforward to use firecracker to build your own optimized Lambda.
I'm actually really happy to see that the function remains active for 5-7 minutes after the last request. This gives a healthy amount of time to flush telemetry, send error reports, etc. This was one of my biggest worries. The small 1 second window on SIGTERM events didn't feel like enough.
Does the ~7 minutes get amortized over sustained load (due to container reuse)? I feel like the article doesn’t consider the shape of the traffic and workloads in its analysis of why lambda is not a good fit.
In general I think the answer to your question is yes. If you have sustained load, the environment will often be reused. When that happens, there is little “idle” time that you’re billed for.
I don’t mean to imply that Lambda Web Functions are a bad fit for every workload, just that they are a bad fit for our workload as a result of this behavior.
Edit: I made an update to the post to hopefully clarify this.
Historically cloudrun containers didn't get torn down immediately but stopped getting scheduled on the CPU once the ingress went idle. You'd only get billed for active time. Since 2021 you can have opt for always-on containers.
Not as far as I can tell. Web Functions let you configure concurrency, maximum environment count, and request rate limits, but there's no setting for how long an environment stays alive after its last request. The configurable timeout applies to individual requests, not the environment itself.
I measured between 5 and 7 minutes of idle time (after the last request had ended) across six environments. I was able to cut this short by exiting the process myself, but AWS records this as a runtime error so IMO it's not suitable to rely on in production.
Here's the AWS scaling documentation. I'm happy to be corrected if I missed anything.
Hmm. Are you sure? The article says AWS documents the behavior, but there is no way to configure it. They tried forcing an early shutdown, but that caused AWS to record an error event.
What's documented is that memory is billed for as long as the environment is active. What's not documented is how long those environments actually remain alive after their last request, and there's no configurable idle timeout.
And for context, Easel.sh is an alternative to Vercel, not AWS. Easel actually uses traditional Lambda as part of its core infrastructure. I was hoping Web Functions could replace some of the custom infrastructure we'd built on top of it, but the idle-memory billing made it a poor fit for our workload.
It isn't clear what you mean by this: "The cold-start comparison has only two paired samples" Are you saying these results are based on a sample size of 2 coldstarts? If so, that's way too small to draw any conclusions. I don't know whether the web functions fleet is currently homogeneous, but I know that for ARM, the event functions fleet has a mix of Graviton2/3/4 of varying percentages. You probably need a sample size of at least 100 for each cpu generation to see trends.
It's not documented but if you make one request with event functions, the Lambda runtime lives for about 7 minutes before it's reaped. I assume this is why the Web Function bills you for about 7 minutes of memory, it needs to hold that memory while it's running in case another request comes in. If you have a lot of rarely invoked functions, it is cheaper to use Lambda Event Functions. There you'll pay for GB/s for the duration of your function.
For Event Functions with node, your best possible E2E coldstart time with an AWS service call is sub 500 ms https://speedrun.nobackspacecrew.com/blog/2025/07/21/the-fas... I have not benchmarked web functions yet, but if they are running on the same infrastructure, I would assume the lower limit is similar.
Yes, the sample was two cold starts. The warm request benchmarks used 100 samples per route.
You raise a good point about the hardware generations. I would like to do a larger sample, though I'm not so concerned about benchmarking each cpu separately since deployers can't control the hardware their functions run on.
IMO your thought about the idle lifetime is plausible. But the distinction between how Event and Web functions handle idle time (outside of billing) is that Event functions are frozen after the invocation completes. No code can execute while frozen. Whereas Web functions stay alive during that entire period. They can do anything they want after the invocation completes and before they are shut down.
I confirmed this by logging heartbeats during the idle period.
Thanks for your thoughtful comment.
This a bit of a “yeah, so?” Statement.
You can configure teardown and minimum workers, and with a busy site, most of the time requests aren’t going to stop enough for this to matter.
Yes for sure, if your web function is very active this is less of an issue. But not every workload fits that mold.
Also: afaict idle time before teardown is not configurable.
I'm pretty sure if you quit your lambda process the container will just shut down. You can do that after returning from the handler.
That is true for traditional Lambda Event Functions, but this post concerns the newly released Lambda Web Functions.
And you can exit Web Functions early, but AWS records it as a failure and I can’t say what would happen to requests in flight but haven’t reached your function yet. It’s not something I was comfortable relying on.
I still wonder why people use lambda over something like GCP's cloud run, although based on my conversations with peers that come from AWS shops they've been living in Amazon's world so long they don't even know it exists.
Lambda is built for the generic case. Amazon was kind enough to open source firecracker, which is what they built Lambda on. If you want to run workloads that are more specific than what Lambda supports, it's pretty straightforward to use firecracker to build your own optimized Lambda.
Yes, that's exactly what we did.
https://www.easel.sh runs on it.
> it's pretty straightforward to use firecracker to build your own optimized Lambda
I take it, then, that you've successfully accomplished this yourself in production?
Yes. We built a cloud that was 10x more efficient than lambda for durable workloads.
https://docs.dbos.dev/conductor/reference/dbos-cloud/deployi...
I'm actually really happy to see that the function remains active for 5-7 minutes after the last request. This gives a healthy amount of time to flush telemetry, send error reports, etc. This was one of my biggest worries. The small 1 second window on SIGTERM events didn't feel like enough.
Does the ~7 minutes get amortized over sustained load (due to container reuse)? I feel like the article doesn’t consider the shape of the traffic and workloads in its analysis of why lambda is not a good fit.
In general I think the answer to your question is yes. If you have sustained load, the environment will often be reused. When that happens, there is little “idle” time that you’re billed for.
I don’t mean to imply that Lambda Web Functions are a bad fit for every workload, just that they are a bad fit for our workload as a result of this behavior.
Edit: I made an update to the post to hopefully clarify this.
Did you speak with the service team before making a decision to evacuate? What did they say about it?
Vercel's Fluid Compute (probably built on the same underlying stack given that AWS is their investor) has a much more "correct" behavior
How does this compare to what gcp cloudrun does?
Historically cloudrun containers didn't get torn down immediately but stopped getting scheduled on the CPU once the ingress went idle. You'd only get billed for active time. Since 2021 you can have opt for always-on containers.
Correct. The instance stays alive but you only get billed for the time it's actively handling the request/job.
Isn't that a configurable parameter?
Not as far as I can tell. Web Functions let you configure concurrency, maximum environment count, and request rate limits, but there's no setting for how long an environment stays alive after its last request. The configurable timeout applies to individual requests, not the environment itself.
I measured between 5 and 7 minutes of idle time (after the last request had ended) across six environments. I was able to cut this short by exiting the process myself, but AWS records this as a runtime error so IMO it's not suitable to rely on in production.
Here's the AWS scaling documentation. I'm happy to be corrected if I missed anything.
https://docs.aws.amazon.com/lambda/latest/dg/web-functions-s...
Yes. Buried several paragraphs past the headline is a note saying "AWS documents this behavior."
This is marketing for a Lambda competitor.
Hmm. Are you sure? The article says AWS documents the behavior, but there is no way to configure it. They tried forcing an early shutdown, but that caused AWS to record an error event.
What's the default though? Because if the 7min thing happen with default settings, then it's definitely blog post worthy.
What's documented is that memory is billed for as long as the environment is active. What's not documented is how long those environments actually remain alive after their last request, and there's no configurable idle timeout.
And for context, Easel.sh is an alternative to Vercel, not AWS. Easel actually uses traditional Lambda as part of its core infrastructure. I was hoping Web Functions could replace some of the custom infrastructure we'd built on top of it, but the idle-memory billing made it a poor fit for our workload.
I thought the findings were worth sharing.
My, what a beautiful bike shed you have there.