Lambda vs EC2 cost breakeven: when serverless stops being cheaper

Quick answer

Lambda charges per request (about $0.20 per million) plus per GB-second of compute (about $0.0000166667 for x86), so you pay only while code runs. EC2 charges for the instance around the clock whether or not it is busy. Lambda is cheaper for spiky, bursty, or low-utilization workloads where an EC2 instance would sit mostly idle; EC2 (ideally with Savings Plans or Spot) is cheaper for steady, high-utilization workloads that would keep a server busy. The breakeven is roughly where continuous Lambda execution would cost more than a right-sized instance running full-time, often around a few hundred thousand to a few million invocations per hour of sustained load, depending on memory and duration.

Lambda and EC2 sit at opposite ends of the compute spectrum. Lambda bills for actual execution and nothing else, which is ideal when work arrives in bursts. EC2 bills for a running instance regardless of load, which is ideal when the work is constant enough to keep that instance busy. The question is not which is cheaper in general, but where your workload sits relative to the crossover.

How each one bills

Model	Charged for	Cheapest when
Lambda	Per request plus per GB-second	Spiky, low-utilization, bursty
EC2 on-demand	Instance per hour, always	Steady, high-utilization
EC2 with Savings Plans/Spot	Instance per hour, discounted	Steady load, committed or interruptible

Lambda costs about $0.20 per million requests plus about $0.0000166667 per GB-second for x86 (ARM is roughly 20 percent cheaper). A 512 MB function running 200 ms per invocation uses 0.1 GB-second per call, so a million such invocations cost about $0.20 in requests plus about $1.67 in duration, roughly $1.87. That is remarkably cheap for a million calls, until the calls become continuous.

Where the crossover sits

The crossover is about utilization. A single m7g.large costs about $0.0816 per hour on-demand, or roughly half that under a Savings Plan or on Spot. If your Lambda workload runs continuously enough that its per-hour execution cost approaches that instance's hourly rate, and the instance would be busy the whole time, EC2 wins. In practice that is often somewhere in the range of a few hundred thousand to several million invocations per hour of sustained load, depending on memory and duration. Below it, Lambda is cheaper because you would be paying for an idle instance; above it, EC2 is cheaper because the instance stays busy.

Utilization is the real variable

The reason Lambda wins for spiky work is that a server sized for the peak sits idle between spikes, and you pay for that idle time. Lambda charges nothing between invocations. Conversely, a server at 70 to 90 percent utilization wastes almost nothing, so the per-request overhead of Lambda makes it more expensive than the efficient instance. Ask what the EC2 utilization would be: low utilization favors Lambda, high utilization favors EC2. This is the same idle-versus-busy logic behind the Lambda versus Fargate comparison.

Other costs at the margin

Lambda avoids the operational cost of patching, scaling, and managing servers, which is real even if it does not show on the bill. It also handles bursts with no capacity planning. EC2, on the other hand, can use Spot and Savings Plans to push the steady-state price well below on-demand, widening its advantage for constant workloads. Cold starts and provisioned concurrency can add Lambda cost for latency-sensitive services, covered in the provisioned concurrency guide.

Deciding for your workload

Estimate your invocation rate, average duration, and memory, then compute the monthly Lambda cost and compare it against a right-sized EC2 instance (with Savings Plans or Spot) that could carry the same load, adjusted for its realistic utilization. Use Lambda while utilization would be low and traffic is spiky; move to EC2 (or Fargate) once the load is steady enough to keep an instance busy. Price both against the resource catalog so the breakeven is a concrete number before you architect around one model.

FAQ

When is Lambda cheaper than EC2?

For spiky, bursty, or low-utilization workloads where an EC2 instance would sit mostly idle between requests. Lambda charges only while code runs (about $0.20 per million requests plus per GB-second of compute), so you pay nothing during idle periods. An always-on instance sized for the peak wastes money on idle time that Lambda simply does not bill for, making serverless the cheaper choice below the utilization crossover.

When is EC2 cheaper than Lambda?

For steady, high-utilization workloads that would keep a server busy most of the time. Once execution is nearly continuous, Lambda's per-request and per-GB-second charges add up to more than a right-sized instance's hourly rate, especially when that instance uses Savings Plans or Spot to cut its price. A busy instance at 70 to 90 percent utilization wastes little, so EC2 wins above the crossover.

Where is the Lambda-to-EC2 cost breakeven?

Roughly where continuous Lambda execution would cost more than a right-sized instance running full-time at high utilization, often somewhere in the range of a few hundred thousand to several million invocations per hour of sustained load, depending on memory and duration. The precise point depends on your function's memory size, average duration, and whether the EC2 alternative uses Savings Plans or Spot.

What determines whether Lambda or EC2 is cheaper?

Utilization. Low utilization and spiky traffic favor Lambda, because a server would sit idle between bursts and you would pay for that idle time. High, steady utilization favors EC2, because a busy instance wastes little and Lambda's per-request overhead makes it more expensive than an efficient server. Estimate what the EC2 utilization would be: that single variable usually decides the comparison.

How does C3X help compare Lambda and EC2 cost?

C3X prices both a Lambda configuration and an EC2 alternative from Terraform against a live catalog, so you can compare the serverless per-request cost against a right-sized instance for your expected load before you deploy. That turns the breakeven into a concrete monthly number in the pull request, so you architect around the model that is actually cheaper for your utilization pattern.

What to do next

Find the Lambda-to-EC2 breakeven before you architect. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.