ECS split cost allocation data, and how it differs from EKS (2026)

Split cost allocation data is usually described as an EKS feature. It is not: AWS's own documentation opens by saying you can use it "to track your Amazon ECS and Amazon EKS container costs". But the two are not the same feature with a different noun. What you get for free, what you have to tag yourself, and which resources can be split at all differ in ways that decide whether task-level chargeback works.

What does split cost allocation data actually do?

It manufactures line items that did not previously exist. Per the split cost allocation data documentation: "split cost allocation data introduces cost and usage data for new container-level resources (that is, ECS tasks and Kubernetes pods) to AWS CUR. Previously, AWS CUR only supported costs at the EC2 instance level."

The mechanism is the same for both:

"Split cost allocation data generates container-level costs by looking at each container's EC2 instance resource consumption, and generates cost based on the amortized cost of the instance and the percentage of CPU and memory resources consumed by the containers that ran on the instance."

Two things follow from that sentence and both matter. It works from the amortized cost of the instance, so Savings Plan and Reserved Instance coverage is already reflected rather than being something you apply afterwards. And it splits on CPU and memory percentages, which is where the weighting question from the EKS side of this feature comes in.

How many rows does it add?

AWS publishes the formula, which is unusual and worth using before you switch it on. "Two new usage records are added for each ECS task and Kubernetes pod per hour in order to reflect the CPU and memory costs."

ECS:  (number of tasks * average task lifetime * 2) * 24
EKS:  (number of pods  * average pod lifetime  * 2) * 24

AWS's own worked example:

"If you have 1,000 pods running each hour across a cluster of 10 EC2 instances and the lifetime for the pod is less than 1 hour, then: (1000 * 1 * 2) * 24 = 48,000 new usage records in AWS CUR"

Forty-eight thousand rows a day, from a thousand pods. That is per day, so roughly 1.5 million rows a month from a single modest cluster, before you count anything else in the account.

This is the number to take seriously if you run short-lived tasks. ECS batch jobs and Fargate tasks that live minutes rather than days multiply the task count without changing your compute bill at all, so the CUR grows while the thing it describes does not. Everything downstream pays for that: S3 storage for the export, and bytes scanned on every query. If you query the CUR through Athena, this is the moment partition projection and a tight partition predicate stop being a nicety.

What does ECS give you for free? Almost nothing

This is the biggest practical difference between the two, and it is easy to miss because it sits in a note rather than a heading.

For ECS, AWS says: "when it comes to AWS cost allocation tags, you can use Amazon ECS-managed tags or user-added tags for your Cost and Usage Reports. These tags apply to all new ECS split cost allocation data usage records."

That is the whole story. ECS split records carry whatever tags you or ECS already put on the resources. There is no service-generated dimension describing the workload. If your tasks are not tagged, you get task-level costs with no task-level meaning: rows keyed by task ID and nothing that says which team or service owns them.

EKS is the opposite. Split cost allocation data creates six tags for you:

Those are "enabled for cost allocation by default", with one exception worth checking: "if you previously used and disabled the aws:eks:cluster-name tag, then split cost allocation data keeps this setting and doesn't enable the tag."

The practical consequence for anyone running both: an EKS cluster produces usable chargeback the day you enable the feature, and an ECS cluster produces usable chargeback only if you did the tagging work first. Plan the ECS side as a tagging project, and remember that activation is separate from tagging and is not retroactive, which is covered in why cost allocation tags show up empty.

What are the workload-type gaps?

On the EKS side, two of the six tags are conditional and the conditions bite in normal clusters.

aws:eks:workload-type is "only populated if there is exactly one workload managing the pod, and is one of the built in workloads", where the types are ReplicaSet, StatefulSet, Job, DaemonSet or ReplicationController. So a pod managed by a custom controller or a CRD-based operator, which is most of the interesting workloads in a mature cluster, gets no workload tag at all. Its cost is still split; it just arrives unlabelled.

aws:eks:deployment is narrower still: "only populated for the workload type ReplicaSet. It is the deployment that creates a ReplicaSet." StatefulSets, DaemonSets and Jobs have no deployment tag, which is correct but means a single "group by deployment" query silently omits a large part of the cluster.

Namespace is the dimension that is always there for EKS, which is why it makes a better default grouping than workload for a first pass.

What about GPUs?

Supported, and EKS only. "For accelerated computing instances used with Amazon EKS, split cost allocation data includes resource allocation for specialized processors alongside CPU and memory. This covers NVIDIA and AMD GPUs, AWS Trainium, and AWS Inferentia accelerators."

Then, unambiguously:

"The feature is available only for Amazon EKS environments and provides pod-level resource reservation data for these accelerated computing resources."

So an ECS task on a GPU instance does not get its accelerator cost split out. If you run inference on ECS and need per-task GPU attribution, split cost allocation data will not produce it, and that is a reason to weigh EKS for that specific workload rather than a gap you can configure around.

Accelerated pods also change the row arithmetic, because they add a third record: "three new usage records are added for each Kubernetes pod per hour". AWS's example gives (1000 * 1 * 3) * 24 = 72,000 records a day, half again as many as the CPU-and-memory case.

ECS and EKS, side by side

How do you turn it on?

It is a CUR 2.0 table configuration rather than a console toggle on the cluster. INCLUDE_SPLIT_COST_ALLOCATION_DATA "adds split cost allocation data and columns (split_line_item_*) to the CUR 2.0 table", and AWS notes that "enabling this configuration can add additional rows and columns".

Because it is a table configuration, it is a CUR 2.0 capability specifically. FOCUS exports have no table configurations, which is the reason FOCUS cannot produce per-pod or per-task cost no matter how you configure it. If you standardised on FOCUS for cross-cloud reporting, you need a CUR 2.0 export alongside it for anything that has to reach a container.

Once it is on, start from namespace or task tag and total cost, confirm the sum reconciles to the instance cost it was split from, and only then go looking for per-workload numbers. The split is an allocation of a real instance bill, so if the parts do not add up to the whole, the problem is your query rather than the data.