AWS Lambda Web Functions Kept Billing Memory Minutes After Requests Ended, Easel Reports
Easel reports that its AWS Lambda Web Functions execution environments kept running and accruing memory charges for five to seven minutes after their last request. The company published the findings on November 11, 2026, in a blog post.
Easel measured six representative environments in us-east-1 on October 26, timing the interval from the last completed request. Idle periods ranged from 313 to 411 seconds. By Easel's calculation, a 200 ms request followed by 345 seconds of inactivity equals roughly 1,700 times the request duration in metered memory time. In other words, the meter kept ticking long after the work was done, much like a parking meter running after the driver has walked away.
Memory was the largest line item. Easel reports that memory accounted for approximately 88% of its calculated compute and request costs at published list prices. The application in the experiment used around 160 to 210 MB, and the memory allocation, not the work performed during the request, dominated the bill.
AWS's pricing page describes each function type differently. Lambda Event Functions are priced on requests served and duration in GB-seconds, which is memory multiplied by time. Lambda Web Functions are priced on requests and active CPU time. Lambda MicroVMs are priced per instance-second. Customers choose the memory allocated to a function, from 128 MB to 10,240 MB in 1 MB increments, and receive CPU and other resources in proportion to that choice. The free tier includes one million requests and 400,000 GB-seconds per month.
Easel also tested a mitigation. Terminating environments itself after 10 seconds of inactivity reduced metered environment time by roughly 20 times. AWS, however, recorded every intentional exit as a runtime failure. The cost saving and the error signal arrived together. Easel separately reported that its first self-operated compute host went live in US East on November 2.
In my view, the gap that matters most sits between how a pricing model is summarized and how the meter actually runs. A team that reads "active CPU time" on a pricing page and then sees memory dominate its invoice has a reconciliation problem. A team that sees "runtime failure" in its dashboards may spend an afternoon chasing errors that, by design of the shutdown, are not errors at all. Neither problem is exotic, and both usually surface only after the bill arrives.
The broader context here is that idle behavior comes from how the platform manages environment lifecycles, while the cost lands on the customer's memory allocation decisions. Right-sizing memory, measuring idle windows, and deciding whether a self-managed shutdown justifies the overhead of classifying failures are all engineering choices. Numbers at this granularity let teams weigh those trade-offs before they show up on an invoice.
