Home › Decoder › Fargate-vCPU-Hours:perCPU and Fargate-GB-Hours - Fargate task cost, and the cheaper arm64
Fargate-vCPU-Hours:perCPU and Fargate-GB-Hours - Fargate task cost, and the cheaper arm64
Fargate-vCPU-Hours:perCPU and Fargate-GB-Hours are what ECS on Fargate bills for task CPU and memory ($0.04048 per vCPU-hour and $0.004445 per GB-hour on x86 in US East N. Virginia); arm64 tasks cost $0.03238 and $0.00356.
In your bill the usage type reads: Fargate-vCPU-Hours:perCPU, USE1-Fargate-vCPU-Hours:perCPU, Fargate-GB-Hours, USE1-Fargate-GB-Hours
What it costs
| Charge | Price | Unit |
|---|---|---|
| Fargate x86 vCPU (Fargate-vCPU-Hours:perCPU) | $0.04048 | per vCPU-hour |
| Fargate x86 memory (Fargate-GB-Hours) | $0.004445 | per GB-hour |
| Fargate arm64 vCPU (Fargate-ARM-vCPU-Hours:perCPU) | $0.03238 | per vCPU-hour |
| Fargate arm64 memory (Fargate-ARM-GB-Hours) | $0.00356 | per GB-hour |
US East (N. Virginia); other regions differ. Checked 2026-11-04. Sources: AWS Fargate pricing, AWS price list file, ECS offer, us-east-1.
Example with made-up numbers
10 tasks, each 1 vCPU and 2 GB, running all month (730 hours)
vCPU: 7,300 x $0.04048 = $295.50; memory: 14,600 x $0.004445 = $64.90; total $360.40 per month on x86
On arm64: 7,300 x $0.03238 = $236.37; 14,600 x $0.00356 = $51.98; total $288.35 per month
Difference: $72.05 per month for these ten tasks
Typical causes
Task definitions default to x86
Unless the runtime platform says ARM64, tasks run on x86.
Images built only for amd64
CI builds a single architecture, so moving needs a pipeline change first.
Over-sized tasks
Tasks sized for a peak keep paying for the CPU and memory they reserve.
Idle environments left running
Staging services that run 24 hours bill for every hour.
Find it in your bill
Have a CUR file queryable in Athena? Paste this and run it:
SELECT date_trunc('month', line_item_usage_start_date) AS month,
line_item_product_code,
line_item_usage_type,
line_item_resource_id,
SUM(line_item_usage_amount) AS usage_amount,
SUM(line_item_unblended_cost) AS cost
FROM your_cur_table
WHERE line_item_usage_type LIKE '%Fargate-vCPU-Hours:perCPU'
OR line_item_usage_type LIKE '%Fargate-GB-Hours'
GROUP BY 1, 2, 3, 4
ORDER BY month DESC, cost DESC
LIMIT 50;Columns used: line_item_usage_start_date, line_item_product_code, line_item_usage_type, line_item_resource_id, line_item_usage_amount, line_item_unblended_cost.
No CUR file? Use Cost Explorer
- Open Billing and Cost Management, then Cost Explorer, and set the date range to the last 3 months with Monthly granularity.
- Set Group by to Usage type.
- In the Filters panel choose Usage type and tick the entries ending in Fargate-vCPU-Hours:perCPU or Fargate-GB-Hours (the region prefix, such as USE1-, differs by region).
- Read the monthly cost per usage type. A line that grows faster than your traffic is the one to chase with the fix below.
- To see which resource drives it, query the CUR above; resource IDs appear only if your CUR was set up with resource IDs included, otherwise the resource column is empty.
Column names checked against: docs.aws.amazon.com/cur/latest/userguide/Lineitem-columns.html, docs.aws.amazon.com/cur/latest/userguide/cur-ate-run.html.
The fix, step by step
Verify first
Check these before you change anything: the steps below are suggestions, and only you can see your own configuration.
- Check that every container image in the task has an arm64 manifest; a missing one makes the task fail to start.
- Compare CPU and memory use after the switch; tasks that run slower on arm64 may need more vCPU and lose part of the saving.
- Roll out one service at a time with a deployment circuit breaker so failed tasks roll back automatically.
- This applies to ECS on Fargate; check the Fargate pricing page for your platform and region before relying on the figures.
In the console
- ECS console > Task definitions; open the revision used by each service and check Operating system/Architecture.
- Build and push a multi-architecture (or arm64) image for each service and test it.
- Create a new task definition revision with Operating system/Architecture = Linux/ARM64 and the arm64 image.
- Update one non-production service to the new revision, check health and performance for a day, then repeat service by service.
- Update the infrastructure-as-code task definitions.
With the CLI
aws ecs list-task-definitions --status ACTIVE --output text
aws ecs describe-task-definition --task-definition my-task --query 'taskDefinition.runtimePlatform'
aws ecs register-task-definition --cli-input-json file://task-def-arm64.json # runtimePlatform: {"cpuArchitecture":"ARM64","operatingSystemFamily":"LINUX"}aws ecs update-service --cluster my-cluster --service my-service --task-definition my-task:NEW_REVISION
Rollback
Point the service back at the previous x86 task definition revision with update-service; ECS replaces the tasks.
Find your Fargate lines in your own bill
Drop in your Cost Explorer or CUR CSV. Billtrim reads it in your browser, finds the Fargate lines and shows the monthly dollars.
Paste your export: how to export a Cost Explorer CSV or CUR file in two minutes.
Questions people ask
Is memory billed separately from CPU?
Yes. Fargate bills vCPU-hours and GB-hours as two lines, which is why both appear above.
Does this apply to EKS on Fargate?
The prices above are for ECS on Fargate; check the Fargate pricing page for EKS.
Related
- Lambda-GB-Second - the Lambda compute line, and the 20% cheaper arm64
- NatGateway-Bytes: the NAT Gateway data-processing line
- LoadBalancerUsage and LCUUsage: what an ALB costs
Part of the guide: Reduce your AWS bill as a startup: a checklist for teams with no FinOps person