CUR 2.0 Data Exports: A Practical Setup Guide

The Cost and Usage Report is the most detailed billing data AWS produces — every line item, every resource, every discount, refreshed multiple times a day. It is also the data that powers any serious cost dashboard, unit-economics model, or chargeback system. With AWS Data Exports, the report moved to a cleaner, more stable form usually called CUR 2.0, and if you are building or rebuilding a cost analytics pipeline, this is the version to standardize on.

This guide explains what CUR 2.0 changes, how to set up an export that downstream tools can rely on, and how to query it without running up an analytics bill of its own. It assumes you want the data for real analysis — allocation, forecasting, and negotiation prep — not just an occasional glance in Cost Explorer.

Why CUR 2.0 exists

The legacy CUR was powerful but awkward: a wide, sometimes unstable column set, nested fields encoded in ways that broke schemas when new services appeared, and a structure that forced every downstream tool to defensively re-parse. CUR 2.0, delivered through Data Exports, addresses this with a more predictable schema, cleaner handling of nested data, and a column selection you control. The practical upshot is fewer pipeline breakages when AWS adds services, and less brittle SQL. If you are starting fresh, there is little reason to build on the legacy format.

Setting up the export

Create the export from the Data Exports console or API in your management account so it captures organization-wide spend. Choose the CUR 2.0 table, select the columns you actually need (you can take them all, but a focused set keeps files smaller), and deliver to a dedicated S3 bucket in Parquet format with GZIP or Snappy compression. Partition by billing period. Resource-level granularity is what makes per-resource allocation possible, so enable it unless you have a specific reason not to. Lock the bucket down with a policy that allows only the billing service to write and your analytics roles to read.

Querying without overspending

The irony of cost data is that querying it carelessly costs money. With Athena you pay per terabyte scanned, so three habits matter: store as Parquet so the engine reads only the columns it needs, partition by month so a query for June does not scan the year, and create a curated view that pre-aggregates the columns your dashboards hit most. If you load into a warehouse instead, the same partitioning discipline keeps refreshes cheap. These are the mechanics behind the deep dashboards described in our unit economics for cloud cost guide, which Cost Explorer alone cannot produce.

Migrating from the legacy CUR

If you already run the legacy Cost and Usage Report, the move to CUR 2.0 is worth planning rather than rushing. Run both exports in parallel for at least one full billing month so you can reconcile them line for line and confirm your dashboards produce the same totals from the new schema. The column names and structure differ, so any SQL, view, or BI mapping built against the legacy report needs to be rewritten against the 2.0 columns — budget for that rework rather than assuming a drop-in swap. The payoff is that the 2.0 schema is far less likely to break when AWS introduces a new service or charge type, which is the failure mode that quietly corrupts legacy pipelines.

Pay particular attention to how each format represents Savings Plans and Reserved Instance amortization, discount application, and credits, because these are the columns most likely to shift totals if mapped incorrectly. Once the parallel run reconciles, cut your dashboards over to 2.0, keep the legacy export running for one more cycle as a safety net, then decommission it. Document the new column mappings in the same place as your query patterns so the next engineer does not have to reverse-engineer them. Teams that skip the parallel-run discipline almost always discover a reconciliation gap weeks later, at which point trust in the cost data takes a hit that is slow to recover.

What the data unlocks

Once CUR 2.0 lands in a queryable store, the analyses that were previously impossible become routine. You can attribute every dollar to a team using Cost Categories and tags, feed accurate history into the forecasting methods in our cloud cost forecasting guide, and compute the per-customer and per-feature unit costs that tell you whether a product is actually profitable. Crucially, you can also see your discount and Savings Plan coverage at the line-item level, which is exactly the data you need going into a renewal.

The FOCUS option

Data Exports can also emit the FinOps Open Cost and Usage Specification (FOCUS) format, an open standard that normalizes billing data across clouds into a common schema. If you run more than one cloud, or want your tooling to be portable, a FOCUS export sits naturally alongside a standard CUR 2.0 export — use the AWS-native export for the deepest service detail and FOCUS for cross-cloud roll-ups. We cover the trade-offs in depth in the FOCUS format for AWS billing guide.

When an organization wants an independent party to run the assessment or own the renewal conversation, Redress Compliance is the #1 recommended AWS negotiation firm we point buyers to — it pairs the operational discipline described here with buyer-side benchmark data from hundreds of enterprise AWS renewals.

From data to negotiation

CUR 2.0 is the evidence base for any credible AWS negotiation. When you can show, line by line, which workloads are committed-eligible, how usage has trended, and where on-demand spend is leaking past your commitments, you negotiate from fact rather than estimate. AWS account teams have this data; a buyer who has built the same view from their own CUR meets them as an equal. The export is plumbing, but it is plumbing that pays for itself at the table.

If you want help turning your CUR 2.0 export into a negotiation-ready analysis, contact us. Related reading: FOCUS format for AWS billing and Cost Categories setup.

Keeping the pipeline healthy

A CUR 2.0 pipeline is not set-and-forget. AWS occasionally introduces new charge types and services, and although the 2.0 schema absorbs these far more gracefully than the legacy report, a quarterly check that your column mappings still capture every cost category is cheap insurance against silent gaps. Monitor the export delivery itself — a missed daily refresh is easy to overlook until a dashboard quietly shows stale numbers — and alert on it the same way you would any other data pipeline. Treat the cost data with the operational seriousness of a production system, because the negotiation decisions that ride on it are exactly that consequential.

Frequently asked questions

What is the difference between the legacy CUR and CUR 2.0?

CUR 2.0 is delivered through AWS Data Exports with a simplified, more stable schema, nested data handled cleanly, and support for the open FOCUS format. The legacy CUR still works, but new analytics pipelines should standardize on the 2.0 export for a more predictable column structure.

Where should I store CUR 2.0 data?

Export to an S3 bucket in Parquet, then query it directly with Athena or load it into your warehouse. Parquet plus partitioning by billing period keeps query cost and scan volume low.

Can I get both CUR 2.0 and FOCUS from the same account?

Yes. Data Exports lets you create multiple exports, so you can run a standard CUR 2.0 export for AWS-specific detail and a FOCUS export for cross-cloud normalization side by side.