Infrastructure · Article

Choosing the Right AWS Compute Service

EC2, ECS, EKS, or Lambda? The answer is never "it depends" in an interview. Here's a structured framework to make the right call every time — with real-world scenarios you can use as STAR answers.

The Decision Framework

To choose the right compute service, you need to think like a designer: identify the "ops tax" you're willing to pay versus the level of control you actually need. In an interview, the best way to explain this is through a Trade-off Matrix focusing on management overhead, cost structure, and scaling behavior.

Abstraction Level (Easier Management) → Control Shift: OS → Container → Function Amazon EC2 Virtual Machines High Ops Effort Scale: Minutes OS Control Amazon ECS Containers Med Ops Effort Scale: Seconds AWS-Native Amazon EKS Containers (K8s) High Ops Effort Scale: Seconds Multi-Cloud Portability AWS Lambda Functions Zero Ops Effort Scale: Millisecs Event-Driven
Fig 1 — AWS Compute Trade-off Matrix: Abstraction vs. Operational Overhead
Feature EC2 ECS EKS Lambda
Abstraction Virtual Machines Containers (Opinionated) Containers (Kubernetes) Functions (Serverless)
Scalability Minutes (Auto Scaling Groups) Seconds (Fast) Seconds (Complex but powerful) Milliseconds (Instant)
Cost Model Pay per instance (24/7) Pay per resource (EC2 or Fargate) Pay per cluster + resources Pay per execution/duration
Ops Effort High (Patching, OS, Scaling) Low/Medium High (K8s is complex) Minimal (No infra)

Core Compute Services Deep Dive

Let's break down each service with its ideal use case, cost profile, and the one thing you should always mention in an interview.

EC2 — The "Brick and Mortar" VM

Use Case: Legacy apps, specialized OS requirements, or 24/7 steady-state workloads where you need the absolute lowest unit cost.

  • Cost: Cheapest for high-utilization (80%+) steady workloads, but most expensive in "human time" (maintenance).
  • Scaling: Slowest. You have to wait for the VM to boot and the agent to initialize.

🎯 Interview Tip

Mention EC2 when the application is not "cloud-native" or requires specific kernel-level tuning that containers can't provide.

ECS — The "Efficient Factory" Container

Use Case: Microservices on AWS where you want "Docker made easy." It's the AWS-native way to run containers without the overhead of Kubernetes.

  • Cost: Balanced. No control plane charge (unlike EKS).
  • Scaling: Faster than EC2. Ideal for web APIs and background workers.

🎯 Interview Tip

Recommend ECS for teams that want to move fast on AWS without needing multi-cloud portability. Use Fargate to remove server management entirely.

EKS — The "Universal Operating System" K8s

Use Case: Large-scale enterprise systems, hybrid-cloud requirements, or when you already have a heavy investment in the Kubernetes ecosystem.

  • Cost: Includes a $0.10/hour cluster fee. Can be expensive for small setups but scales efficiently for massive fleets.

🎯 Interview Tip

Highlight EKS for portability. If the company wants to run the same setup on-prem or on another cloud, EKS is the only choice.

Lambda — The "Electric Switch" Serverless

Use Case: Event-driven tasks (S3 uploads, DynamoDB streams), small APIs, or "glue code."

  • Cost: Cheapest for low/variable traffic. Warning: At high, constant volume, Lambda becomes significantly more expensive than EC2 or ECS.
  • Scaling: The gold standard. Scales to thousands of concurrent executions in milliseconds.

🎯 Interview Tip

Use Lambda when traffic is unpredictable or bursty. If nobody uses the app at 3 AM, you pay $0.

The "Confusing" Comparisons

ECS vs. EKS: "Use ECS if you want a simple, AWS-integrated container experience. Use EKS if you need the specific features of the Kubernetes API or multi-cloud flexibility."

Lambda vs. Containers: "Use Lambda if the task is short-lived (< 15 mins) and event-driven. Use Containers (ECS/EKS) for long-running processes, WebSockets, or when you need consistent sub-millisecond local caching."


Real-World Scenarios (STAR Answers)

To impress an interviewer, you should move past definitions and speak in patterns and trade-offs. Here are four "Real-World Scenarios" you can use to explain exactly why you chose one over the others.

1 The Event-Driven "Image Processor" — Lambda

The Problem: A social media app where users upload profile pictures. You need to resize them and store them in S3.

The Choice: AWS Lambda.

"I'd choose Lambda here because the workload is event-driven and bursty. If no one uploads a photo at 2 AM, we pay $0. If a celebrity joins and 10,000 photos hit at once, Lambda scales horizontally in milliseconds. Managing an EC2 server just to 'wait' for an upload is a waste of capital and 'ops' effort."
2 The High-Traffic "E-Commerce API" — ECS with Fargate

The Problem: A standard REST API for a retail website. It needs to be reliable, handle thousands of requests per second, and deploy fast.

The Choice: ECS (Elastic Container Service).

"For a standard microservice, I'd go with ECS. It offers the best balance of low management overhead and consistent performance. Unlike Lambda, we don't worry about 'Cold Starts.' Unlike EKS, we don't need a dedicated team to manage the Kubernetes control plane. It's the 'Goldilocks' solution for AWS-native teams who want to focus on code, not infrastructure."
3 The Enterprise "Multi-Cloud Platform" — EKS

The Problem: A large financial institution that runs some services on-premise and some in AWS, requiring identical deployment tooling everywhere.

The Choice: EKS (Elastic Kubernetes Service).

"I'd choose EKS for portability and ecosystem. If the business requirement is to avoid 'Cloud Lock-in' or if we are already using Helm charts and Prometheus for monitoring on-prem, EKS allows us to use the same manifests. It's an investment in a universal API, even though it has a higher management 'tax' than ECS."
4 The "Legacy Monolith" or "High-Performance Database" — EC2

The Problem: A legacy Java application that requires 128GB of RAM and specific kernel tuning, or a self-managed database like Cassandra.

The Choice: EC2 (Elastic Compute Cloud).

"I'd stick with EC2 when we need full control over the OS or specialized hardware (like GPUs or High-Memory instances). If the application isn't containerized and rewriting it is too expensive, EC2 is the most pragmatic choice. Also, for 24/7 steady-state workloads, Reserved Instances on EC2 provide the absolute lowest 'unit cost' per hour."

Interview Cheat Sheet

When the interviewer asks a rapid-fire comparison, use this mental model to frame your response instantly:

If the interviewer asks about... Your response should be...
Cost for low/variable traffic Lambda wins (Pay-per-request).
Cost for high steady-state EC2/ECS wins (Lower hourly rate than Lambda).
Speed of Scaling Lambda (ms) > ECS (seconds) > EC2 (minutes).
Operational Effort Lambda (Zero) < ECS (Low) < EKS (High).

🎯 Pro-Tip for your DevOps Background

When you answer, mention "Day 2 Operations."

Example: "I chose ECS not just for the initial setup, but because the patching and security overhead is significantly lower than managing an EKS cluster or a fleet of EC2s."

⚠️ Common Mistake in Interviews

Don't just pick a service — always explain the trade-off. Interviewers want to hear: "I chose X over Y because of Z." Naming a service without explaining what you're giving up signals a lack of depth.