Applies toAmazon EC2 and Auto Scaling, Amazon ECS (Fargate and EC2 launch types), Amazon EKS (including Auto Mode), AWS Lambda
Start with two questions
- What is the workload? Web/API, background worker, event handler, batch, vendor software, or a shared platform for many teams?
- Who operates it? A small product team, or a platform team with Kubernetes skills and on-call capacity?
Choose the simplest option that meets the requirements. Every step towards "more control" adds work that someone must do forever.
Decision path
Vendor/legacy software, OS-level control, licensing tied to hosts, Windows GUI apps?
└─ yes → EC2 (Auto Scaling groups for stateless fleets)
Event-driven, short tasks (< 15 min), spiky or low traffic?
└─ yes → Lambda
Containerised services, want AWS-native and minimal cluster operations?
└─ yes → ECS on Fargate (ECS on EC2 for GPUs, special instance types or cost at scale)
Need Kubernetes APIs, portability, operators/Helm ecosystem, many teams on one platform?
└─ yes → EKS (Auto Mode or Karpenter to reduce node management)
Comparison
| EC2 | ECS Fargate | ECS on EC2 | EKS | Lambda | |
|---|---|---|---|---|---|
| You manage | OS, patching, runtime, scaling | Task definitions | Tasks + container instances | Cluster add-ons, upgrades, nodes (less with Auto Mode), workloads | Functions |
| Scaling | ASG | Service auto scaling | Service + capacity providers | HPA/KEDA + Karpenter/Auto Mode | Per request, automatic |
| Max run time | Unlimited | Unlimited | Unlimited | Unlimited | 15 minutes |
| Cold start | n/a | Task start (tens of seconds) | Faster with warm hosts | Pod start | Init time per environment |
| Skills | Linux/Windows admin | Containers | Containers + EC2 | Kubernetes, strong | Event-driven design |
| Typical trap | Patch and drift debt | Cost at very high steady scale | Managing hosts again | Upgrades and add-ons are a job | Timeouts, chatty functions, hidden concurrency limits |
Patterns that work
| Workload | Good fit |
|---|---|
| Small team, a few containerised APIs | ECS on Fargate |
| Many teams, 50+ services, shared platform | EKS with a platform team |
| Event processing (S3, SQS, EventBridge) | Lambda |
| Long batch jobs | AWS Batch / ECS tasks / Step Functions orchestrating containers |
| COTS app on Windows Server | EC2 with SSM, AWS Backup |
| GPU inference | EKS or ECS on GPU EC2, or SageMaker endpoints |
Questions for the design review
- Who patches the OS and runtime, and how is that evidenced?
- How does it scale, and what's the bottleneck downstream (database, licences)?
- How is it deployed and rolled back?
- What happens when one AZ fails?
- Can the owning team operate it at 3 AM?
Mixing is fine
Most estates use several: Lambda for glue and events, ECS or EKS for services, EC2 for vendor software. Standardise how things are built, deployed, observed and secured, rather than forcing one compute model everywhere.
Tip
Revisit the choice when the workload changes. A Lambda function now running constantly at high concurrency may be cheaper on Fargate; an EKS cluster hosting three services may be simpler as ECS.
Checklist
- Workload shape and operating team identified
- Decision path recorded
- Patching, scaling and deployment ownership written down
- AZ failure behaviour understood
- Review date set for when the workload changes