ECS Task Sizing Calculator (CPU & memory -> task count)
Estimate required ECS tasks from average resource demand. Compare baseline vs peak demand to set a safe recommended task count.
Inputs
Total vCPU needed (average)
Total memory needed (GB, average)
vCPU per task
Effective vCPU: 0.35
Memory per task (GB)
Effective memory: 0.7 GB
Target utilization (%)
Use average CPU/memory demand, not peak. For safety, target 60-80% utilization instead of 100%.
Scenario presets
Results
Tasks needed (CPU)
6
Tasks needed (memory)
6
Recommended tasks
6
CPU utilization (at recommended)
6,667%
Memory utilization (at recommended)
6,667%
This sizes tasks only. Use a pricing calculator (Fargate or EC2) to convert task count into monthly cost.
How to get your inputs
- Inputs: use billing exports, metrics, or logs to get real counts/GB where possible.
- Units: convert throughput (Mbps) or rates (RPS) into monthly units when needed.
- Scenarios: build a baseline and a high-usage scenario to avoid under-budgeting.
Result interpretation
- If CPU and memory recommend different task counts, the higher value should drive sizing.
- Very high utilization targets can lead to unstable performance under burst traffic.
Common mistakes
- Using a single average and ignoring peak/incident scenarios.
- Double-counting or missing adjacent line items (transfer, logs, retries).
Scenario planning
| Scenario | Total vCPU | Total memory | Utilization |
|---|---|---|---|
| Baseline | Average | Average | 70-80% |
| Peak | High | High | 60-70% |
Validate after changes
- Compare your estimate to the first real bill and adjust assumptions.
- Track the primary driver metric (requests/GB/count) over time.
Next steps
Advertisement
Example scenario
- If your service needs ~2 vCPU and ~4 GB on average, and each task is 0.5 vCPU / 1 GB at 70% utilization -> estimate tasks.
- Use average demand, not peak. Add headroom for spikes and deployments.
- Peak 180% scenario shows how many tasks to reserve for burst traffic.
Included
- Task count estimate from average vCPU and memory demand.
- Target utilization to keep headroom (planning).
- Baseline vs peak scenario table for recommended tasks.
Not included
- Pricing (use Fargate or EC2 pricing calculators after sizing).
- Load balancers, logs, networking, and storage.
How we calculate
- Effective capacity per task = per-task capacity x target utilization.
- Tasks by CPU = ceil(total vCPU needed / effective vCPU per task).
- Tasks by memory = ceil(total GB needed / effective GB per task).
- Recommended tasks = max(tasks by CPU, tasks by memory).
FAQ
What should I use for total vCPU and memory needed?
Use measured averages from monitoring (p50/p95 where relevant) and pick a realistic planning average. Don't size from peak-only numbers unless you also model autoscaling and scheduling.
What target utilization should I use?
Common planning values are 60-80% to keep headroom for bursts, deployments, and noisy neighbors.
How do I convert tasks into cost?
For ECS on Fargate, use the Fargate cost calculator (vCPU-hours + GB-hours). For ECS on EC2, estimate required instances and use the EC2 cost calculator.
Related tools
Related guides
S3 pricing: a practical model for storage, requests, egress, and replication
A practical S3 pricing guide: what to include (GB-month, requests, egress, replication) and how to estimate the key inputs without copying price tables.
CDN cost comparison: how to compare pricing across providers
A practical framework to compare CDN pricing across providers: normalize bandwidth, requests, regions, cache fill, and contract terms before choosing the lowest total cost.
Cloud cost estimation checklist: build a model Google (and finance) will trust
A practical checklist to estimate cloud cost without missing major line items: requests, compute, storage, logs/metrics, and network transfer. Includes a worksheet template, validation steps, and the most common double-counting traps.
Copy storage pricing: what you pay for when data moves
A practical guide to pricing storage copy operations (cross-region copy, replication, backups) across S3-like object storage: transfer, requests, and extra storage.
Google Kubernetes Engine (GKE) pricing: nodes, networking, storage, and observability
GKE cost is not just nodes: include node pools, autoscaling, requests/limits (bin packing), load balancing/egress, storage, and logs/metrics. Includes a worked estimate template, pitfalls, and validation steps to keep clusters right-sized.
S3 CRR vs SRR cost: what changes (transfer, storage, requests)
A practical cost comparison of S3 cross-region replication (CRR) vs same-region replication (SRR). Compare transfer/feature fees, extra replica storage, and request costs - with calculators.
Advertisement
Disclaimer
Educational use only. Not legal, financial, or professional advice. Results are estimates based on the inputs and assumptions shown on this page. Verify pricing and limits with your providers and documentation.
Last updated: 2026-01-28