AWS gives you four compute stories that sound interchangeable until you are on-call. They are not. Picking the wrong one does not fail immediately — it fails six months later when scaling, cost, or team skills do not match the architecture.
EC2: the baseline everything else sits on
Amazon EC2 is virtual machines you manage (or partially manage with Systems Manager). You choose instance types, AMIs, networking, and patching strategy.
Use EC2 when:
- You need full OS control, custom kernels, or legacy apps
- Workloads are steady-state with predictable CPU/memory profiles
- You are running software that does not fit containers or functions
- License-bound software requires dedicated hosts
Watch out for: You own patching, capacity planning, and Auto Scaling configuration. "Just run EC2" often means "just run an ops team."
Lambda: compute as a reaction to events
AWS Lambda runs your code in response to triggers — API Gateway, S3 events, SQS messages, EventBridge schedules — with automatic scaling and no servers to patch.
Use Lambda when:
- Traffic is spiky, intermittent, or event-driven
- Execution time stays under 15 minutes and memory fits the workload
- You want near-zero idle cost
- Microservices with small, stateless handlers
Watch out for: Cold starts, VPC-attached Lambda latency, package size limits, and debugging distributed failures. Lambda is not a drop-in replacement for a always-on web server.
ECS: containers without the Kubernetes tax
Amazon ECS orchestrates Docker containers on EC2 or AWS Fargate. You define task definitions and services; ECS handles scheduling, health checks, and rolling deploys.
Use ECS when:
- You want containers and AWS-native tooling (no kubectl required)
- Teams prefer simplicity over the Kubernetes ecosystem
- Fargate removes EC2 cluster management for many workloads
- You integrate tightly with ALB, Service Connect, and CloudWatch
Watch out for: ECS is AWS-specific. Portable Kubernetes skills do not transfer directly. Complex multi-tenant platforms may outgrow ECS conventions.
EKS: Kubernetes when portability and ecosystem matter
Amazon EKS runs upstream-compatible Kubernetes. You get the CNCF ecosystem — Helm, operators, service meshes, GitOps tooling — at the cost of control plane fees and operational depth.
Use EKS when:
- You standardize on Kubernetes across cloud and on-prem
- You need operators, CRDs, or a large Helm chart ecosystem
- Platform teams already run K8s and want AWS-managed control planes
- Multi-cloud portability is a business requirement
Watch out for: EKS has the highest operational surface area. Node groups, add-ons, IRSA, CNI choices, and upgrades are real work even with a managed control plane.
Comparison at a glance
| Service | Unit of deploy | Ops burden | Best traffic pattern | Typical team fit |
|---|---|---|---|---|
| EC2 | VM / AMI | High | Steady, long-running | Traditional ops, legacy |
| Lambda | Function | Low | Event-driven, bursty | Serverless-first teams |
| ECS | Container task | Medium (lower on Fargate) | Microservices, batch | AWS-native container teams |
| EKS | Pod / Deployment | High | Platform-scale containers | Kubernetes platform teams |
How to decide in one pass
- Is it event-driven and short-lived? Start with Lambda.
- Do you need containers? If yes: choose ECS for AWS simplicity, EKS for K8s portability.
- Does anything else fit? Fall back to EC2 — or run EC2/ Fargate as the host for ECS/EKS anyway.
- Model cost at idle. Lambda wins at zero traffic; EC2 wins at 24/7 high utilization on reserved capacity.
Exam and interview patterns
- "Minimal ops, unpredictable traffic, API backend" → Lambda + API Gateway
- "Docker microservices, no Kubernetes" → ECS on Fargate
- "Same manifests on AWS and GCP" → EKS
- "Windows .NET monolith with RDP debugging" → EC2 (still)
Build muscle memory
Reading comparison tables is not enough. Deploy the same tiny API four ways: EC2 + ALB, Lambda + API Gateway, ECS Fargate service, and a minimal EKS Deployment. Compare deploy time, logs, scaling behavior, and monthly cost. That exercise sticks.