AWS Compute Choice Framework

Choosing between Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, AWS Lambda, and AWS Batch is a decision about where code runs and who owns the operational work. In this course, we build a repeatable framework that ties workload requirements to scaling behavior, failure boundaries, operational ownership, and total cost drivers. We will avoid service catalog thinking and instead make each choice defensible with constraints and evidence.

Ownership spectrum from instances to batch

Let’s define the ownership axis first, because it explains most tradeoffs. Operational ownership means who patches the operating system, manages capacity, and runs the scheduler that places work onto compute.

On Amazon EC2, we operate virtual machines, so we choose the AMI, patch strategy, and scaling approach. On Amazon ECS or Amazon EKS, we operate an orchestrator that schedules containers, and we still need to decide what provides the underlying capacity. On AWS Fargate, the container capacity layer is managed by AWS, so we focus on task definitions and service scaling instead of node fleets. On AWS Lambda, AWS runs the compute infrastructure and scaling, and we focus on function code and its invocation model. On AWS Batch, AWS manages job queuing and scheduling for batch work, and it can place jobs onto ECS, EKS, Fargate, or EC2 capacity.

Let’s inspect the ownership shifts across these options at a high level.

Inputs that shape the decision

We can now treat compute selection as a constraint-matching exercise rather than a preference debate. Execution model means whether work runs as a long-lived service, an event-triggered function, or a queued job with a clear start and end.

Traffic shape is often the first constraint that bites. Spiky traffic with long idle periods tends to favor per-request models, and steady traffic tends to favor always-on capacity where utilization stays high.

Duration and state narrow the field quickly. AWS Lambda has a maximum timeout that is currently 900 seconds, so longer-running work usually moves to containers or batch. Stateful workloads that keep local state or require specialized host tuning often fit better on Amazon EC2 or containers on EC2 capacity.

Latency sensitivity also has an operational meaning. For request-response paths, we care about cold start risk, network placement, and how fast the platform can add parallel capacity. For async paths, we care about backlog growth, retry behavior, and how failures are isolated and retried.

Let’s visualize how these requirement cards map to compute constraints.