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

ChargePriceUnit
Fargate x86 vCPU (Fargate-vCPU-Hours:perCPU)$0.04048per vCPU-hour
Fargate x86 memory (Fargate-GB-Hours)$0.004445per GB-hour
Fargate arm64 vCPU (Fargate-ARM-vCPU-Hours:perCPU)$0.03238per vCPU-hour
Fargate arm64 memory (Fargate-ARM-GB-Hours)$0.00356per 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

  1. Open Billing and Cost Management, then Cost Explorer, and set the date range to the last 3 months with Monthly granularity.
  2. Set Group by to Usage type.
  3. 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).
  4. Read the monthly cost per usage type. A line that grows faster than your traffic is the one to chase with the fix below.
  5. 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

  1. ECS console > Task definitions; open the revision used by each service and check Operating system/Architecture.
  2. Build and push a multi-architecture (or arm64) image for each service and test it.
  3. Create a new task definition revision with Operating system/Architecture = Linux/ARM64 and the arm64 image.
  4. Update one non-production service to the new revision, check health and performance for a day, then repeat service by service.
  5. 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.

See a sample result

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

Part of the guide: Reduce your AWS bill as a startup: a checklist for teams with no FinOps person