EC2 vs Fargate

Compute choice.

Overview

EC2 and Fargate are the two main AWS compute choices for containerised workloads. EC2 gives maximum control (instance type selection, kernel access, custom AMIs) at the cost of operating the instance fleet; Fargate gives managed serverless containers (no instance management, per-second billing) at higher per-vCPU cost. The right answer depends on whether ops control or operational simplicity matters more.

• EC2: max control. Choose instance type, kernel, AMI, networking. Default for workloads that need GPU, custom drivers, or specific instance shapes.
• Fargate: managed serverless containers. No instance fleet to operate; per-second billing at vCPU and memory granularity. Default for variable workloads where ops simplicity matters.
• Per-workload cost analysis. Fargate carries a per-vCPU premium; EC2 wins on steady-state high utilisation, Fargate wins on bursty or spiky load.
• Operational fit per team. Existing EC2 expertise biases toward EC2; teams that want to spend zero ops time on substrate bias toward Fargate.

The approach

Workload-driven choice with per-workload cost analysis, per-team operational fit considered, documented rationale per service. The discipline is making the compute choice once with a written reason rather than mixing both compute layers across services that share patterns.

• Workload-driven. Compute per workload. Reality drives the answer.
• EC2 for max control plus steady-state high utilisation. GPU workloads, custom kernels, predictable load. Default when control or steady utilisation matters.
• Fargate for variable load plus ops simplicity. Bursty traffic, scheduled jobs, teams that do not want to operate instances. Default when ops simplicity wins.
• Per-workload cost analysis plus documented rationale. Run the math per service; capture the rationale for future review.

Why this compounds

The right compute choice compounds across years. Wrong-compute workloads pay cost or ops penalties indefinitely; right-compute workloads pay neither. Cross-service tooling (deploy, observability, secrets) gets built once per compute layer and reused. By year two the compute choice is automatic per service.

• Better cost efficiency. Pricing model matches utilisation pattern. EC2 for steady-state, Fargate for bursty.
• Better operational fit. Compute matches team. Ops time goes where it adds value.
• Workload-driven decisions. Replaces tribal preference with documented rationale. Quality of choice improves.
• Year-one investment, year-two habit. First compute choice is the investment; subsequent services inherit the patterns.