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.

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.

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.

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.

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.