Fargate and EC2 to Lambda: 10x Savings on Bursty Load

Fargate is not always the cheapest place to run a request

Fargate is a good default for containerized services, but for spiky web frontends and REST APIs it can be an expensive one. If your containers spend most of their time idle and then get slammed with requests for a few seconds at a time, you are paying for provisioned capacity that mostly sits waiting, and Fargate is often too slow to scale into the burst anyway, so users see latency spikes on top of the cost.

That usage pattern, mostly idle with sharp bursts, is close to the ideal case for Lambda. You pay per request and per millisecond of execution, so idle time is free, and it scales into a burst far faster than a container service can.

Estimating the change before committing to it

Before recommending a migration like this, I estimate it. I built a tool that reads the load balancer CloudWatch metrics, the request counts, latency, and bandwidth over the last 30 days, and calculates what it would cost to serve the same traffic with a Lambda function behind CloudFront. The estimates are often surprising.

On one client the production setup cost about $4,000 a month across Fargate, data transfer out, and ALBs. The Lambda equivalent estimated at about $400, roughly a 10x reduction, with most of the remaining cost being CloudFront data transfer and requests. That estimate is conservative, because the ALB data transfer metric includes inbound traffic that would be free on Lambda. Their staging environment for the same backend cost about $1,500 a month, and the same Lambda setup estimated at $5, a 300x reduction.

A second client’s full footprint across all environments came to about $13,000 a month on EC2 and Fargate, estimated at about $1,000 on Lambda, a 13x reduction, roughly enough to fund a new developer. On another the numbers were smaller in absolute terms but the same shape, taking R&D compute from about $1,100 a month to about $5.

The savings are not always the biggest win

The $5-a-month staging number is worth pausing on. When an environment costs that little, the interesting move is not the saving itself but what it enables. One client had been sharing a single expensive staging environment that was a bottleneck in their delivery process. At $5 a month per environment they could instead give every engineer their own ephemeral sandbox for each pull request, for a fraction of what the shared one cost, and unblock their whole development flow. The cost reduction was almost a rounding error next to the velocity that bought them.

When this applies, and when it does not

This is not a blanket recommendation to rewrite everything as functions. It fits a specific shape: request-driven web or API workloads that are bursty or mostly idle, sitting behind a load balancer. Steady, high-throughput workloads that keep containers busy will usually be cheaper staying where they are.

The way to know which case you are in is to measure it against your real traffic rather than guess, which is exactly what the estimate is for. Migrating also has practical details to handle, such as how secrets reach the function, that are worth sorting out up front.

If you run spiky web or API workloads on Fargate or EC2 and want to know what they would cost on Lambda, book a discovery call or reach out on LinkedIn.

-Cristian