Compute

Compute Services Guide

Trade-off Matrix for EC2, ECS, EKS, and Lambda focusing on management overhead, cost structure, and scaling behavior.

⟵ Go to Home Page

4Topics
Beginner

The Decision Matrix

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
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)
Intermediate

Core Compute Services

1. EC2: The "Brick and Mortar"

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.

2. ECS: The "Efficient Factory"

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.

3. EKS: The "Universal Operating System"

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.

4. Lambda: The "Electric Switch"

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.


How to Answer the "Confusing" Scenarios:

  • 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."
Advanced

Real-World Scenarios

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.

Scenario 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.

The "Why" (Interview Answer):
"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."

Scenario 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).

The "Why" (Interview Answer):
"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."

Scenario 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).

The "Why" (Interview Answer):
"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."

Scenario 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).

The "Why" (Interview Answer):
"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."

Advanced

Quick "Interview Cheat Sheet" for Trade-offs

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."