Technology1 min read

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

By · Published by Everything Blog

In short

Easel rejected AWS Lambda Web Functions after benchmarking revealed that execution environments stay active and accrue memory costs for roughly five to seven minutes following a final request. Memory charges represented about 88 percent of the calculated compute and request costs, with AWS offering no way to lower the idle timeout. Although Easel managed to slash metered time by forcing exits after 10 seconds of inactivity, the platform logged every manual shutdown as an error. Consequently, Easel deployed its own compute host on November 2, using traditional Lambda strictly as a backup.

Key points

  • Unconfigurable idle durations make AWS Lambda Web Functions costly for platforms running…: Unconfigurable idle durations make AWS Lambda Web Functions costly for platforms running numerous services with intermittent traffic.
  • Easel migrated primary workloads to self-operated compute hosts in the US East region to…: Easel migrated primary workloads to self-operated compute hosts in the US East region to avoid unnecessary memory expenses.
  • Self-hosted infrastructure outperformed AWS Lambda Web Functions in early latency tests f…: Self-hosted infrastructure outperformed AWS Lambda Web Functions in early latency tests for both warm responses and cold starts.

Sources checked by our analysis pipeline: 1

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.

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…

Technology