AWS Compute in review: what we learned, what surprised us, what to pick
AWS Compute in review: what we learned, what surprised us, what to pick
Series: AWS Field Guide · Part 6 of 6 — Compute This series: 01 — Overview · 02 — EC2 · 03 — Lambda · 04 — ECS & Fargate · 05 — EKS · 06 — Wrap-up
We've covered a lot of ground
Over the last five articles we went deep on every major AWS compute service — from the foundational virtual machine (EC2) through to the full weight of managed Kubernetes (EKS). If you've read them all, you now have a working mental model of the entire AWS compute landscape.
If you landed here first — welcome. This article is the distilled version: honest verdicts, a consolidated decision framework, and a cheat sheet you can bookmark and return to every time a new workload lands on your desk.
The honest verdict on each service
EC2 — still the foundation, still worth knowing
EC2 is twenty years old and it still underpins most of what AWS runs. It's not glamorous, but it's the right tool more often than the serverless community would have you believe.
The verdict: use it when you need full control, long-running processes, specialised hardware, or when you're running something that genuinely can't be containerised. Don't use it as a default just because it's familiar — the operational burden of managing instances, AMIs, and patching adds up over time.
The most underappreciated EC2 decision isn't instance type — it's pricing model. Teams that run On-Demand instances for steady workloads for months at a time are leaving significant money on the table. Reserved Instances and Savings Plans exist for a reason.
Best fit: stateful long-running processes, legacy workloads, GPU compute, anything needing OS-level control.
Lambda — genuinely magical for the right workload
Lambda remains one of the best value propositions in cloud computing for event-driven workloads. Zero servers to manage, zero idle costs, automatic scaling from zero to thousands of concurrent executions. For the right use case it's hard to beat.
The verdict: lean into Lambda for event-driven, short-lived, stateless tasks. The ecosystem around it — EventBridge, SQS, S3 triggers — makes it the glue that holds modern AWS architectures together. But resist the temptation to build your entire backend on it. Cold starts, the 15-minute limit, the database connection problem, and the degraded local development experience all surface eventually.
The most underappreciated Lambda decision is failure handling for async invocations. A Dead Letter Queue is not optional — it's the difference between knowing about failed events and silently losing them.
Best fit: event-driven processing, webhooks, scheduled jobs, glue logic between AWS services, anything spiky or infrequent.
ECS + Fargate — the pragmatic workhorse
ECS with Fargate is the service that quietly runs a significant portion of production AWS workloads without generating much conference talk. It doesn't have the serverless mystique of Lambda or the ecosystem cachet of Kubernetes, but it solves the container-in-production problem cleanly and with minimal drama.
The verdict: if you're containerising workloads and don't have a specific Kubernetes requirement, ECS + Fargate should be your default. It handles rolling deployments, health checks, load balancer integration, and auto-scaling without requiring a platform team to maintain it. The IAM dual-role model is confusing at first; once you understand it, it's actually well-designed.
The most underappreciated ECS decision is log configuration. It's not automatic on Fargate — and discovering that your containers have been silently discarding logs in production is a bad day.
Best fit: containerised APIs and workers, microservices, any long-running workload that doesn't need Kubernetes specifically.
EKS — powerful, expensive, and often premature
EKS is the right answer for a real set of problems. It's also adopted far more often than those problems actually occur in the wild.
The verdict: EKS earns its place when you genuinely need the Kubernetes API — custom operators, CRDs, Helm-based workflows, multi-cloud portability, or complex scheduling requirements. At scale, the operational investment pays off. For teams under fifty engineers running fewer than a dozen services, ECS + Fargate almost always serves them better and costs less to operate.
The most underappreciated EKS reality is the upgrade treadmill. A Kubernetes cluster is not a thing you set up and forget — it demands attention every twelve months at minimum, and each upgrade is a project in its own right. Budget for this before you adopt it.
Best fit: large engineering organisations, teams already invested in Kubernetes tooling, workloads requiring multi-cloud portability or advanced scheduling.
The consolidated decision framework
Use this every time a new workload lands:
1. Is it short-lived, stateless, and event-driven? (< 15 min)
└─ Yes → Lambda
2. Is it containerised (or ready to be)?
└─ Yes, and Kubernetes isn't required → ECS + Fargate
└─ Yes, and Kubernetes is specifically required → EKS
3. Does it need full OS control, long-running processes,
GPU access, or specialised hardware?
└─ Yes → EC2
4. Unsure?
└─ Default to ECS + Fargate. Migrate later with evidence.
One addition worth making explicit: most real architectures use more than one. A typical production system might combine Lambda for event processing, ECS + Fargate for the core API, and EC2 for a specialised background worker. The goal isn't to standardise on one compute service — it's to match each workload to its best fit.
The one-page cheat sheet
| EC2 | Lambda | ECS + Fargate | EKS | |
|---|---|---|---|---|
| What it is | Virtual machine | Serverless function | Managed containers | Managed Kubernetes |
| You manage | OS, runtime, patching | Just the code | Container image, task config | Nodes, add-ons, upgrades |
| Max run time | Indefinite | 15 minutes | Indefinite | Indefinite |
| Scales to zero | No | Yes | With Fargate Spot | With Fargate profiles |
| Cold starts | No | Yes | No | No |
| Kubernetes | No | No | No | Yes |
| Pricing unit | Instance-second | Invocation + GB-second | vCPU + memory-second | Control plane + nodes |
| Baseline cost | ~$0 (spot) | ~$0 (pay per use) | ~$0 (no idle tasks) | ~$73/month (control plane) |
| Operational weight | Medium | Low | Low–Medium | High |
| Best for | Control, legacy, GPU | Event-driven, spiky | Containerised services | Large orgs, K8s ecosystem |
| Watch out for | Idle costs, patching | Cold starts, 15-min limit | IAM roles, log config | Upgrade treadmill, VPC IPs |
What surprised us writing this series
A few things that came up repeatedly across the research and writing:
Pricing decisions matter more than service selection. The gap between On-Demand and Reserved pricing on EC2, the Lambda concurrency cost at high volume, the EKS control plane tax — these are the decisions that compound over time on your AWS bill. Getting the service right and the pricing mode wrong is almost as bad as picking the wrong service entirely.
The "when NOT to use it" sections write themselves. Every service has an obvious sweet spot and a set of use cases where it genuinely struggles. The AWS documentation rarely tells you this plainly. The community has learned it the hard way, and passing that on is more useful than yet another hello-world tutorial.
ECS is underrated. It shows up less in conference talks and less in job descriptions than Kubernetes, but it handles the containerised workload problem cleanly for the vast majority of teams. If you're using EKS and find yourself not using any Kubernetes-native features, ECS + Fargate would likely serve you just as well at lower operational cost.
Key takeaways for the whole series
EC2 is the foundation. Every other compute service is an abstraction on top of it. Understanding EC2 makes the rest legible.
Lambda is the right default for event-driven, stateless, short-lived work. Its operational simplicity is real — so are its constraints.
ECS + Fargate is the pragmatic container platform for teams who want managed orchestration without Kubernetes complexity.
EKS is powerful and carries real operational weight. Adopt it when you have a specific Kubernetes requirement, not before.
Pricing mode is a first-class architectural decision, not an afterthought. On-Demand, Reserved, Spot, and Savings Plans have meaningfully different economics.
Real architectures mix compute services. Match the tool to the workload, not the workload to the tool you already know.
Up next — the Storage series
The next series in the AWS Field Guide covers Storage: S3, EBS, and EFS. Three services that look simple from the outside and reveal surprising depth once you're running them in production.
Part 1 → AWS Storage: choosing between S3, EBS, and EFS
Previously
Part 5 → AWS EKS: Kubernetes on AWS — power, complexity, and when it's worth it
Covers the EKS managed control plane, node groups, add-ons, the version upgrade treadmill, VPC IP exhaustion, and the honest ECS vs EKS decision framework.
Part of the AWS Field Guide series. Tags: #aws #compute #cloud #devops #aws-field-guide
