I Built the Same System in ECS, Lambda, and EKS — Here’s What Happened
I Built the Same System in ECS, Lambda, and EKS — Here’s What Happened
by Gary Worthington, More Than Monkeys

Most teams don’t choose an AWS compute platform, they inherit one.
Usually from a well-meaning DevOps engineer who’s since left the company and now “does consulting”.
A few years later, you’re staring at a Terraform directory the size of Yorkshire, trying to decipher which of the six load balancers actually does anything, and wondering if it’s too late to retrain as a gardener.
So, in the spirit of self-inflicted suffering, I decided to rebuild the same system three different ways:
- once with AWS Lambda,
- once with ECS on Fargate,
- and once with EKS (Kubernetes).
Same architecture, Same functionality, Three very different levels of regret.
Here’s what actually happened — in cost, complexity, and developer sanity.
The System
Nothing fancy: a small stateless REST API with a DynamoDB backend and a background job triggered from SQS.
It’s the sort of thing every startup builds before they accidentally reinvent Jira.
Each version used the same Terraform stack. The goal wasn’t to prove which one could scale to ten billion requests; it was to see which one would make me question my life choices first.
Round 1: Lambda — The Dream That Betrays You
Setup time: about 15 minutes.
Deployment: SAM template, one coffee.
First bug: discovered before the coffee was finished.
Lambda feels magical at first. You write a function, hit deploy, and it’s live. No servers, no scaling policies, no nonsense. AWS just… handles it.
You can almost hear Jeff Bezos whispering “trust me” as your first event triggers perfectly.
Pros:
- Zero infrastructure to manage.
- Scales like a dream.
- Dirt cheap at low traffic.
- Makes you feel clever for about half an hour.
Cons:
- Cold starts turn your endpoints into PowerPoint presentations.
- Packaging dependencies feels like origami with explosives.
- Debugging distributed logs will break your spirit.
- Fifteen-minute timeout feels generous until you need sixteen.
Verdict:
I’m a big fan of Lambda in the right circumstances (event-driven systems, background jobs, or serverless workflows where simplicity trumps control).
However, using it for a full-blown API still feels clunky. The developer experience just isn’t as mature as ECS or something like FastAPI running in a container.
It’s brilliant for small workloads, but if you’re stitching together a large REST interface, you’ll quickly miss the comfort of a real framework and predictable runtime.
Like a flat in London, it’s convenient, overpriced at scale, and smaller than you remember.
Round 2: ECS — The Sensible Option Nobody Talks About
Setup time: roughly a day (with some swearing).
Infra: ECS service on Fargate, ALB, a bit of Terraform duct tape.
ECS doesn’t get much hype, which is a shame. It’s the reliable Ford Focus of AWS compute. It won’t win awards, but it’ll start every morning and get you where you’re going.
Pros:
- Containers feel normal; no new mental models.
- Fargate removes servers from the equation.
- Autoscaling actually makes sense.
- Works with your existing CI pipeline.
Cons:
- Task definitions read like a cry for help.
- IAM policies multiply like rabbits.
- Observability still feels like assembling IKEA furniture without the manual.
- Networking configuration will haunt your dreams.
Verdict:
ECS is “just enough abstraction”. You don’t need a PhD in Kubernetes to use it, but you still feel in control. Once you’ve suffered through the first deployment, everything after that feels strangely pleasant — like you’ve joined a secret club of engineers who quietly got on with their jobs while everyone else was writing Helm charts.
Round 3: EKS — The Beast That Must Be Fed
Setup time: several days.
Level of despair: 8/10.
Amount of YAML written: immeasurable.
EKS (Elastic Kubernetes Service) is what happens when someone at AWS says, “What if we made containers… but complicated?”
The documentation promises “a managed control plane”. What it means is “we’ll manage it, but you’ll still be in therapy afterwards.”
Pros:
- Limitless flexibility.
- Huge ecosystem (Helm, CRDs, chaos).
- Every cloud-native job posting now wants Kubernetes experience, so there’s that.
Cons:
- The operational overhead of a small government.
- You patch it, upgrade it, and hope for the best.
- Requires an entire platform team to babysit.
- Costs more than a city-centre flat for what Lambda did for £8.
Verdict:
EKS is fantastic if you’re Spotify. If you’re not, it’s like buying a racehorse to deliver your big shop.
Powerful, yes. Sensible, absolutely not.
The Numbers (and the Damage)
Time to first deploy:
- Lambda: 15 minutes
- ECS: 1 day
- EKS: 4 days and part of my soul
Monthly cost (light traffic):
- Lambda: ~£8
- ECS (Fargate): ~£40
- EKS: ~£110 (plus therapy)
Maintenance effort:
- Lambda: none
- ECS: low
- EKS: constant vigilance
Developer happiness:
- Lambda: 8/10
- ECS: 9/10
- EKS: 4/10 (and that’s generous)
What Actually Surprised Me
Lambda wasn’t the cheapest once traffic scaled. Cold starts became noticeable, and concurrency limits needed manual tuning.
ECS, on the other hand, quietly got on with it. No fuss, no fires, no Kafka-level complexity.
EKS was… educational. Mostly in the way near-death experiences are.
The real surprise was how ECS hit the sweet spot between simplicity and control.
It’s boring, predictable, and quietly brilliant — three words you’ll never hear in a Kubernetes Slack channel.
Choosing the Right Tool
If you’re building:
- A scrappy MVP or event-driven API: go Lambda. It’s perfect for short-lived workloads, background jobs, or single-purpose functions that don’t justify a container.
But don’t fool yourself — building a full-blown REST API out of 47 separate Lambda functions isn’t “serverless innovation”. It’s just pain in installments. - A growing app or microservice: go ECS on Fargate.
- A full-blown platform with multiple teams: fine, go EKS — but only if you’re also hiring a therapist.
Your compute choice should reflect your team’s maturity, not your ego.
Running Kubernetes “because that’s what big companies use” is like buying a combine harvester for your window plants.
Final Thoughts
If I were starting again tomorrow, I’d pick ECS without hesitation.
It’s the sweet spot: simple enough to live with, flexible enough to grow, and cheap enough not to appear on your CFO’s radar.
Lambda feels effortless but constrained — brilliant for glue, clunky for full systems.
EKS feels limitless but expensive — in money, time, and sanity.
AWS gives you all the rope you could possibly need.
ECS is the one where you’re least likely to hang yourself with it.
Gary Worthington is a software engineer, delivery consultant, and fractional CTO who helps teams move fast, learn faster, and scale when it matters.
Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.
Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.
Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance.
I Built the Same System in ECS, Lambda, and EKS — Here’s What Happened was originally published in AWS Tip on Medium, where people are continuing the conversation by highlighting and responding to this story.