AWS Cost and Usage Reports (CUR)

Cost and Usage Reports are the most comprehensive cost and usage data AWS produces. Where Cost Explorer gives you a view, CUR gives you the underlying line items — one per unique combination of product, usage type and operation — for you to query yourself.

• Reports are published to an S3 bucket you own.
• Costs break down by hour, day or month; by service and by resource; and by any tag you have activated for cost allocation.
• AWS updates the report in the bucket at least once a day, and up to three times a day. Each update in a month is cumulative, so the latest file always holds the whole month to date.
• Files are delivered compressed (.zip or .gzip CSV) or as Parquet — the format to choose if the data is going anywhere near Athena.
• Reports integrate with Amazon Athena for querying, Amazon Redshift for warehousing, and Amazon QuickSight for visualisation.

A month’s report for a large estate is routinely more than a gigabyte and well past a million rows, so it is split across several files. Treat it as data, not as a spreadsheet.

Create new exports as CUR 2.0 through AWS Data Exports

AWS Data Exports is the current path for creating cost exports, and CUR 2.0 is the export type to choose. Compared with legacy CUR it has:

• a fixed schema, where legacy CUR’s columns vary month to month depending on which services, cost categories and tags you happened to use — the single biggest source of broken downstream pipelines;
• nested columns with key-value pairs for resource_tags, cost_category, product and discount, instead of one sparse column per tag key;
• extra columns legacy CUR does not have, including bill_payer_account_name, line_item_usage_account_name, line_item_iam_principal and line_item_user_identifier;
• SQL at export time for column selection, filtering and aliasing, so you can produce a narrower table rather than exporting everything and trimming it later.

CUR 2.0 exports can be made backwards compatible with an existing legacy-CUR pipeline, so migrating does not require rewriting downstream queries on day one.

What it is used for

1. Splitting an organization’s bill by OU or by individual member account.
2. Tracking Savings Plans utilisation, charges and how the discount was allocated across accounts.
3. Monitoring on-demand capacity reservations.
4. Breaking down data transfer charges, which are otherwise almost impossible to attribute — internet egress and inter-Region transfer both appear as line items with the resource that caused them.
5. Cost allocation by tag, for example by environment or owning team. This only works for tags that have been activated as cost allocation tags in the Billing console, and only from the point of activation onwards — it does not backfill. See tagging and resource groups.