AWS Lambda Web Functions keep billing memory ~7 minutes after the last request(www.easel.sh)
64 pointsby seanw2657 hours ago11 comments
  • perpil6 hours ago
    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.

    • seanw2653 hours ago
      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.

      • perpil2 hours ago
        > 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.

        Yes, if you run at least 100 coldstarts and ignore the hardware, you'll get a good real world representation. I usually execute the function every 8 minutes for a day so I get a good sample size. If you're curious to see the difference that hardware makes on coldstart times, I have a recent writeup here: https://speedrun.nobackspacecrew.com/blog/2026/10/15/shrinki...

        > 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.

        Yes this is correct. I got the impression you weren't trying to do any extra work after the request which is why I was suggesting that event functions would be cheaper for use cases that are mostly coldstarts.

    • seanw2655 hours ago
      [dead]
  • netik6 hours ago
    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.

    • seanw2656 hours ago
      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.

      • torginus5 hours ago
        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.
        • seanw2655 hours ago
          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.

  • jedberg4 hours ago
    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.
  • vrosas3 hours ago
    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.
    • pjmlp2 hours ago
      Usually most companies marry themselves with a specific cloud provider, the whole value proposition is buying into the provider ecosystem.

      If you do everything agnostic, it is hardly any cheaper than running everything on prem, as per the amount of infrastructure people required.

  • bilalq5 hours ago
    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.
  • catlifeonmars7 hours ago
    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.
    • seanw2656 hours ago
      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.

      • otterley3 hours ago
        Did you speak with the service team before making a decision to evacuate? What did they say about it?
      • Onavo5 hours ago
        Vercel's Fluid Compute (probably built on the same underlying stack given that AWS is their investor) has a much more "correct" behavior
  • psanford5 hours ago
    How does this compare to what gcp cloudrun does?
    • hnav4 hours ago
      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.
      • vrosas4 hours ago
        Correct. The instance stays alive but you only get billed for the time it's actively handling the request/job.
  • 7 hours ago
    undefined
  • hoppp7 hours ago
    Isn't that a configurable parameter?
    • seanw2656 hours ago
      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...

    • ceejayoz7 hours ago
      Yes. Buried several paragraphs past the headline is a note saying "AWS documents this behavior."

      This is marketing for a Lambda competitor.

      • Hnrobert426 hours ago
        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.
      • stymaar7 hours ago
        What's the default though? Because if the 7min thing happen with default settings, then it's definitely blog post worthy.
      • seanw2656 hours ago
        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.

  • nickphx5 hours ago
    My, what a beautiful bike shed you have there.
  • 7 hours ago
    undefined