Choosing Between Lambda, ECS, and EC2 in AWS

Start with the workload, not the service

The most common mistake in choosing compute is starting with the service — “should I use Lambda or EC2?” — instead of starting with the workload. The workload determines the right service. Here’s the decision flow:

Is your workload event-driven and short-running (under 15 minutes)? → Lambda. No servers to manage, automatic scaling, zero cost when idle.

Is your workload long-running, containerized, and stateless? → ECS Fargate. Containers without managing EC2 instances.

Is your workload long-running and needs EC2-specific capabilities (GPU, Windows Server, specific OS, legacy app)? → EC2.

Do you have a complex microservices architecture with Kubernetes requirements? → EKS (Kubernetes). Beyond the scope of this three-way comparison, but the right answer if you need Kubernetes.

These are not hard rules but strong defaults. Most workloads fit clearly into one category. The edge cases are worth examining.

Decision matrix: workload type to service

Lambda: the default starting point

Lambda should be your first consideration for any new workload. The reason is simple: it has the lowest operational overhead of the three. No instances to provision, no AMIs to maintain, no OS patches, no capacity planning.

Lambda is the right default when:

• You’re building something new and the workload fits the event-driven model
• Traffic is unpredictable or has significant idle periods
• You want to ship fast without infrastructure setup
• The workload runs in well under 15 minutes

Lambda becomes the wrong choice when:

• Execution time exceeds 15 minutes
• The application needs persistent in-memory state (active WebSocket connections, loaded ML models)
• You need more than 6 vCPUs or 10 GB memory
• The workload runs 24/7 at high volume (fixed-cost EC2 may be cheaper)
• You need OS-level configuration, specific kernel versions, or Windows

Lambda container image support largely eliminates deployment package size as a constraint. You can package a full application with large dependencies as a container image up to 10 GB and run it on Lambda. The execution model is still per-invocation and the time limit still applies, but the “my dependencies are too large for Lambda” problem is solved.

See Lambda overview for the complete picture of Lambda limits and capabilities.

ECS Fargate: the middle ground

ECS Fargate occupies the space between Lambda and EC2. It runs containers without Lambda’s execution constraints and without EC2’s server management overhead.

ECS Fargate is the right choice when:

• Your application is already containerized or can be containerized with minimal effort
• Execution time exceeds Lambda’s 15-minute limit
• You need persistent connections (WebSockets, database connection pools)
• You want long-running services without managing EC2 instances
• Traffic is steady enough that always-on containers are cost-effective

ECS Fargate patterns:

• Long-running services: Web servers, API backends, background workers — deployed as ECS services with auto-scaling
• One-off tasks: Video processing, data export, batch transforms — triggered as ECS tasks that start, run to completion, and stop
• Scheduled tasks: Long-running cron jobs triggered by EventBridge Scheduler

ECS Fargate pricing: $0.04048/vCPU-hour + $0.004445/GB-hour. A task with 1 vCPU and 2 GB RAM running 24/7 costs approximately $0.04048 × 720 + $0.004445 × 2 × 720 = ~$29.15 + $6.40 = ~$35.55/month.

Compare this to Lambda running the same workload: if requests are continuous, Lambda per-invocation pricing at high volume may be significantly higher than a fixed Fargate service.

EC2: when you need the full virtual machine

EC2 is the right answer when neither Lambda nor ECS Fargate provides what the workload needs.

EC2 is the right choice when:

• You need GPU hardware (machine learning training, graphics rendering)
• You’re running Windows Server workloads
• You’re lifting and shifting an existing application without containerizing it
• You need specific kernel versions, OS configurations, or custom drivers
• You’re running stateful services (self-managed databases, in-memory stores)
• You need Spot Instances for large-scale batch processing (significant cost savings)

EC2 operational considerations: With EC2, you manage OS patches, security updates, AMI maintenance, and instance health. Auto Scaling Groups automate scaling and replace unhealthy instances, but the underlying infrastructure is still your responsibility. This operational overhead is the price you pay for the control EC2 provides.

For batch workloads, EC2 Spot Instances are dramatically cheaper — up to 90% off On-Demand pricing. The trade-off is that Spot Instances can be reclaimed with 2 minutes notice. AWS Batch manages this elegantly: it retries interrupted jobs automatically on new Spot capacity. This is the right pattern for large-scale batch processing at minimal cost.

See Spot Instances for how to build fault-tolerant batch workloads on Spot capacity.

The migration path: Lambda → ECS → EKS

Understanding the natural progression helps you choose the right starting point.

Start on Lambda for new event-driven workloads. You move off Lambda when:

• The workload hits the 15-minute timeout
• The workload needs persistent connections
• The workload needs more memory/CPU than Lambda provides
• The per-invocation cost exceeds fixed-cost alternatives

Move to ECS Fargate when Lambda’s limits are reached. The migration process:

1. Write a Dockerfile for your application
2. Push the image to ECR
3. Define an ECS task definition (CPU, memory, image, environment variables)
4. Create an ECS service (for long-running) or use EventBridge to trigger tasks (for scheduled/triggered)

Most Lambda codebases containerize cleanly — remove the handler wrapper, run the application as a main process, and the logic is identical.

Move to EKS if ECS’s orchestration model becomes insufficient — typically when you have many services needing complex scheduling, service mesh, or Kubernetes-specific tooling. Most teams never need this step from ECS.

Start on EC2 for workloads that are clearly EC2-appropriate from the beginning: GPU workloads, Windows Server, legacy applications that can’t be containerized, or very large scale batch processing with Spot.

Cost comparison across the three services

Cost depends heavily on workload. Here are three representative workloads:

Webhook handler — 500,000 invocations/month, 300ms each, 256MB:

• Lambda: ~500K invocations + 500K × 0.3s × 0.25GB GB-seconds. With free tier: essentially $0–$2/month
• ECS Fargate minimum: ~$12/month for the smallest always-on task
• EC2 t3.nano: ~$3.80/month but you manage OS
• Winner: Lambda — clear cost advantage for event-driven, low-volume, short-duration

Always-on API — 24/7, 1 vCPU equivalent, 2 GB RAM:

• Lambda: depends on traffic volume; at 1M requests/day with 200ms duration = ~$60–80/month
• ECS Fargate (1 vCPU, 2 GB): ~$35/month
• EC2 t3.small (On-Demand): ~$15/month; Reserved 1-year: ~$9/month
• Winner: EC2 Reserved or ECS at sustained 24/7 load — per-invocation Lambda cost adds up

Batch job — 100 jobs/day, 30 minutes each, 4 vCPU, 8 GB:

• Lambda: impossible — 30 minutes exceeds the 15-minute limit
• ECS Fargate: 100 × 0.5hr × (4 × $0.04048 + 8 × $0.004445) = $9.93/day = **$298/month**
• EC2 Spot (equivalent): $0.05–0.08/hr × 50 hours/day = **$75–120/month**
• Winner: EC2 Spot via AWS Batch — major cost advantage for batch workloads