Comparing AWS Compute Services

The decision matrix for “which compute service?” — one of the most predictable AWS interview questions. The full cross-service essentials live in ../../_interview_essentials.md; this file is the compute-specific deep dive.

The options

The decision tree

Is it event-driven and short (< 15 min)?
├── Yes → Lambda
└── No
    │
    Is it a batch/parallel job (rendering, ETL, simulations)?
    ├── Yes → AWS Batch
    └── No
        │
        Is it a long-running service (web API, worker)?
        ├── Already on Kubernetes / multi-cloud / need K8s ecosystem?
        │   └── Yes → EKS
        ├── Want zero node management?
        │   └── Yes → Fargate (via ECS or EKS)
        ├── Steady high volume, per-CPU cost matters, or need GPU?
        │   └── Yes → ECS on EC2 (Spot + Reserved)
        ├── Want "just deploy my container, manage nothing"?
        │   └── Yes → App Runner
        └── Need full OS control, special hardware, licensed software?
            └── Yes → EC2

Cost model comparison

Key insight: Lambda and Batch scale to zero; everything else has a non-zero idle cost. For spiky or intermittent workloads, that’s decisive.

Cold start / startup latency

For request/response latency-critical paths: Lambda with provisioned concurrency, or always-warm Fargate/ECS. For “user is waiting on a button,” don’t put a cold-starting service in the hot path without mitigation.

Operational burden

Lowest → highest: App Runner / Lambda → Fargate → ECS on EC2 → EKS → EC2.

• Lambda / App Runner — AWS manages everything below your code/container.
• Fargate — AWS manages the nodes; you manage task definitions, networking, scaling policies.
• ECS on EC2 — you also manage the EC2 fleet (patching, capacity, bin-packing).
• EKS — all of the above plus Kubernetes itself (upgrades, add-ons, CNI, RBAC).
• EC2 — you manage the OS, the runtime, the deployment mechanism, everything.

EKS’s operational cost is real — only pay it when the K8s ecosystem, multi-cloud portability, or existing team expertise justifies it.

When each wins

Lambda — webhooks, event processing (S3/SQS/DynamoDB Streams triggers), scheduled tasks, glue code, spiky APIs. Anything where idle time is most of the time.

Fargate — long-running web services and workers where you want containers but not node management. The default “containerized backend on AWS” choice for most teams.

ECS on EC2 — steady high-volume workloads where the per-vCPU premium of Fargate adds up, GPU workloads, or when you need control over the instance (placement, special instance types, Spot bidding strategy).

EKS — you already run Kubernetes, need multi-cloud portability, or want the K8s ecosystem (Helm, operators, service mesh, Argo). Don’t choose EKS just to run containers — Fargate/ECS is simpler.

EC2 — legacy apps, licensed software tied to an OS, special hardware (GPU/FPGA without container support), or full control requirements.

App Runner — a single containerized web service where you want to deploy and forget. Less flexible than ECS but near-zero ops.

Elastic Beanstalk — older PaaS; still works, but new projects usually pick App Runner (for simplicity) or ECS/Fargate (for control). Beanstalk is in maintenance-mode mindshare.

Batch — large-scale parallel jobs: rendering, genomics, ETL, Monte Carlo. Manages the job queue and scales the compute fleet to match.

Common interview traps

• “Lambda for everything” — the 15-minute limit, cold starts, and per-invocation cost make it wrong for steady high-volume or long-running work. Knowing when not to use Lambda is the signal.
• “EKS because Kubernetes is standard” — EKS carries real operational cost ($73/mo control plane + cluster management). For a team that just needs to run containers, Fargate is simpler and cheaper to operate.
• Confusing Fargate with a service — Fargate is a launch type / capacity provider for ECS and EKS, not a separate orchestrator. “ECS on Fargate” and “EKS on Fargate” are both valid.
• Ignoring scale-to-zero — for intermittent workloads, the idle cost of always-on compute (ECS/EKS/EC2) can dwarf the actual work cost.

Interview angle

• “Walk me through choosing compute for a new service.” — start with the workload shape: event-driven+short → Lambda; long-running service → Fargate (default) or ECS-on-EC2 (cost/GPU) or EKS (already K8s); batch → Batch. Then weigh cold-start tolerance, cost model, and ops burden.
• “When would you NOT use Lambda?” — steady high-volume traffic (per-invocation cost adds up), work > 15 min, latency-critical without provisioned concurrency, or workloads needing persistent local state / large dependencies.
• “Fargate vs ECS on EC2?” — Fargate: no node management, pay per task, ~20-30% vCPU premium. ECS on EC2: you manage nodes but can use Spot/Reserved and bin-pack tightly — wins for steady high volume and GPU.
• “Why is EKS more expensive operationally than ECS?” — $73/mo per control plane plus the ongoing cost of running Kubernetes itself: version upgrades, add-on management, CNI, RBAC, etc. Worth it for K8s-native teams; overhead otherwise.
• “What scales to zero?” — Lambda and Batch. Everything else has idle cost. Decisive for intermittent workloads.