AWS Lambda Web Functions keep billing memory ~7 minutes after the last request

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.

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.

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.

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.

How does this compare to what gcp cloudrun does?

Isn't that a configurable parameter?

My, what a beautiful bike shed you have there.