ECS on EC2 vs Fargate

Amazon ECS (Elastic Container Service, AWS’s container orchestrator) runs your containers, but it does not run them on thin air — something has to provide the CPU and memory. That “something” is the launch type, and you have two choices: EC2 (Elastic Compute Cloud, AWS’s virtual servers) or Fargate (AWS’s serverless container engine). Picking the right one decides how much you pay, how much you manage, and what hardware you can use. This page explains the trade-offs in plain English so you can choose with confidence.

What the launch type actually controls

A launch type only changes where the containers run. The rest of ECS — task definitions, services, load balancers, logging — works the same either way. So you are really answering one question: do I want to own the servers, or let AWS own them?

EC2 launch type: You run a fleet of EC2 instances (virtual servers) that join an ECS cluster. ECS schedules your containers onto those instances. You patch, scale, and pay for the instances whether they are busy or idle.
Fargate launch type: There are no servers for you to see. You describe how much CPU and memory each task (a running group of containers) needs, and AWS provisions and bills exactly that, per task, by the second.

Tip: You can mix both in one cluster using capacity providers — for example, baseline steady traffic on EC2 and burst traffic on Fargate. You do not have to pick just one forever.

EC2 launch type — you own the capacity

With EC2 you manage an Auto Scaling group of instances. Because you control the hardware, you get options Fargate cannot offer.

When to use this:

You have steady, predictable load running most hours of the day. Reserved Instances or Savings Plans on EC2 can be far cheaper than per-task Fargate pricing.
You need GPUs (for machine learning inference) or special instance types like high-memory or Arm Graviton bare-metal — Fargate’s hardware menu is limited.
You want bin-packing: cramming many small tasks tightly onto each instance to squeeze out every dollar of compute.
You need host-level features: privileged containers, custom kernel parameters, or a daemon on every node.

When NOT to use this: small or spiky workloads, or any team that does not want to patch and right-size servers. Idle EC2 instances still cost money even when no tasks are running on them.

Fargate launch type — AWS owns the capacity

Fargate removes the servers entirely. You pick CPU and memory per task and AWS handles everything underneath.

When to use this:

Variable or bursty traffic where you scale to zero or near-zero at night. You pay only for running tasks, so idle cost disappears.
Small teams that want to skip instance patching, AMI updates, and capacity planning.
Strong task isolation — each Fargate task runs in its own micro-VM, a stronger security boundary than co-tenant containers on a shared EC2 host.

When NOT to use this: GPU workloads, sustained high utilization where EC2 reservations win, or fine-grained bin-packing.

EC2 vs Fargate — side by side

Dimension	EC2 launch type	Fargate
Server management	You patch/scale instances	None — fully managed
Billing model	Per instance-hour (busy or idle)	Per task, per second
Best for	Steady, high utilization	Spiky, variable, low ops
GPU support	Yes	No
Bin-packing	Yes, fine-grained	No (one task = its own sizing)
Per-unit compute cost	Lower (if kept packed)	Higher
Isolation	Shared host	Micro-VM per task
Scale to zero cost	Instances still cost money	Truly zero when no tasks

Rule of thumb

Start on Fargate. Move steady, always-on workloads to EC2 only once utilization is consistently high and you will commit to a Savings Plan. Fargate’s simplicity is worth the premium until your bill says otherwise.

The cost gotcha is subtle: EC2 can be cheaper per unit of compute, but only if you actually keep the instances packed. A cluster of half-empty m6i.large instances wastes the savings — you pay for capacity you are not using. Fargate has no idle waste because you only pay for running tasks, so a poorly-packed EC2 fleet often ends up more expensive than Fargate in practice.

How to set the launch type

You choose the launch type (or capacity provider) when you create the ECS service.

Console steps:

Open the ECS console and choose your cluster.
Under Services, click Create.
In Compute configuration, pick Launch type, then choose FARGATE or EC2 (or pick a Capacity provider strategy to mix both).
Select your task definition, set the desired task count, and configure networking.
Click Create.

AWS CLI — Fargate service:

aws ecs create-service \
  --cluster prod-cluster \
  --service-name web \
  --task-definition web:7 \
  --launch-type FARGATE \
  --desired-count 3 \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c3d],securityGroups=[sg-0a1b2c3d],assignPublicIp=DISABLED}"

AWS CLI — EC2 service:

aws ecs create-service \
  --cluster prod-cluster \
  --service-name web \
  --task-definition web:7 \
  --launch-type EC2 \
  --desired-count 3

Output:

{
    "service": {
        "serviceArn": "arn:aws:ecs:us-east-1:111122223333:service/prod-cluster/web",
        "serviceName": "web",
        "launchType": "FARGATE",
        "status": "ACTIVE",
        "desiredCount": 3,
        "runningCount": 0
    }
}

A quick cost sanity check

Suppose one task needs 0.5 vCPU and 1 GB memory and runs 24/7. On Fargate (us-east-1, 2026 pricing) that is roughly $15-18/month per task with no idle waste. The equivalent on a shared t3.medium EC2 instance (2 vCPU, 4 GB) is about $30/month on-demand — but that one instance can hold several such tasks. Pack four tasks onto it and EC2 wins; run one task on it and Fargate is cheaper. The break-even is all about packing density.

Best practices

Default to Fargate for new services; switch to EC2 only when data shows sustained high utilization.
Use capacity providers to blend EC2 baseline + Fargate burst instead of choosing one rigidly.
On EC2, monitor cluster CPU/memory reservation — if instances sit below ~70% packed, you are wasting the cost advantage.
Buy Compute Savings Plans to cover steady EC2 (and Fargate) usage; they apply across both.
Use Fargate Spot or EC2 Spot for fault-tolerant, interruptible tasks to cut compute cost up to ~70%.
Right-size task CPU/memory in the task definition — over-provisioning costs the same waste on either launch type.
Reserve GPU and special-hardware workloads for EC2; Fargate cannot run them.