EKS & ECS Cost Visibility via AWS Split Cost Allocation Data
CloudForecast’s container cost visibility leverages AWS Split Cost Allocation Data to provide per-deployment, per-namespace, and per-service insights for EKS and ECS. This guide explains what the data means, how it’s derived, and how it differs from traditional AWS billing metrics.
☁️ What Is Split Cost Allocation Data?
AWS introduced Split Cost Allocation Data to break down the cost of shared resources like EC2 or Fargate across individual containers (ECS tasks or EKS pods). This data appears in the Cost and Usage Report (CUR) as a new column: split_line_item_split_cost.
- What we show in CloudForecast: Costs broken down to ECS services or EKS deployments/namespaces based on that
split_line_item_split_costcolumn. - How AWS calculates it: Costs are estimated based on container CPU and memory usage with a default 9:1 weighting (CPU:Memory) for cost allocation (source).
📊 What You See in CloudForecast
| Metric | Data Source | Description |
|---|---|---|
| AWS Costs | line_item_unblended_cost or amortized_cost | The total actual billed cost for AWS resources (e.g., EC2, Fargate, EBS). Users can toggle between Unblended and Amortized views in CloudForecast, depending on their preference. |
| EKS/ECS Cost (Split) | split_line_item_split_cost | Estimated cost of containerized workloads, split proportionally based on CPU/Memory usage. This data is always amortized by AWS. |
| Cluster/Service-level Views | Derived from CUR + AWS metadata | Enables granular breakdowns by namespace, deployment, or ECS service, depending on the context. |
Understanding Gaps and Mismatches
It’s essential to understand what is and isn’t included in Split Cost Allocation data:
| Consideration | Explanation |
| Unused resources aren’t included | If your cluster has idle CPU or memory, that unused portion is still billed by AWS (in line_item_unblended_cost) but won’t show up in split_line_item_split_cost. |
| Estimates vs Actuals | The split_cost column provides cost attribution estimates — not what you are billed. |
| Not all services are split | Only workloads running in ECS/EKS are considered; other AWS services (S3, Lambda, etc.) aren’t broken down. |
| Amortization | The split cost AWS provides is already amortized and accounts for reservation/commitment models. |
| Cluster-level totals ≠ Actual AWS totals | Due to underutilization, the sum of deployment or namespace costs will often be significantly lower than the actual AWS bill. This is expected behavior. |
Example Scenario
You run a single EC2 instance for EKS:
- Actual AWS cost: $100/day (from
line_item_unblended_cost) - You run two pods, each using 1 CPU and 9GB RAM, totaling 2 CPU / 18GB usage out of 4 CPU / 36GB
- Estimated container cost: ~$50/day (from
split_line_item_split_cost)
Why the mismatch?
Because you’re only using half the available capacity — the rest is unused but still billed by AWS.
Pro Tips for Interpreting Data
- “AWS Cost” is what you pay. “EKS/ECS Cost” is what you use. Use both together to assess efficiency.
- When comparing with other tools like CAST.ai, expect differences:
- CAST might report full cluster costs (including idle time).
- CloudForecast only shows container-allocated costs.
- Avoid over-attributing unused cluster costs to teams — it’s better to surface what they actually used.
FAQs
Why doesn’t my EKS deployment cost match the actual AWS bill?
Because AWS Split Cost Allocation only includes used container resources, not unused capacity.
Can I get costs broken down by cluster?
Yes — but remember, cluster-level totals may not reflect all AWS charges due to idle capacity.
Is this cost data accurate?
It’s as accurate as AWS’s allocation model. It’s not perfect, but it’s the best source of truth without running agents in your clusters.
Can I use this for showback/chargeback?
Yes — but it should be paired with context. For true cost accountability, consider overlaying usage patterns, SLOs, and efficiency metrics.