EKS split cost allocation data: the two choices that change your numbers (2026)

Most write-ups of split cost allocation data stop at "turn it on and you get pod costs". The interesting part is what happens in between, and there are two decisions baked into it that change your numbers materially. One of them is a radio button most people click past. The other is a weighting AWS borrowed from a different service entirely.

How do you turn it on?

It is a billing preference, not a cluster setting, and it is a prerequisite before any report can include the data. Per Enabling split cost allocation data, you opt in under Cost Management preferences in the Billing console, then separately tick Split cost allocation data on the report itself.

Three things about that are easy to trip over:

• "Only regular and payer accounts have access to the AWS Cost Management preferences and can opt in". A member account cannot enable it, only view the result.
• "It can take up to 24 hours for the data to be visible in AWS CUR." If you enable it and query immediately, the absence of rows means nothing.
• It is "not available in Cost Explorer. It is available in legacy Cost and Usage Reports (CUR) and Cost and Usage Report 2.0 (CUR 2.0) with Data Exports." AWS also describes activation as preparing "the granular cost data for the current month", which reads as no backfill, though it does not say so outright. Either way, turn it on before you need the history rather than after.

Which measurement option should you pick?

This is the radio button, and it is the single most consequential choice in the feature. For EKS, AWS offers three:

The trap is in the Resource requests option, and it is quoted directly: "If you choose resource requests, only the pods configured with memory and CPU requests are used by split cost allocation data. Pods that haven't requested any usage won't see any split cost data."

Read that again if you run a real cluster. Pods with no resource requests do not get under-allocated or over-allocated. They get nothing. In a cluster where a meaningful share of workloads ship without requests, which is most clusters that have not been through a rightsizing exercise, your chargeback report silently omits them and every namespace total is wrong in the same invisible direction.

One more constraint worth knowing before you pick: "For accelerated computing instances, only the Resource request option is supported... the system will default to Resource request to compute accelerator, CPU, and memory costs, even if other measurement options are enabled." So on GPU nodes you get requests-based allocation whether you chose it or not.

How does AWS actually compute the split?

This is documented and worked through with numbers in Example of split cost allocation data, and it contains the fact that surprises people most.

Your EC2 instance is priced using Fargate's weights

The weights are not derived from the instance you are actually running. AWS states: "Split cost allocation data uses relative unit weights for CPU and memory based on a 9:1 ratio. This is derived from per vCPU per hour and per GB per hour prices in AWS Fargate."

So a vCPU-hour is treated as nine times more valuable than a GB-hour, everywhere, on every instance type, using a ratio taken from a different service's price list. On AWS's own worked example, an m5.xlarge at $1/hour amortized:

Unit cost   = $1 / ((1 × 16 GB) + (9 × 4 vCPU))
            = $1 / 52 = $0.01923
Per vCPU-hr = 9 × $0.01923 = $0.17
Per GB-hr   = 1 × $0.01923 = $0.02

A note on the arithmetic, because it will not reconcile otherwise. AWS's example displays the unit cost rounded to $0.02, then gives $0.17 per vCPU hour. Nine times $0.02 is $0.18. The published figure is right and the rounding is display-only: the unadjusted unit cost is $1/52 = $0.01923, and nine times that is $0.173. Use the unrounded value if you are reimplementing this, or your numbers will drift from your bill.

AWS documents the ratio but not its consequences, so the following is our reading rather than something AWS states. Because the weighting is fixed, it cannot know that a memory-optimised instance is mostly paying for memory. On such an instance a memory-heavy pod is therefore allocated relatively less cost than its share of what the machine actually costs you, and a CPU-heavy neighbour picks up the difference. The split stays internally consistent and always sums back to the instance cost. It is simply not a market-rate valuation of what each pod consumed, and on skewed instance families the gap is worth measuring before you bill anyone on it.

What happens when pods use more than they request?

AWS's example includes this case deliberately, and it is where the intuition breaks. Four pods on a 4 vCPU instance, and Pod2 uses 1.9 vCPU against a request of 1:

Total allocation exceeds instance capacity, which AWS describes as "CPU over subscription, attributed to Pod2 that used more vCPU than what was reserved". Unused CPU is then max(4 − 4.9, 0) = 0.

The subtlety is in the denominator. Pod1's ratio is computed as 1 / 4.9 = 0.204, so the divisor is total allocated, not the instance's 4 vCPU. That keeps the ratios summing to 1 and the split summing back to the instance cost, but note it does not match the column reference, which describes the ratio as compared to "the overall CPU or memory available on the EC2 instance". In the oversubscribed case those are different numbers, and the example is the one to trust.

Unused capacity is not left aside either. It is redistributed across pods proportionally, so a pod on a half-empty instance carries a share of the waste. In the worked example Pod1's $0.22 split cost becomes $0.23 once its share of unused memory is added.

What happens with Savings Plans and Reserved Instances?

Handled, and more carefully than you might expect. The example states that with a Savings Plan covering the whole instance, "amortized costs are computed using savingsPlan/SavingsPlanEffectiveCost". With partial coverage, costs are "computed using savingsPlan/SavingsPlanEffectiveCost (for SavingsPlanCoveredUsage) + lineItem/UnblendedCost (for On-Demand usage)".

So pod cost reflects your negotiated rate rather than list price, which is what you want for chargeback and is a real advantage over any tool computing pod cost from public pricing.

Where is it silent?

Worth stating plainly, because these are the gaps a chargeback conversation eventually runs into.

• Pods with no requests, under the Resource requests option. Not approximated. Absent.
• Anything that is not ECS, AWS Batch or EKS. A self-managed cluster on EC2 gets no split data at all, which is one reason finding those clusters is a separate problem.
• Non-compute cost. The split covers the EC2 instance. Load balancers, storage and the data transfer your pods generate are not allocated to pods by this feature.
• Utilisation over time. You get an hourly allocation, not a time series you can rightsize against.
• FOCUS exports. Split cost allocation is a CUR 2.0 table configuration, and the FOCUS table has none. See CUR 2.0 vs FOCUS for why that is structural rather than an oversight.

None of that makes SCAD the wrong tool. It is the most accurate pod cost available from AWS itself, priced at your actual rates, and it should be the cost source of record. It just answers "what did this pod cost" and not "was that a reasonable amount", and those are different questions.