2.1.1. Evaluating Compute Options (EC2, ECS, EKS, Lambda, Fargate, Batch, Serverless)

💡 First Principle: Optimal compute selection is achieved by matching workload characteristics (e.g., statefulness, duration, traffic pattern) to the service's operational model, scalability, and cost structure.

Scenario: Your team is starting a new project and needs to decide on the primary compute platform. The application's requirements are still evolving, but you know it will involve a mix of API endpoints, background processing, and potentially some long-running tasks. You need to evaluate the various AWS compute options to determine the best fit.

AWS offers a diverse array of compute services, each with unique strengths. Evaluating these options is critical for effective architectural design.

• "Amazon EC2 (Elastic Compute Cloud)": Provides virtual servers with granular control over the OS and software. Ideal for custom configurations, legacy applications, or workloads requiring specific OS features. Offers highest flexibility but more operational overhead.
• "Amazon ECS (Elastic Container Service)" / "Amazon EKS (Elastic Kubernetes Service)": Container orchestration services. "ECS" offers AWS-native integration, "EKS" provides managed Kubernetes. Ideal for microservices, stateful containers, and achieving container portability.
• "AWS Lambda" (Serverless): Event-driven, pay-per-execution compute. Ideal for event-driven functions, APIs, and highly variable workloads where managing servers is undesirable. Offers extreme scalability and cost-efficiency.
• "AWS Fargate": Serverless compute engine for "ECS" / "EKS" containers. Eliminates server management for containers, balancing control with ease of use.
• "AWS Batch": Managed service for running batch computing workloads. Ideal for scientific modeling, data processing, and highly parallel jobs.

Key Compute Service Characteristics:

• "Amazon EC2": High control, high operational overhead, per-instance-hour cost.
• "Amazon ECS/EKS": Medium control (orchestration), medium operational overhead, per-instance-hour + container overhead cost.
• "AWS Lambda": Low control, low operational overhead, pay-per-invocation/"GB-second" cost.
• "AWS Fargate": Low control (serverless containers), low operational overhead, pay-per-vCPU/"GB-second" cost.
• "AWS Batch": Low control (job management), low operational overhead, pay-per-vCPU/"GB-second" cost (often integrates with "Spot").

Visual: Compute Service Selection Flow

Loading diagram...

⚠️ Common Pitfall: Choosing a compute service based on team familiarity rather than workload requirements. For example, using "EC2" for a highly spiky, event-driven workload when "Lambda" would be far more cost-effective and scalable.

Key Trade-Offs:

• Control vs. Operational Simplicity: "EC2" gives you full control but requires you to manage everything. "Lambda" gives you minimal control but handles all scaling and server management for you. "Fargate" and "ECS"/"EKS" sit in between.

Reflection Question: Considering the unpredictability and stateless nature of API endpoints and background processing tasks, why would "AWS Lambda" be a more suitable and cost-effective choice than "Amazon EC2" for this scenario, and how would you handle the long-running tasks differently?