AWS Fargate Cost Calculator

Fargate bills are mostly about steady task-hours

This page is strongest when you already know the service runs as persistent tasks. Fargate cost usually does not hinge on one request spike in isolation. It is driven by the monthly accumulation of running tasks, vCPU per task, and memory per task across real uptime windows.

• Main driver: average running tasks, not desired count and not short-lived peak count.
• Sizing lever: task shape determines whether memory or vCPU dominates the bill.
• Operational boundary: this page is compute-only, so adjacent network and observability lines stay separate.

Where Fargate estimates usually drift

Teams often misread Fargate by sizing from peak tasks, copying task definitions that carry too much headroom, or forgetting that always-on background services silently accumulate hours even when user traffic looks quiet.

• Peak-first modeling: using surge count as the monthly baseline makes always-on services look too expensive.
• Over-sized task definitions: memory-heavy task shapes can keep costs elevated even when CPU is mostly idle.
• Mixed workload shapes: cron, worker, and API services should not share one average task assumption.
• Adjacent lines: NAT, egress, ALB, logs, and metrics can rival compute but should not be hidden in this number.

What to validate before you trust the baseline

• Pull average running tasks from ECS metrics or billing-backed history rather than from deployment intent.
• Review whether memory or vCPU is the real bottleneck before changing task count.
• Separate always-on services from burst or schedule-based tasks so the model reflects real runtime behavior.
• Keep transfer, load balancers, and logs as separate cost lines instead of treating Fargate as the whole service bill.

Baseline vs autoscaling burst scenarios

How to reconcile the first real Fargate bill

• Compare billed vCPU-hours and GB-hours to the service-level average task history instead of to peak alerts.
• Check whether the main gap came from task count, task size, or uptime before changing multiple assumptions at once.

Next steps