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

Easel tested AWS Lambda Web Functions as a possible replacement for its custom infrastructure, but found that execution environments kept running - and accruing memory charges - for 313-411 seconds after their last request. Memory made up about 88% of calculated compute and request costs in the experiment, despite the app using only 160-210 MB. A 200-millisecond request followed by 345 seconds of inactivity meant roughly 1,700 times the request duration in metered memory time. Attempts to terminate idle environments after ten seconds cut billed time but caused AWS to record runtime failures. Because Easel serves many applications with unpredictable traffic, it chose to run applications on its own shared servers and use Lambda only for overflow.

On the same Next.js 16 application, Easel’s host delivered warm requests 1.5-3 times faster across JSON APIs, server rendering, streaming, and a CPU-intensive route; chained SHA-256 operations were also about 1.5 times faster. After twelve minutes idle, its cold starts took 216-250 milliseconds, compared with 810-854 milliseconds on Lambda. In one five-minute-idle comparison, Easel resumed in 14 milliseconds while Lambda took 908. These are preliminary results, not a broad performance study: measurements came from one region, the systems used different hardware and configurations, and the cold-start comparison included only two paired trials. Easel accepts added infrastructure responsibilities in exchange for control over capacity and idle costs; Lambda may remain attractive for applications with sustained traffic.