In 2026, AWS Data Exports gives you two serious options: Cost and Usage Report 2.0, and FOCUS 1.2 with AWS columns added. People often ask which one is better, and the honest answer is that it depends on who reads the data. CUR 2.0 is the detailed, AWS-native dataset. FOCUS 1.2 gives you standard cost and usage semantics you can use across providers.
Start from the decisions the data has to support and the fields those decisions need. If finance wants one model across providers while engineering digs into AWS-specific discounts or product attributes, two well-controlled exports are often cleaner than one export stretched to do both jobs.
The short decision
| Need | Preferred starting point | Why |
|---|---|---|
| Migrate an existing CUR pipeline | CUR 2.0 | AWS documents a compatibility path and AWS-oriented structure |
| Investigate AWS-specific cost | CUR 2.0 | Broader AWS fields and nested product, discount, tag, and cost-category data |
| Use one model across providers | FOCUS 1.2 | Standard terms and columns across provider boundaries |
| Reconcile invoices in a FOCUS pipeline | FOCUS 1.2 | Includes fields such as InvoiceID and InvoiceIssuerId |
| Analyse capacity reservations in the standard model | FOCUS 1.2 | Dedicated capacity-reservation identity and status fields |
| Support deep AWS analysis and multi-provider reporting | Both | Separate stable consumers may justify separate reconciled data products |
For a new export, we would not start on FOCUS 1.0 any more. AWS now supports FOCUS 1.2 with AWS columns and documents breaking changes from 1.0.
What CUR 2.0 is good at
CUR 2.0 has a fixed schema compared with legacy CUR. Several formerly dynamic column groups become nested key-value fields, including resource tags, cost categories, product, and discount. Data Exports also supports limited SQL selection, filtering, and aliases.
CUR 2.0 fits when:
- existing AWS queries and data products need migration;
- analysis depends on AWS-specific product or discount detail;
- columns and rows should be reduced in the export definition;
- AWS engineering and FinOps are the main consumers.
A fixed schema still changes underneath you. Values, nested keys and export settings can all break downstream logic, so version your schema assumptions and test against real rows for every charge type you care about.
What FOCUS 1.2 is good at
FOCUS defines shared concepts for fields such as Billed Cost, Effective Cost, Service, SKU, Charge Category, and Commitment Discount. AWS adds a small set of provider-specific columns to its standard export.
AWS highlights these FOCUS 1.2 changes from 1.0:
- InvoiceID for invoice association;
- capacity-reservation identity and status;
- additional pricing-currency fields;
- new service and SKU detail;
- changed row formation and values for some commitment cases;
- configurable hourly, daily, or monthly granularity.
FOCUS fits when one set of downstream logic has to read AWS, Azure or other supported sources. It cuts the translation work, but providers still differ: null values, conformance gaps and the extra AWS columns all need handling on purpose.
Do not turn a shared column name directly into policy
Two providers using the same column name does not mean your company uses it the same way. Settle these rules before anyone writes a pipeline:
| Business term | Rule to define |
|---|---|
| Monthly cost | Billed, actual, amortized, or effective cost? |
| Consumption owner | Account, tag, cost category, or an internal rule? |
| Commitment purchase | In which report and period does it appear? |
| Unused commitment | Which owner receives the residual? |
| Credit and refund | Original period or posting period? |
| Invoice | Which identifiers and totals are the reconciliation basis? |
| Currency | Billing, pricing, or reporting currency? |
Put these rules into mappings and tests, not just into a dashboard. If they only live in the dashboard, switching exports can quietly change a number management relies on.
When running both is justified
AWS lets you create several exports per table. That does not mean you should. A second dataset earns its place only when it serves a different consumer with stable needs.
A pattern that works:
- FOCUS 1.2 feeds normalised cross-provider reporting.
- CUR 2.0 feeds AWS-specific investigations not covered by the standard export.
- Both reconcile to the same AWS invoice for each billing period.
- A documented key relates payer, billing period, and the relevant charge population.
- No measure sums both datasets together.
Don't build a near-identical second pipeline just in case. If FOCUS already covers every decision you make today, an extra CUR 2.0 feed is something to run and monitor with nothing to show for it.
Process delivery and corrections safely
AWS delivers Data Exports files with a Manifest.json. CUR 2.0 refreshes at least daily, and AWS may update the previous billing period after period end. Exports can overwrite previous files or retain each execution separately.
A pipeline that survives this does six things:
- Use the manifest, not a file glob, as the delivery inventory.
- Process export execution and billing period idempotently.
- Accept corrections to an already loaded period as a new version.
- Do not interpret empty chunks in overwrite mode as a zero-cost period.
- Reconcile source total, loaded rows, and transformed total.
- Block management-view updates when schema or nullability checks fail.
A short selection test
Pick one representative, closed month and put the same questions to each candidate:
- Does the defined total reconcile to the invoice?
- Are account, service, SKU, Region, and resource available at sufficient detail?
- Can commitments, credits, refunds, tax, and support be classified correctly?
- Does the existing ownership and allocation policy work?
- Can the consumer read the data without provider-specific exceptions?
- Do unknown or uncovered cases remain visible?
Column count is a poor tiebreaker. Choose the export that answers your questions with the least extra logic and without losing anything material.
The choice shows up first in the monthly cloud cost review, which needs one declared cost basis. The AWS integration page lists which AWS billing data Costfluent reads.
Sources and review boundary
Reviewed on 6 September 2026: AWS migration to CUR 2.0, Data Exports table dictionary, FOCUS 1.0 to 1.2 migration, export delivery, and quotas and restrictions. Recheck the table dictionary and conformance notes before fixing a production schema.