AWS Lambda Web Functions keep billing memory up to 7 minutes after the last request, Easel finds

Easel, a platform that hosts large numbers of web applications, has dropped AWS Lambda Web Functions after measuring that the service's execution environments stay alive and keep billing memory for roughly five to seven minutes after the final request. According to the company's blog post, which reached the Hacker News front page, the discovery pushed Easel onto servers it operates itself, and early benchmarks suggest that setup is also faster.

Memory billed long after traffic stops

AWS announced Lambda Web Functions in October, and Easel was an eager early tester: native HTTP handling, request concurrency, and CPU metered only during active use matched problems the company had spent months working around on traditional Lambda. Initial experiments looked promising, with 300 concurrent requests handled without errors and a fresh function serving traffic in under nine seconds.

The problem was the billing tail. Web Functions meter CPU only while it is in use, but memory is charged for the entire lifetime of an execution environment. AWS documents this model; what caught Easel off guard was how long environments linger. Across six representative environments in us-east-1 on October 26, idle periods ran from 313 to 411 seconds after the last completed request, with processes active throughout and no setting to shorten the idle window.

The multiplier is stark. According to Easel, a 200 ms request followed by 345 seconds of silence produces roughly 1,700 times the request's duration in metered memory time. Cross-checked against CloudWatch and AWS Cost Explorer, memory made up about 88% of calculated compute and request costs at published list prices, even though the application used only around 160–210 MB. The entire experiment cost about two cents at list prices — trivial on its own, but Easel supports thousands of applications with unpredictable traffic, some receiving only a few requests a day, so per-environment idle charges compound at that scale.

No supported workaround

Easel tried killing environments itself after 10 seconds of inactivity. That reduced metered environment time by roughly 20×, but AWS logged each deliberate shutdown as a runtime failure, which the company considered too risky to depend on in production.

The move to self-run compute

Instead, Easel now runs application execution on hosts it operates, with ordinary Lambda kept for spillover traffic. Capacity on a single machine can be shared across many applications rather than paying AWS for each idle environment. The first self-operated compute host went live in US East on November 2, serving applications including Easel's own website.

The homegrown setup also benchmarked faster

Easel deployed the same Next.js 16 application to both platforms and benchmarked from a client in Ashburn, Virginia, on November 11–12. Median warm-request times were 1.5–3× faster on its own host across all four workloads — 2.1× for server-side rendering and 2.0× for the first chunk of streaming — based on roughly 100 requests per route per platform. A CPU-bound test of 20,000 chained SHA-256 operations took 29.2 ms on Easel's host versus 43.8 ms on Web Functions.

Cold starts followed the same pattern. After 12 minutes idle, fresh environments served first bytes in 216–250 ms on Easel versus 810–854 ms on Web Functions, about 3.5× faster, though that comparison rests on just two paired trials. After a five-minute gap, Web Functions had already terminated its environment and needed 908 ms to respond, while Easel resumed a paused environment in 14 ms.

Easel is quick to caveat the numbers: a single region, a small application, only two cold-start samples, no sustained throughput testing yet, and the two platforms ran on different hardware, so the results compare deployments rather than normalized machines.

Why it matters

Serverless costs are usually judged by per-request prices and per-GB-second rates, but this story shows that platform behavior — how long an environment lives after traffic stops — can dominate the bill, and it is not a knob users can turn. For bursty or rarely visited workloads, minutes of post-request memory billing per environment can dwarf the cost of the requests themselves; Easel's 88% memory share is the concrete illustration. The behavior is documented by AWS, which makes the lesson less about a hidden fee and more about the gap between documented mechanics and measured economics. It is also a reminder that a first-party managed service is not automatically the fastest option — a small operator tuning its own stack beat AWS on latency in these early tests. Teams running many small, irregularly used functions should measure environment lifetime before assuming list prices map cleanly to their traffic shape.