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

Why we chose our own compute over AWS Lambda Web Functions Lambda Web Functions kept billing memory for 5–7 minutes after the last request, so we built our own compute. On the same Next.js app, it answered warm requests 1.5–3× faster and cold-started about 3.5× faster. Author Sean Whiteman Founder, Easel.sh Published Nov 11, 2026 Reading time 4 min Engineering We built our own compute. Then benchmarked it against AWS. When AWS announced Lambda Web Functions in October, I was excited. At Easel , we'd spent months building infrastructure to run web applications efficiently on traditional Lambda. Native HTTP servers, concurrent requests, and active CPU billing sounded like exactly what we'd been looking for. If Web Functions worked the way we hoped, we could potentially replace a substantial amount of our custom infrastructure. So we decided to put them to the test. A few weeks later, we'd decided to run our own compute instead. And as it turns out, our own infrastructure was faster, too. The five-minute problem Our initial experiments were promising. Web Functions handled 300 concurrent requests without errors, and a new function was serving requests in under nine seconds. But we quickly ran into something that didn't work for us. Execution environments continued running and accruing memory charges for 5–7 minutes after their last request. Web Functions bill CPU only while it's actively used, but memory is billed for the entire lifetime of an execution environment, even when no requests are running. AWS documents this behavior . What surprised us was how long those environments remained alive. Across six representative environments, we observed idle periods ranging from 313 to 411 seconds. The processes remained active throughout, and there was no configurable idle timeout to shorten their lifetime. 5–7 min of memory billed after the last request Last request Idle, memory billed Lower is better 5 min 313s 355s 358s 391s 410s 411s 0 1m 2m 3m 4m 5m 6m 7m For a 200ms request followed by 345 seconds of inactivity, that's roughly 1,700 times the request duration in metered memory time . We checked the economics against CloudWatch and AWS Cost Explorer. Across our experiment, memory accounted for approximately 88% of the calculated compute and request costs at published list prices, even though our application only used around 160–210 MB. The entire experiment amounted to about two cents at list prices. Hardly alarming on its own. But Easel needs to support thousands of applications with unpredictable traffic. Some receive sustained traffic, while others might get only a few requests per day. At that scale, the cost of keeping independently metered environments alive starts to matter. We even tried terminating environments ourselves after 10 seconds of inactivity. That reduced metered environment time by roughly 20×, but AWS recorded every intentional exit as a runtime failure. It wasn't something we wanted to rely on in production. What if we ran the compute ourselves? Rather than adopt Web Functions, we decided to move application execution onto servers we operate ourselves, keeping traditional Lambda available for overflow. This gives us control over scheduling and resource allocation. We can share capacity across applications without paying AWS for each idle environment, and scale beyond our own infrastructure when demand requires it. Easel.sh edge Easel.sh compute Lambda overflow Serving Idle Our first self-operated compute host went live in US East on November 2, serving applications including Easel's own website. But taking ownership of the compute raised another question: How would our performance compare to AWS? We deployed the same Next.js 16 application to both platforms and ran a series of benchmarks from a client in Ashburn, Virginia. The results surprised us. 1.5–3× faster warm requests on the same Next.js app Easel.sh AWS Lambda Web Functions Median ms · lower is better JSON API 2.9 × 9.3 27.0 Server-side rendering 2.1 × 12.2 26.0 Streaming (first chunk) 2.0 × 9.1 18.1 CPU-intensive API 1.5 × 39.7 61.4 Our host delivered 1.5–3× faster median warm-request times across all four workloads. The difference wasn't limited to network or routing overhead. Running the same 20,000 chained SHA-256 operations took 29.2ms on our host versus 43.8ms on Web Functions, about 1.5× faster. And cold starts told a similar story. After leaving both applications idle for 12 minutes, we triggered fresh execution environments on each platform. 3.5× faster cold starts after 12 minutes idle Fastest to slowest of two trials Lower is better Easel.sh : 216 – 250 ms AWS Lambda Web Functions : 810 – 854 ms In both trials, Easel started serving requests about 3.5× faster . We also saw an interesting difference after a shorter idle period. Following one five-minute gap, Web Functions had already terminated its environment and needed 908ms to respond. Easel resumed its paused environment and responded in just 14ms. These are early results from a single region and a small application, not a comprehensive performance study. The cold-start comparison has only two paired samples, and we haven't benchmarked sustained throughput yet. Still, seeing our own infrastructure outperform AWS across these initial workloads was encouraging. Taking ownership of the infrastructure Running our own compute comes with additional responsibilities. We have to manage capacity, handle failures, and make sure resources are distributed efficiently across applications. But it also gives us the freedom to optimize the entire execution path, rather than working around the constraints of another platform. Web Functions may be a good fit for applications with sustained traffic, where idle memory costs are less significant. For Easel, the economics of running large numbers of independent applications led us in a different direction. And our initial benchmarks suggest that the decision doesn't have to come at the expense of performance. We're taking on more infrastructure complexity so developers using Easel don't have to. How we measured Dates Benchmarks ran November 11–12, 2026 (UTC). Idle-memory measurements are from October 26, 2026. Setup The same Next.js 16 application on Easel's self-operated US East host and on AWS Lambda Web Functions in us-east-1. Client One client in Ashburn, Virginia. Timing Time to first byte, excluding TLS connection setup but including network transit and platform routing. Samples About 100 requests per route per platform for warm requests. Two paired trials for cold starts. Hardware The platforms ran on different hardware and resource configurations, so these compare deployments, not normalized hardware. Pricing AWS costs use published list prices. Sources AWS Lambda Web Functions Web Functions environment lifecycle Web Functions scaling behavior AWS Lambda pricing