ECS Cost Allocation 101: How Much Does Each Service Really Cost?

Amazon ECS hides real costs behind aggregate EC2, Fargate, and networking bills. Without a translation layer, you cannot tell whether orders-service or sync-worker is burning the budget. ClusterCost’s ECS agent gives you that map. Here’s how it works and how you can mirror the math in your own reports.

1. Understand the building blocks

ECS spend usually comes from five buckets:

1. Compute – EC2 instances or Fargate tasks.
2. Storage – EBS or EFS volumes attached to tasks.
3. Networking – Load balancers, NAT, data transfer, PrivateLink.
4. Service overhead – CloudWatch logs, parameter store, Service Discovery.
5. Shared platform – CI/CD runners, container registry pulls, artifact storage.

Tracing each bucket to the owning ECS service is step one.

2. Attribute EC2-backed services

For EC2 launch type:

• Divide each instance’s hourly cost by the total CPU and memory reserved by tasks on that instance.
• Multiply a task’s reservation (or usage) by the per-unit cost to determine its share.
• Add EBS volume cost if the task mounts persistent storage.

Pseudocode:

task_share = (task_cpu / instance_total_cpu) * instance_hourly_cost

ClusterCost performs this calculation continuously using CloudWatch metrics and ECS metadata.

3. Attribute Fargate services

Fargate publishes exact per-second pricing for vCPU and memory plus a flat fee for Windows and GPU workloads. For each task:

cost = (vCPU requested * price_per_vCPU_second + memory requested * price_per_GiB_second) * runtime_seconds

ClusterCost also adds data transfer and ephemeral storage when relevant so you get the complete bill.

4. Handle shared networking

Load balancers and NAT gateways often serve multiple services. Choose a policy:

• Request-based – attribute by number of requests per service (works for ALB/NLB).
• Bandwidth-based – use bytes transferred for data-heavy services.
• Even split – for shared NAT gateways when traffic differences are negligible.

Document the policy in COST_ALLOCATION.md so everyone agrees.

5. Roll up by service, team, or environment

Once task costs are available, aggregations are easy:

ClusterCost exposes these cuts in the UI and via API exports for BI tools.

6. Turn data into action

• Spot idle services: compare desired vs. running tasks and CPU usage to flag zombie capacity.
• Size reservations: highlight tasks where requested CPU is 3x higher than peak usage.
• Optimize launch type: show where moving from Fargate to EC2 or vice versa reduces spend without sacrificing velocity.

7. Automation checklist

• Deploy ClusterCost ECS agent in each cluster/account.
• Tag services with team, customer, and environment labels.
• Decide on networking allocation rules.
• Share weekly ECS cost digests with engineering and finance.

With these steps you will finally know what every ECS service costs per hour, per customer, and per deployment. Decisions stop being gut feelings and start being data-backed.***