Every AWS compute decision starts with EC2, Fargate, or Lambda. Every tutorial says "it depends on your use case." That is true but unhelpful. Here is a concrete framework for making the decision.
What Each One Actually Is
Before the decision matrix, a clear mental model:
EC2 is a virtual machine you rent. You control the OS, the runtime, the network config, the patching schedule. It runs as long as you pay for it, regardless of whether it is doing anything.
Fargate is a container runtime you rent. You bring a Docker image; AWS manages the underlying VM. You pay per second the container runs, not for idle time the way you do with EC2.
Lambda is a function runtime. You bring a handler function; AWS manages everything else — container, OS, scaling, everything. Billing is per invocation and per millisecond of execution.
When EC2 Wins
EC2 is the right choice when you have predictable, sustained workloads where the overhead of managing an instance is justified by the control it gives you.
Use EC2 when:
- ▸You need a specific OS configuration or kernel module
- ▸The workload runs continuously with high CPU/memory utilisation (>60% of the time)
- ▸You need GPU instances for ML training or rendering
- ▸You are running a database that requires persistent local storage and low-latency disk I/O
- ▸You want Reserved Instance pricing — up to 72% off on-demand rates for 1-3 year commitments
The real cost of EC2 is not the instance price. It is the engineering time spent on patching, capacity planning, AMI management, and cluster maintenance. If you are running fewer than 10 instances and do not have a DevOps team, the operational cost often exceeds the compute savings.
A t3.medium runs 24/7 → $30/month
A Lambda handling 1M requests/month → $0.20/month
But: a constantly-running application on Lambda that processes
requests for 10 seconds each at 100 requests/second =
100 * 10 * 0.0000166667 * 3600 * 24 * 30 = $4,320/month
EC2 wins at sustained high utilisation. Lambda wins at spiky or infrequent workloads.
When Fargate Wins
Fargate is EC2 minus the OS management. You get container isolation, persistent processes, and the ability to run any workload — but AWS handles the underlying infrastructure.
Use Fargate when:
- ▸You have containerized workloads that run for minutes to hours
- ▸Traffic is variable — you need to scale containers up and down without managing an autoscaling group
- ▸You want to run ECS or EKS without managing node groups
- ▸The workload exceeds Lambda's 15-minute timeout or 10GB memory limit
- ▸You need a persistent TCP connection (Lambda cannot maintain one between invocations)
Good Fargate use cases:
- ▸Background job processors (video transcoding, report generation, ETL pipelines)
- ▸Long-running API services with variable traffic
- ▸Scheduled data processing tasks
- ▸Microservices that cannot fit Lambda constraints
Fargate costs roughly 2-3x equivalent EC2 on-demand pricing per compute unit — but saves the operational overhead. For most teams shipping product, that trade-off is worth it.
When Lambda Wins
Lambda is the right choice for event-driven, short-duration, spiky workloads where you genuinely cannot predict or do not want to manage capacity.
Use Lambda when:
- ▸Workloads are triggered by events: API calls, S3 uploads, DynamoDB streams, SQS messages, scheduled cron jobs
- ▸Execution completes in under 15 minutes
- ▸Traffic is unpredictable — ranging from 0 to thousands of requests per second
- ▸You want zero idle cost — Lambda truly bills per invocation, not per hour
- ▸You are building glue code between AWS services
Where Lambda surprises people:
- ▸Cold starts add 100-500ms on the first invocation (use Provisioned Concurrency for latency-sensitive paths)
- ▸Stateless only — no local file system persistence between invocations (use /tmp for temporary files within one invocation)
- ▸10GB memory and 15-minute timeout are hard limits — no exceptions
The Decision Tree
Is the workload event-driven or triggered?
├── Yes → Does it complete in < 15 minutes?
│ ├── Yes → Lambda (unless sustained high throughput → Fargate)
│ └── No → Fargate
└── No → Is traffic predictable and sustained?
├── Yes → EC2 (Reserved Instances for cost)
└── No → Fargate (scale to zero when idle)
Special cases:
GPU workloads → EC2 (p3/g4 instances)
ML inference → Lambda (small models) or Fargate/EC2 (large models)
Database servers → EC2 (RDS manages this for you, but EC2 underneath)
Batch processing → AWS Batch (manages EC2/Fargate automatically)
The Practical Answer
For most new workloads in 2024:
- ▸Start with Lambda for anything event-driven or with variable traffic
- ▸Use Fargate for services that need to run continuously but do not need EC2's control
- ▸Use EC2 only when you have a specific reason — GPU, sustained high utilisation for Reserved Instance savings, or OS-level requirements
The biggest mistake is defaulting to EC2 because it is familiar. The second biggest is defaulting to Lambda because it is trendy, without checking the timeout and concurrency constraints.
Pick based on workload shape, not familiarity.