ECS Task Sizing Calculator (CPU & memory -> task count)

This page solves sizing before pricing

ECS task sizing is upstream of cost. If task count is wrong, every Fargate or EC2 cost estimate built on top of it will also be wrong. That is why this page should focus on resource demand, headroom, and safe task count before any pricing model is applied.

• CPU constraint: task count rises when vCPU demand is the bottleneck.
• Memory constraint: task count rises when memory saturation arrives first.
• Recommendation rule: the higher of the two counts should drive planning.

Where ECS sizing estimates usually go wrong

• A single calm-month average is used without a separate deployment or incident envelope.
• High utilization targets are chosen without leaving room for rolling deploys or transient bursts.
• CPU and memory are blended into one intuition instead of tested as separate constraints.
• Sizing is treated as a billing problem before service behavior has been measured.

What to review before carrying this into a cost model

• Measure CPU and memory demand from representative service history, not from one unusual peak.
• Lower utilization targets when you expect deployment overlap, burst traffic, or noisy-neighbor sensitivity.
• Use separate baseline and stress scenarios so the recommended task count is honest about operational headroom.
• Only after task count is credible should you hand the result to Fargate or EC2 pricing pages.

Baseline vs headroom-sensitive sizing scenarios

How to validate the sizing result in production

• Check whether CPU or memory saturation is the real scaling trigger once the service runs under normal and burst traffic.
• If production task count is higher than planned, identify whether the miss came from headroom, deployment overlap, or the wrong dominant resource.

Next steps