---
title: Which AWS Compute Service Should I Use?
description: Lambda, ECS Fargate, EKS, EC2, App Runner, Beanstalk, or Lightsail? Answer 4 questions and get an opinionated recommendation with the comparison guide that goes deeper.
url: https://www.factualminds.com/decide/which-aws-compute/
category: compute
publishDate: 2026-04-30
updateDate: 2026-04-30
---

# Which AWS Compute Service Should I Use?

> Pick Lambda, ECS Fargate, EKS, EC2, App Runner, Beanstalk, or Lightsail by traffic shape, latency budget, and team capacity — in 4 questions, with the comparison guide that goes deeper.

## How to use this tree

This tree captures the trade-offs we make in real architecture reviews. The goal is not to be exhaustive — it is to get you to a defensible default in 60 seconds. If two answers feel close, walk both branches and read the comparison guides at each leaf; the right call usually becomes obvious.

If you do not see your scenario, the most common hybrid is Lambda for spiky API traffic + Fargate for steady services + Batch for long-running async work. That is a healthy production shape.

## Start Here

workload-shape

## Decision Questions

### workload-shape: What kind of workload are you running?

_Pick the closest match. Long-running services, async jobs, and full Kubernetes ecosystems each have a clear best fit._

- "Web app or API serving HTTP requests" → http-traffic
- "Async job or event-driven function (queue → worker)" → async-duration
- "Containerized service that needs Kubernetes ecosystem (Helm, operators, CRDs)" → rec-eks
- "Batch job, ML training, or HPC" → batch-shape
- "Static website or front-end with serverless functions" → rec-amplify

### http-traffic: What does the traffic look like?

_Spiky, idle, or steady traffic determines whether serverless or container is more cost-efficient._

- "Spiky / unpredictable; idle 50%+ of the time; bursty events" → rec-lambda-api
- "Steady production traffic with predictable load" → container-orchestration
- "Just want to push a container and forget orchestration" → rec-app-runner
- "Need a single managed VM for cost predictability and full OS control" → rec-lightsail

### async-duration: How long does a single job run?

_Lambda caps at 15 minutes. Beyond that, ECS or Batch is the right tool._

- "Under 15 minutes — most jobs finish in seconds or minutes" → rec-lambda-async
- "15 minutes to several hours" → rec-fargate-job
- "Long-running batch (hours to days), needs queue/scheduling" → rec-batch

### container-orchestration: How much Kubernetes/cluster operations does your team want to own day-to-day?

_ECS Fargate is the simplest container path on AWS. EKS gives you the Kubernetes ecosystem if you need it._

- "As little as possible — just run my container" → rec-fargate-svc
- "Need EC2-level instance control (GPUs, custom AMIs, reserved instances)" → rec-ecs-ec2
- "Need full Kubernetes (Helm, operators, multi-tenancy, CRDs)" → rec-eks

### batch-shape: Do you need GPU acceleration?

_AWS Batch handles scheduling, retries, and instance lifecycle for batch and ML training._

- "Yes — model training or HPC requiring GPU instances" → rec-batch-gpu
- "No — CPU-bound batch jobs" → rec-batch

## Recommendations

### rec-lambda-api: AWS Lambda + API Gateway

Pay-per-invocation HTTP APIs. Wins on cost when traffic is spiky and on idle time. SnapStart drops cold starts to single-digit ms for Java and Python.
**When to use:**
- API traffic is spiky or idle 50%+ of the time
- Per-request execution under 15 minutes
- You want zero infrastructure to manage
**When NOT to use:**
- Steady high-throughput traffic — Fargate or EC2 is cheaper above ~1M req/day per service
- You need long-lived connections (WebSockets to Lambda is awkward)
**AWS services:**
- [AWS Serverless Consulting](/services/aws-serverless/)
**Comparisons:**
- [EC2 vs Lambda](/compare/aws-ec2-vs-lambda/)
- [Lambda vs ECS Fargate](/compare/aws-lambda-vs-ecs-fargate/)

### rec-lambda-async: AWS Lambda (event-driven)

Serverless workers triggered by SQS, EventBridge, S3 events, DynamoDB streams, or API Gateway. Default async compute when jobs finish in < 15 min.
**When to use:**
- Jobs finish in under 15 minutes
- Spiky or unpredictable workload
- Event-driven pipeline from SQS, EventBridge, S3, or DynamoDB streams
**When NOT to use:**
- Job runs longer than 15 minutes — use Fargate or Batch
- Highly steady throughput where Fargate is cheaper
**AWS services:**
- [AWS Serverless Consulting](/services/aws-serverless/)
**Comparisons:**
- [Lambda vs ECS Fargate](/compare/aws-lambda-vs-ecs-fargate/)

### rec-fargate-svc: Amazon ECS on Fargate

AWS-native container orchestration without owning the cluster. The lowest-friction container path on AWS — perfect for steady production services.
**When to use:**
- Steady production HTTP services
- You want containers without managing nodes
- You don't need the Kubernetes ecosystem
**When NOT to use:**
- You need GPU, custom AMIs, or precise reserved-instance economics — use ECS on EC2
- You need Helm, operators, or multi-tenancy patterns from Kubernetes — use EKS
**AWS services:**
- [DevOps Pipeline Setup](/services/devops-pipeline-setup/)
**Comparisons:**
- [Lambda vs ECS Fargate](/compare/aws-lambda-vs-ecs-fargate/)
- [ECS vs EKS](/compare/aws-ecs-vs-eks/)

### rec-fargate-job: ECS Fargate (scheduled tasks)

Run a long-running container on demand. Right answer for jobs that exceed 15 minutes but are still bursty enough that you do not want to keep instances warm.
**When to use:**
- Job duration 15 min – several hours
- Sporadic enough that an idle EC2/EKS cluster wastes money
**When NOT to use:**
- Continuous high-volume processing — EC2 spot or Batch is cheaper
**Comparisons:**
- [Lambda vs ECS Fargate](/compare/aws-lambda-vs-ecs-fargate/)

### rec-ecs-ec2: Amazon ECS on EC2

Container orchestration with EC2-level instance control. Pick this when you need GPUs, custom AMIs, or reserved-instance pricing that Fargate cannot offer.
**When to use:**
- You need GPU instances, custom AMIs, or specific instance families
- You can amortize reserved instances across multiple services
**When NOT to use:**
- You do not want to manage cluster capacity — use Fargate
**Comparisons:**
- [ECS vs EKS](/compare/aws-ecs-vs-eks/)

### rec-eks: Amazon EKS (Auto Mode if you can)

Managed Kubernetes. EKS Auto Mode (GA Dec 2024) removes most cluster ops. Pick this when you need the Kubernetes ecosystem — Helm, operators, multi-tenancy, CRDs.
**When to use:**
- You need the Kubernetes ecosystem (Helm, operators, CRDs)
- Multi-tenant platform serving multiple internal teams
- Workloads that already speak Kubernetes from another cloud or on-prem
**When NOT to use:**
- Single-team product with no need for the Kubernetes ecosystem — ECS Fargate is much simpler
**AWS services:**
- [DevOps Pipeline Setup](/services/devops-pipeline-setup/)
- [AWS Application Modernization](/services/aws-application-modernization/)
**Comparisons:**
- [ECS vs EKS](/compare/aws-ecs-vs-eks/)

### rec-app-runner: AWS App Runner

The "git push and forget" path. Push a container or source repo, App Runner builds, deploys, scales, and serves it. Good for early product, internal tools, and low-volume APIs.
**When to use:**
- Internal tool, prototype, or low-volume API
- You want zero infra config
- Single container per service
**When NOT to use:**
- Production at scale — Fargate or EKS gives you more control over networking, autoscaling, and cost

### rec-lightsail: Amazon Lightsail

Flat-rate VMs with predictable monthly pricing. Good for WordPress, simple back-ends, and dev environments where billing transparency matters more than scale.
**When to use:**
- Single VM with predictable monthly cost
- WordPress, Mastodon, low-traffic side project
**When NOT to use:**
- Production load that benefits from autoscaling, multi-AZ, or AWS-native networking — graduate to EC2 or ECS

### rec-amplify: AWS Amplify Hosting

Static site + CDN with optional Lambda functions and pre-built integrations. Default for Next.js, Astro, Nuxt, SvelteKit front-ends.
**When to use:**
- Static or hybrid SSR front-end (Next.js, Astro, Nuxt)
- You want CDN, build pipeline, and preview environments without configuring CloudFront yourself
**When NOT to use:**
- Highly custom edge logic — go to CloudFront + Lambda@Edge directly
**AWS services:**
- [AWS CloudFront Consulting](/services/aws-cloudfront-consultant/)

### rec-batch: AWS Batch (CPU)

Managed batch scheduling on Fargate or EC2. Handles job queues, retries, dependencies, and instance scaling for embarrassingly parallel CPU work.
**When to use:**
- CPU-bound batch processing — bioinformatics, simulation, ETL
- You want spot pricing without managing the spot lifecycle
**When NOT to use:**
- Single small jobs — Lambda is simpler

### rec-batch-gpu: AWS Batch (GPU) or Amazon SageMaker Training

For ML training, SageMaker Training gives you the highest-level abstraction. For arbitrary GPU batch (HPC, simulation, custom CUDA), Batch + EC2 GPU instances is right.
**When to use:**
- Model training where you want managed experiment tracking — SageMaker Training
- Custom CUDA / arbitrary GPU compute — AWS Batch on EC2 GPU instances
**When NOT to use:**
- Inference — use Bedrock, SageMaker Endpoints, or ECS+GPU instead
**AWS services:**
- [AWS SageMaker Consulting](/services/aws-sagemaker/)

## FAQ

### Why is ECS Fargate the default container recommendation?
ECS Fargate is the lowest-friction container path on AWS. You get container deployment, autoscaling, IAM-integrated networking, and CloudWatch logging without ever touching nodes or kubelets. EKS is more powerful but pays back its complexity only when you actually need the Kubernetes ecosystem (Helm, operators, CRDs, multi-tenancy patterns).

### Should I just put everything on Lambda?
Lambda wins on spiky traffic and on jobs that finish under 15 minutes. It loses on steady high-throughput services where Fargate or EC2 is materially cheaper, and it is awkward for long-lived connections like WebSockets. The decision tree captures these breakpoints.

### Where does EKS Auto Mode fit?
EKS Auto Mode (GA Dec 2024) removes most node ops — networking, storage, and Karpenter-style autoscaling are managed by AWS. If you already chose EKS, Auto Mode is the easier path. It does not change the EKS-vs-ECS decision; it just lowers the operational tax of being on EKS.

---

*Source: https://www.factualminds.com/decide/which-aws-compute/*