AWS Cost Benchmark: Lambda vs Fargate vs ECS on EC2 vs EKS

When engineers compare AWS Lambda, ECS Fargate, EC2 and Kubernetes, the discussion usually becomes architectural. But there is a more concrete question: what happens if we run exactly the same workload on all of them?

This benchmark uses one API model, identical RPS targets, the same memory and latency assumptions, and a common availability model. The goal is not to produce an AWS quote. It is to show how the economics change as utilization and platform complexity increase.

The workload

Assume a lightweight REST API performing authentication, business logic, a database/cache call, and a JSON response. We fix the workload so that the compute model — not the application — is what changes.

We calculate four steady-load scenarios:

Lambda: pay per request and execution duration

Lambda has a request component and a duration component measured in GB-seconds. For a 512 MB function running for 100 ms, each request consumes 0.05 GB-seconds. API Gateway adds another per-request cost for HTTP APIs.

0.5 GB × 0.1 sec = 0.05 GB-seconds per request

Lambda total
=
request charge
+
duration charge
+
API Gateway

At low and intermittent traffic, this model is extremely attractive because compute can fall close to zero during idle periods. Under continuous high-volume traffic, however, the convenience premium becomes visible.

Fargate: pay for task-level vCPU and memory

Fargate changes the unit of economics. Instead of paying per invocation, you pay for the vCPU and memory assigned to running tasks. For this model, one task is 0.25 vCPU and 512 MB and can process roughly 50 RPS.

required tasks
=
ceil(RPS × 1.3 / 50)

minimum tasks for HA
=
2

This produces 2, 3, 13 and 26 tasks at 10, 100, 500 and 1,000 RPS respectively.

ECS on EC2: cheaper raw capacity, but only when you use it

EC2 introduces capacity ownership. The advantage is that multiple tasks can share an instance and purchasing models such as Savings Plans or Spot can reduce effective compute cost. The disadvantage is that unused instance capacity is still billed.

At small scale, a two-node HA baseline can make ECS on EC2 more expensive than tightly right-sized Fargate. As the number of workloads grows, bin packing can fill those gaps and improve economics.

EKS: Kubernetes does not make EC2 cheaper

EKS worker nodes are still EC2 instances. If EKS and ECS use the same underlying nodes, the raw compute price is not magically reduced. EKS additionally has a per-cluster fee and introduces platform components and operational work.

Under standard Kubernetes version support, Amazon EKS currently charges $0.10 per cluster-hour; extended support is $0.60 per cluster-hour. Worker-node EC2, EBS, IPv4, and related resources are billed separately.

Cost per million requests

Looking only at the monthly bill can hide the utilization effect. Cost per million requests makes it easier to see when fixed infrastructure is being amortized across more traffic.

At 10 RPS, fixed EC2 and EKS capacity is poorly utilized. At 1,000 RPS, those fixed costs are spread across 2.628 billion requests and the gap narrows dramatically.

Traffic shape matters more than average RPS

Two systems can both average 100 RPS and have completely different economics. One may run flat at 100 RPS all day. Another may spend most of the day at 10–20 RPS and spike to 1,000 RPS for short periods.

Where does the bill come from?

The platform bill is not only compute. Lambda architectures add API Gateway request pricing; container architectures add load balancers; EC2 adds block storage and idle capacity; EKS adds cluster-level overhead.

The first surprising result: Lambda is not always the cheapest starting point

At extremely low or intermittent traffic, Lambda is hard to beat. But this benchmark is steady 24/7 traffic. At 100 RPS, the model produces roughly $534/month for Lambda + HTTP API versus about $64/month for Fargate.

The lesson is not “Lambda is expensive.” The lesson is that serverless economics depend heavily on idle time, duration, memory size, traffic shape and the per-request services around the function.

The second result: Fargate can remain competitive for longer than expected

It is common to assume that serious traffic automatically means migrating to EC2. In this workload model, Fargate remains slightly below the two-node/three-node/five-node EC2 model even at 1,000 RPS because tasks are tightly right-sized while EC2 capacity is bought in larger chunks.

This changes when many independent workloads share the same EC2 fleet. Then the scheduler can fill unused capacity much more effectively.

The third result: EKS is not a cost optimization by itself

For a single API, EKS is consistently more expensive than ECS on the same EC2 capacity in this model. That should not be surprising. Kubernetes is not primarily a discount mechanism.

Its value appears when platform-level capabilities matter: many teams, many services, heterogeneous compute, GitOps, policy, advanced scheduling, multi-tenant platform boundaries and operational standardization.

Infrastructure cost is not Total Cost of Ownership

A platform decision based only on the AWS invoice can be misleading. The better equation includes people and operational complexity.

If moving from Fargate to EKS saves $180/month but creates substantial cluster lifecycle and platform engineering work, the migration makes little economic sense. If an established platform saves several thousand dollars per month and Kubernetes is already justified for organizational reasons, the equation changes.

What changes with Savings Plans, Spot and Graviton?

This benchmark intentionally starts from a mostly On-Demand baseline. Mature environments should evaluate Compute Savings Plans, EC2 Savings Plans, Fargate Savings Plans, Spot and ARM/Graviton where compatible.

Critical APIs       -> On-Demand / Savings Plans
Background workers  -> Spot
CI workloads        -> Spot
Batch processing    -> Spot
Stable baseline     -> committed capacity

Those levers can materially shift ECS/EC2 and EKS economics, especially when compute is stable and well utilized.

The benchmark I would run before a real migration

Before using AWS Pricing Calculator, I would load-test the actual application with k6, Gatling or Locust and measure CPU, memory, p50/p95/p99 latency and error rate at increasing RPS.

k6 / Gatling / Locust
        |
        v
10 -> 50 -> 100 -> 250 -> 500 RPS
        |
        v
CPU | Memory | p95 | p99 | Errors

The useful output is not simply “500 RPS works.” It is a measured capacity unit such as:

0.25 vCPU
50 RPS
CPU: 58%
p95: 84 ms
errors: 0.01%

Only then should the pricing model be populated.

A practical decision map

Final takeaway

The benchmark suggests a useful progression: Lambda is strongest when elasticity and idle-time economics dominate; Fargate is compelling for continuously running, right-sized containers; ECS on EC2 becomes powerful as shared capacity utilization increases; and EKS becomes justified when platform and organizational complexity require Kubernetes capabilities.