AWS Lambda Web Functions Bills Idle Memory for Up to 7 Minutes, Easel.sh Finds

⏱️ Reading time: 6 min

AWS Lambda Web Functions, the service AWS announced in October with native HTTP servers and billing based on active CPU time, arrived with the promise of replacing much of the custom infrastructure that many companies build on top of classic Lambda. Easel.sh, a deployment platform, tested it for several weeks and found a problem that AWS’s documentation does not clarify: an idle environment keeps billing memory for 5 to 7 minutes after handling the last request, with no parameter to shorten that window. The company ended up building its own compute and, in the process, measured response times up to 3.5 times faster than AWS Lambda Web Functions.

📑 En este artículo

1. Nine seconds to start, five minutes billing with no traffic
2. Running its own compute: 1.5 to 3.5 times faster on the same Next.js app
3. Classic Lambda and Vercel Fluid Compute: the same dilemma, a different trade-off
4. What this means for your stack
5. Limitations of the experiment
6. References

Unlike classic Lambda, which runs one function per invocation and shuts it down immediately, Web Functions keeps a server running that can handle several requests at once. For a company like Easel, which operates deployment infrastructure for thousands of third-party applications, that promised to replace much of the work it had already invested in running web apps efficiently on classic Lambda.

Nine seconds to start, five minutes billing with no traffic

Easel’s first tests went well. Web Functions handled 300 concurrent requests without errors, and a new function was already serving traffic in under nine seconds, according to the company’s report. The problem showed up afterward: AWS documents that Web Functions bills memory for the entire lifetime of the execution environment, even with no requests running, but does not specify how long an idle environment stays alive before shutting down.

Easel measured six representative environments and, according to its own report, found idle periods of between 313 and 411 seconds (just over 5 minutes to almost 7). For a 200-millisecond request followed by 345 seconds of inactivity, that means billing memory for roughly 1,700 times longer than the request itself. In its comparison against AWS Cost Explorer, memory accounted for about 88% of the calculated cost of compute and requests at list prices, even though the test application used only 160 to 210 MB.

📌 Note: Easel tried shutting down its own environments after 10 seconds of inactivity. That cut the billed environment time by about 20 times, but AWS logged every voluntary shutdown as a runtime failure, something the company did not want to risk in production.

Running its own compute: 1.5 to 3.5 times faster on the same Next.js app

Instead of adopting Web Functions, Easel moved execution to servers it operates itself, keeping classic Lambda only for traffic overflow. The first self-managed compute host went into production on the US East Coast on November 2, 2026, serving customer applications and Easel’s own site.

To compare performance, the company deployed the same Next.js 16 application on both platforms and ran benchmarks from a client in Ashburn, Virginia, according to its own report. The result was 1.5 to 3 times faster warm response times across the four workload types it tested: a JSON API took 9.3 ms on Easel versus 27.0 ms on Web Functions (2.9 times), server-side rendering dropped from 26.0 ms to 12.2 ms (2.1 times), the first chunk of a streaming response fell from 18.1 ms to 9.1 ms (2.0 times), and a CPU-intensive API went from 61.4 ms to 39.7 ms (1.5 times).

The difference was not just network routing: 20,000 chained SHA-256 operations took 29.2 ms on Easel’s host versus 43.8 ms on Web Functions, 1.5 times faster on raw compute. On cold start, after leaving both applications idle for 12 minutes, Easel responded in 216 to 250 ms against AWS’s 810 to 854 ms across two paired tests, about 3.5 times faster. After a shorter five-minute idle period, Web Functions had already terminated its environment and needed 908 ms to respond, while Easel resumed its paused environment in just 14 ms.

Classic Lambda and Vercel Fluid Compute: the same dilemma, a different trade-off

Easel is not the first to run into idle memory billing. In the Hacker News discussion the case generated, a user identified as Onavo pointed out that Vercel’s Fluid Compute behaves “more correctly,” possibly because it runs on the same AWS infrastructure (which is also an investor in Vercel). That is a community opinion, not an Easel measurement, but it marks the obvious comparison point for anyone evaluating these three routes.

Platform	What it solves	Risk or limitation
Classic AWS Lambda	Bills per short invocation; does not keep a persistent HTTP server running	Handling concurrent HTTP traffic efficiently requires building your own infrastructure, exactly what Easel already had before testing Web Functions
Vercel Fluid Compute	Per Onavo’s HN comment, keeps the environment alive without the same idle memory penalty	The figure is an HN user’s opinion, not an Easel measurement; it is also a managed, closed platform, not self-operated compute
Easel.sh’s own compute	Self-managed US host in production since November 2, 2026, with classic Lambda only for overflow	Requires operating servers and allocating capacity across customers; not a ready-made option for a team that does not want to manage infrastructure

What this means for your stack

If you run an API or a Next.js backend on Lambda Web Functions with sporadic traffic (a multi-tenant SaaS, internal microservices, dashboards that get only a few requests per hour), open AWS Cost Explorer and separate how much of the cost is billed memory versus actual compute. The 88% Easel measured is the signal to look for before committing to this option.

Beyond Cost Explorer, check CloudWatch metrics per execution environment (duration per invocation versus total environment time) to see whether your own traffic matches the pattern Easel describes: short requests separated by minutes of silence. If the ratio gets close to the 88% the company measured, you are probably paying far more for idle memory than for real work.

A comment in the Hacker News discussion offers a concrete clue: a user named torginus wrote that “if you close your Lambda process, the container just shuts down, and you can do it after returning the response.” Before applying that in production, test it in a staging environment first: Easel already tried something similar (shutting down environments after 10 seconds of inactivity) and AWS logged every voluntary exit as a runtime failure instead of a clean shutdown, so the behavior may not be as predictable as it sounds.

For teams with steady traffic, none of this changes much: the same environment spreads the idle cost across many requests. The problem shows up with intermittent traffic or on multi-tenant platforms hosting many small apps, exactly Easel’s case.

Limitations of the experiment

Easel notes that these are initial results from a single AWS region and a single test client in Ashburn, Virginia; there is no guarantee they would hold in other regions or with a different traffic profile. The cold-start comparison relies on just two paired tests, a small sample to support a 3.5-times difference. Easel also sells its own compute, giving it a direct incentive for its infrastructure to come out ahead in the comparison; that does not invalidate the numbers, but it calls for reading them with that context in mind.

References

• Easel.sh: original report with idle memory measurements, latency benchmarks and cold-start comparisons.
• Hacker News: discussion thread on idle memory billing in Lambda Web Functions.
• Onavo’s comment on Hacker News: comparison with Vercel Fluid Compute’s behavior.
• torginus’s comment on Hacker News: suggestion to close the process after responding to shut down the container.

Featured image: Foto de Rick Rothenberg en Unsplash

How each article is made (sources, testing and editorial criteria): How we work.