"Should we export CUR 2.0 or FOCUS?" is usually asked as though the two are alternatives. They are not. They answer different questions, and if you run EKS one of them cannot answer yours at all. Here is the difference, taken from the AWS column dictionaries rather than from vendor summaries.
What are CUR 2.0 and FOCUS, exactly?
Both are tables you create through AWS Data Exports. The names matter because they are what you query:
| CUR 2.0 | FOCUS 1.0 with AWS columns | |
|---|---|---|
| SQL table name | COST_AND_USAGE_REPORT | FOCUS_1_0_AWS |
| Schema | Fixed, 125 possible columns | FOCUS 1.0 plus five AWS columns |
| Standard | AWS proprietary | FOCUS, cross-cloud |
| Table configurations | Six | None |
Per the
CUR 2.0 table dictionary,
CUR 2.0 improves on legacy CUR in three ways: a "consistent schema", where
legacy CUR "columns included for CUR can vary monthly depending on your usage
of AWS services, cost categories, and resource tags"; "nested data", which
collapses sparse columns into key-value pairs; and additional columns
including bill_payer_account_name and
line_item_usage_account_name.
That first point is the one that matters if you are building a pipeline. A legacy CUR schema that changes shape month to month is a recurring integration cost. CUR 2.0 does not do that.
The
FOCUS 1.0 with AWS columns dictionary
describes a table "formatted with FinOps Open Cost and Usage Specification
(FOCUS) 1.0, along with five additional columns from AWS that contain
proprietary billing data". Those five are x_CostCategories,
x_Discounts, x_Operation,
x_ServiceCode and x_UsageType. AWS describes them as
its own additions rather than part of the specification, so treat anything
you build on them as AWS-specific even though the surrounding table is
portable.
Why can't FOCUS give you Kubernetes pod costs?
This is the single biggest practical difference, and it follows from two documented facts.
First, split cost allocation data is a table configuration on
CUR 2.0. The CUR 2.0 dictionary lists INCLUDE_SPLIT_COST_ALLOCATION_DATA
among six configurations, described as adding "split cost allocation data and
columns (split_line_item_*) to the CUR 2.0 table".
Second, the FOCUS dictionary states plainly: "There are no table configurations for the FOCUS 1.0 with AWS columns table."
So there is no switch to turn on. If you need per-pod cost, you need a CUR 2.0 export. A FOCUS export is the right choice for cross-cloud normalisation and the wrong choice for EKS chargeback, and no amount of querying will change that.
What do the split cost allocation columns actually contain?
Per Understanding split cost allocation data, the feature "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". The split line item reference notes the feature "is limited to Amazon ECS (including Fargate), AWS Batch, and Amazon EKS only".
| CUR 2.0 column | Type | What AWS says it is |
|---|---|---|
split_line_item_split_cost | double | Cost for vCPU or memory allocated to the task or pod, including amortized costs where the parent instance has upfront reservation or Savings Plan charges |
split_line_item_unused_cost | double | Cost of CPU, memory or accelerator resources on the parent instance "that were not utilized for the specified time period" |
split_line_item_net_split_cost | double | Effective cost after all discounts. Present "only when your account has a discount in the applicable billing period" |
split_line_item_net_unused_cost | double | Effective unused cost after discounts, same conditional presence |
split_line_item_actual_usage | double | Usage the task or pod actually incurred |
split_line_item_reserved_usage | double | Usage you configured, that is, the request |
split_line_item_split_usage | double | "the maximum usage of splitLineItem/ReservedUsage or splitLineItem/ActualUsage" |
split_line_item_split_usage_ratio | double | Allocated share of the parent instance's CPU, memory or accelerator resources |
split_line_item_parent_resource_id | string | The EC2 instance the pod ran on. EC2 launch type only |
split_line_item_public_on_demand_split_cost | double | Same allocation priced at public On-Demand rates |
split_line_item_public_on_demand_unused_cost | double | Unused portion at public On-Demand rates |
Names and types above are from the
CUR 2.0 split line item column reference.
The older
legacy CUR reference
documents the same fields in slash notation
(splitLineItem/SplitCost) and the two pages do not say quite the
same things, which matters below.
Four gotchas worth knowing before you build on it
SplitUsage is the max of request and actual, not actual. AWS defines it as "the maximum usage of splitLineItem/ReservedUsage or splitLineItem/ActualUsage". A pod that requests 2 vCPU and uses 0.1 is allocated cost on 2. That is defensible as chargeback, since the capacity was reserved, but it is not a measure of what the workload consumed, and reading it as one will make your efficiency numbers look far better than they are.
split_line_item_split_usage_ratio and hourly
granularity. The legacy CUR reference states the field "is only
available for AWS Cost and Usage Reports with a time granularity preference
of hourly data". The CUR 2.0 page does not repeat that restriction. Given
TIME_GRANULARITY accepts HOURLY, DAILY or MONTHLY, assume the
restriction still applies and verify against your own export before building
on the column, rather than trusting either page alone.
Two discount columns appear conditionally.
NetSplitCost and NetUnusedCost are "included in your
report only when your account has a discount in the applicable billing
period". A query that selects them unconditionally works in one account and
fails in another, which is a nasty way to discover a schema difference.
Row counts multiply. AWS gives the formula directly: for EKS,
(number of pods * average pod lifetime * 2) * 24 new usage
records per day, because two records are added per pod per hour for CPU and
memory. Their worked example: 1,000 pods at under an hour each produces
48,000 new usage records a day. On accelerated instances it
is three records per pod per hour, so 72,000.
What Kubernetes metadata does AWS give you for free?
Split cost allocation data "creates new cost allocation tags for some Kubernetes attributes", and they are enabled for cost allocation by default:
| Tag | Populated when |
|---|---|
aws:eks:cluster-name | Always, retrospectively |
aws:eks:namespace | Always, retrospectively |
aws:eks:node | Always, retrospectively |
aws:eks:workload-type | "only populated if there is exactly one workload managing the pod, and is one of the built in workloads" |
aws:eks:workload-name | With workload-type |
aws:eks:deployment | "only populated for the workload type ReplicaSet" |
Workload types are ReplicaSet, StatefulSet,
Job, DaemonSet and
ReplicationController. The two conditional rules above are worth
reading twice, because they are where cluster-wide attribution quietly
develops holes: a pod owned by a custom controller, or by more than one
workload, gets no workload type and no workload name. Group by workload alone
and those pods vanish from the report rather than showing as unattributed.
This is also the honest limit of what CUR alone can tell you. It gives you cost per pod with the ownership metadata AWS can infer from the EKS control plane. It does not give you container-level utilisation over time, anything about pods on clusters outside EKS, or labels AWS does not mint itself. For that you need something running in the cluster. We have written separately about what an in-cluster agent adds on top of SCAD.
Which should you export?
Both, if you have the storage budget, and here is the decision if you do not.
| If you need | Export | Because |
|---|---|---|
| EKS or ECS cost per pod or task | CUR 2.0 | SCAD is a CUR 2.0 table configuration; FOCUS has no configurations |
| One schema across AWS, Azure and GCP | FOCUS | That is the specification's entire purpose |
| Resource-level line items | CUR 2.0 | INCLUDE_RESOURCES adds line_item_resource_id |
| Bedrock cost per IAM principal | CUR 2.0 | INCLUDE_IAM_PRINCIPAL_DATA, data from 8 April 2026 |
| Capacity reservation attribution | CUR 2.0 | INCLUDE_CAPACITY_RESERVATION_DATA, data from 1 November 2025 |
Note the two dates in that table. Both configurations "only add data in the new columns" from those dates, so enabling them does not backfill. If you want that history, turn them on now rather than when you need the report.
We run both exports daily into a single S3 data lake and query them with Athena using partition projection, which is the practical setup: FOCUS for the portable summary, CUR 2.0 for anything that has to reach a pod. See our notes on where network charges show up in the CUR for a worked example of reading usage types out of the same table.