Finance wants hourly cost per team tag, broken down by usage type, for the last twelve months — more detail than the Billing console will show. Explain what the AWS Cost and Usage Report gives you that the console does not, and how you would query it.

## What the CUR actually is Every other cost view in AWS is a rendering of the same underlying billing records. The **Cost and Usage Report** hands you those records. You configure it once in the Billing and Cost Management console: a report name, an S3 bucket you own (with a bucket policy allowing the billing service to write), a time granularity of hourly, daily or monthly, and options for including resource IDs and split cost allocation data. AWS then delivers compressed files — CSV or Parquet — plus a manifest per billing period, and refreshes them several times a day while the month is open. ## The row model One row is one **line item**: a charge for one usage type, in one operation, in one hour, for one account. That means a single EC2 instance running for a day produces many rows, and one instance-hour can produce several rows of different `lineItem/LineItemType` — usage, the discount line if a commitment covered it, taxes, credits, fees. Anyone summing a cost column without understanding line item types will produce a number that does not match the invoice, which is the classic first mistake. Columns are namespaced by prefix: - `bill/` — billing period, payer account, invoice id - `lineItem/` — account, usage start and end, usage type, operation, usage amount, cost, and the line item type - `product/` — attributes of what was used: region, instance type, and so on - `pricing/` — the rate and its unit - `resourceTags/` — **one column per activated cost allocation tag**, which is the whole reason this leaf cares about the CUR That last point is the connection back to tagging: an activated tag becomes a first-class column in the raw data, so allocation stops being a console filter and becomes SQL you control. ## Querying it with Athena Athena reads directly from S3, so there is no load step. AWS provides a crawler and a CloudFormation-based integration that creates the Glue table and keeps partitions current; in the Athena table, CUR's slashed column names are flattened to underscores. ```sql SELECT resource_tags_user_cost_center AS cost_center, line_item_usage_type, sum(line_item_unblended_cost) AS cost FROM cur_db.my_report WHERE bill_billing_period_start_date = TIMESTAMP '2025-07-01 00:00:00' GROUP BY 1, 2 ORDER BY cost DESC; ``` The things that make this survive contact with production: **Partition, always.** Filter on the billing period partition in every query. Athena charges by bytes scanned, and an unpartitioned twelve-month hourly report with resource IDs is exactly the kind of table where a careless `SELECT *` becomes a line item of its own. **Prefer Parquet.** Columnar storage plus the fact that most cost queries touch a handful of the report's very many columns is a large reduction in scanned bytes. **Handle re-delivery.** During an open month AWS overwrites the period's data as the estimate is refined, and the report is finalised after the month closes. A pipeline that appends rather than replaces will double-count. Report versioning options control whether new deliveries overwrite the existing files or create a new version, and your ingestion must match whichever you chose. **Only the payer gets the whole picture.** The management account's report covers the organization; a member account can enable its own report covering only itself. **Tags are only there if they were activated.** A tag activated last week does not retroactively populate a column for last quarter, so the twelve-month request in the question may simply be unanswerable for the earlier months — say so rather than producing a report full of nulls without comment. ## Newer delivery paths AWS Data Exports is the current mechanism for creating these exports; alongside the legacy CUR it offers CUR 2.0 with a flattened schema and column selection, and a FOCUS-format export for organizations standardising cost data across more than one cloud. Same S3-and-query pattern, less schema to carry. ## When *not* to reach for it If the question is "what did we spend last month by service", the console answers it in seconds and building a data pipeline is waste. The CUR earns its keep when you need resource-level or hourly detail, joins to data AWS does not have (your CMDB, your team roster, per-tenant usage), or an allocation model whose logic is more complicated than the console's grouping options can express.