Containers Serverless Engineering · April 2026 · 8 min read AWS

EKS vs ECS vs Lambda: simulation-led container platform selection at 1K, 10K, and 100K RPS

Principal Solutions Architect AWS Containers April 2026
← Back to blog

"Should we use EKS, ECS Fargate, or Lambda for this service?" is one of those AWS questions where the honest answer is it depends, but where engineers reach for a default — usually the one they already know — and discover six months later that the default was wrong for the workload. The cost gap between the three platforms is not 10%. At certain shapes of load it is 4×.

This post walks through a simulation-led decision framework: we model the same API workload at three traffic levels and look at what the platforms actually cost, where they break, and how the choice changes when you stop arguing from architecture instincts and start arguing from numbers.

The reference workload

To make the comparison concrete, we use a single reference workload: a stateless REST API, 50 ms average backend latency, 256 MB memory footprint, p99 SLO of 500 ms, 60% sustained load with 3× spikes twice daily. We simulate at 1K RPS (early-stage product), 10K RPS (growth-stage product), and 100K RPS (mature platform).

Cost at each traffic level

The headline numbers from a pinpole canvas simulation of all three platforms with the same workload configuration:

Platform1K RPS10K RPS100K RPSCold-start risk
Lambda$240/mo$2,150/mo$21,400/moHigh at spike onset
ECS Fargate$610/mo$4,800/mo$42,500/moNone
EKS (managed nodes, m6g)$920/mo$3,400/mo$11,200/moNone

Three things jump out. Lambda is cheapest at low volume — by a lot. EKS becomes cheapest at high volume — also by a lot. ECS Fargate is the safe middle at every traffic level but never the cheapest. If your decision framework does not account for where on this curve your workload actually sits, you will overpay.

Where each platform breaks

Lambda — concurrency cliff

Hits the regional account concurrency limit (default 1,000) faster than teams expect. Spike simulation surfaces this immediately; production discovers it during a launch.

ECS Fargate — slow scaling

Task launch time is 30–60s. A 3× spike that lands in under 60s will hit existing tasks at saturation before new ones boot. Add headroom or pre-scale.

EKS — operational tax

Cheap at scale, but only if you have someone who actually understands cluster autoscaler, PDBs, and version upgrades. The $11k/mo savings can disappear into one DevOps headcount.

A decision framework that holds up

From running this comparison across dozens of customer workloads, a fairly stable framework emerges:

The trap to avoid

The most common pattern we see is teams who picked Lambda for a prototype, scaled the prototype into the company's revenue path, and never re-ran the math. By the time anyone notices, the migration cost dwarfs the savings. Re-run the simulation each time you cross an order-of-magnitude in traffic.

Simulating it yourself

The pinpole canvas lets you wire up the same architecture three times — once with each runtime — and run the simulation at all three traffic levels in under five minutes. Each variant returns a live monthly cost, p99 latency under load, and AI recommendations specific to the runtime (provisioned concurrency for Lambda, capacity providers for Fargate, cluster autoscaler tuning for EKS).

The point is not that one of these platforms is always right. The point is that the right platform is a function of where you are on the traffic curve, and that decision should be made with numbers, not vibes.

Stop guessing which runtime is cheaper. Simulate all three.

Wire EKS, ECS Fargate and Lambda variants on the pinpole canvas, run the same traffic pattern through each, and compare cost and latency before you commit.

Start 14-day free trial →