About the ECS Hosting Calculator
Fargate pricing is per vCPU-second and per GB-second of the task size you request, which makes the estimate arithmetic rather than guesswork — but only once you know what you are actually requesting. Fargate offers a fixed set of CPU and memory combinations, and a task definition specifying anything outside that table is rejected at registration rather than adjusted — so the size you pick is the size you are billed for.
The cost people forget is everything around the container. A load balancer has an hourly charge plus capacity units, NAT gateways charge per hour and per gigabyte processed, and CloudWatch Logs charges for ingestion and storage. On small deployments these frequently exceed the compute they support.
For AI and inference workloads the picture changes again. Model containers are memory-heavy, and Fargate's memory-to-CPU ratios mean you often pay for CPU you do not use in order to get the memory you need. Check whether the ratio you require is one Fargate offers before assuming it is the cheaper option.
Frequently asked questions
Is Fargate more expensive than EC2 for the same workload?
Per unit of compute, generally yes. Whether it costs more in total depends on utilisation — well-packed EC2 instances running steadily are cheaper, while instances sized for peak and idle much of the time may not be. Include the engineer time spent on patching, scaling and capacity planning, which Fargate removes.
Why is my bill higher than the task cost?
Almost always the supporting infrastructure. Load balancers, NAT gateway data processing, log ingestion and cross-AZ traffic each carry their own charges and none appear in a per-task calculation. NAT gateway processing in particular surprises teams whose containers pull large images or call external APIs frequently.
Do I have to use the predefined CPU and memory combinations?
Yes — Fargate supports specific pairings, and a task definition that does not match one fails to register with an `Invalid 'cpu' setting for task` error. Because the valid steps are coarse, a small increase in required memory often forces you up to the next CPU tier, which raises cost more than the memory alone suggests.
Does Fargate Spot make sense?
For interruption-tolerant work, yes, and the discount is substantial. Tasks receive a termination notice with a short grace period, so the workload must handle being stopped and rescheduled. It suits batch processing and stateless workers; it does not suit anything holding long-lived connections or in-progress state.
How should I size a task I have not run yet?
Start deliberately generous, measure actual utilisation, then reduce. Under-sizing produces CPU throttling and out-of-memory kills that read as application bugs and cost far more engineering time than the compute saved. Size down once you have real numbers rather than guessing low first.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.