Easel.sh Builds Custom Compute to Avoid AWS Lambda Web Functions' Idle Memory Billing

For a single 200ms request followed by 345 seconds of inactivity, AWS Lambda Web Functions can result in roughly 1,700 times the request duration in metered memory time. This finding led Easel.sh, a platform for running web applications, to abandon the service in favor of building its own compute infrastructure to gain control over resource allocation and costs.

The Five-Minute Idle Problem

While AWS Lambda Web Functions are designed to scale to zero, the platform bills for memory consumed over the entire life of an execution environment. Easel.sh discovered that these environments do not terminate immediately after a request finishes, instead remaining active for 5–7 minutes.

In experiments across six representative environments, the idle periods measured between 313 and 411 seconds. Because there is no configurable idle timeout to shorten these windows, the cost of memory remains active even when the application is doing no work.

This figure illustrates the specific idle periods discovered by Easel.sh during their testing of AWS Lambda Web Functions.

Chart drawn by HN Digest from figures reported by easel.sh; values are shown as written in the source.

Economic Impact on Low-Traffic Workloads

The billing structure poses a specific challenge for applications with unpredictable traffic. For a steady stream of requests, the idle-memory cost is spread across many interactions; however, for apps receiving only a few requests per day, the cost of a single request can be dominated by the subsequent idle period.

Easel.sh noted that memory accounted for approximately 88% of the calculated compute and request costs in their tests. For a platform supporting thousands of independent deployments, these cumulative idle charges create a different economic profile than high-volume, sustained traffic.

Performance and Infrastructure Trade-offs

To solve the billing issue, Easel.sh moved application execution onto servers they operate themselves, using traditional Lambda only for overflow. This move allows them to share capacity across multiple applications on a single machine, eliminating the per-environment idle fee.

This diagram explains the architectural shift to shared capacity to mitigate idle-time costs.

Initial benchmarks showed that this custom infrastructure delivered 1.5–3× faster median warm-request times across various workloads, including JSON APIs and server-side rendering. Furthermore, the custom host achieved 3.5× faster cold starts after a 12-minute idle period compared to AWS Lambda Web Functions.

This chart provides the data for the performance improvements observed in warm-request scenarios.

This visual supports the claim regarding significantly faster cold starts on the self-operated infrastructure.

Limitations of the Findings

The performance data provided by Easel.sh is based on a single region (us-east-1) and a specific Next.js 16 application. The company noted that these are early results and do not constitute a comprehensive, multi-region performance study or a benchmark of sustained throughput.

While the move to self-operated compute provides better cost control and performance in these tests, it introduces the responsibility of managing capacity, handling failures, and ensuring efficient resource distribution across a diverse set of user applications.