This chapter assumes you already know that CUR is “a detailed CSV of your AWS bill.” We go straight into the concepts that matter once you’re building real cost analytics on top of it: the legacy CUR versus the newer Data Exports model, line item types, and the granularity settings that decide whether your report is actually useful.

Legacy CUR vs. AWS Data Exports (CUR 2.0)

The original Cost and Usage Report delivers a single, wide, denormalized CSV or Parquet file per billing period to an S3 bucket you own. AWS Data Exports, the modern successor commonly referred to as CUR 2.0, reframes the same underlying billing data as a queryable, versioned table with a defined schema, supporting more flexible column selection, native Parquet output, and better integration with query engines out of the box — while remaining built on the exact same underlying billing line-item data as legacy CUR.

Line Item Types — The Core of the Schema

Every row in CUR carries a line_item_type that fundamentally changes how that row should be interpreted: Usage rows represent actual on-demand or metered consumption; DiscountedUsage rows represent usage covered by a Reserved Instance or Savings Plan commitment; Fee rows represent the upfront or recurring fee for that commitment itself; Refund and Credit rows adjust the bill downward; and Tax rows capture applicable tax line items separately from the underlying usage.

Resource-Level Granularity

CUR can be configured with resource IDs enabled, which adds the specific resource identifier (an EC2 instance ID, an S3 bucket name, a Lambda function ARN) to every applicable row. Without this setting, cost data is aggregated at the service/usage-type level with no way to trace a specific dollar amount back to a specific running resource — a setting every serious cost-allocation initiative must enable from day one, since it cannot be retroactively applied to historical data already generated without it.

Here we open the hood on what actually happens between AWS metering a resource’s usage and that usage appearing as a queryable row in your CUR files.

From Metering to Line Item

Every AWS service independently meters its own usage internally (an EC2 instance-hour, a Lambda invocation and its duration, an S3 GET request) and reports that raw usage into AWS’s central billing pipeline. The billing pipeline applies the account’s pricing — on-demand rates, any applicable Reserved Instance or Savings Plan discount, negotiated Enterprise Discount Program rates if present — and produces the fully-priced line items that eventually populate CUR. This is why CUR reflects billed cost, not raw usage volume; the same underlying usage can appear at wildly different unblended_cost values depending on which pricing commitment happened to apply that hour.

graph TB
    subgraph "AWS Service Layer"
        EC2[EC2 Usage Metering]
        S3M[S3 Usage Metering]
        LAM[Lambda Usage Metering]
    end
    EC2 --> PIPE[Central Billing Pipeline]
    S3M --> PIPE
    LAM --> PIPE
    PIPE --> PRICE[Apply Pricing: On-Demand / RI / Savings Plan / EDP]
    PRICE --> LINEITEM[Generate Priced Line Items]
    LINEITEM --> CUR[CUR File Generation]
    CUR --> S3OUT[(Delivered to S3 Bucket)]
        

Amortization: The Detail That Trips Up Every New Cost Analyst

When you buy a one-year Reserved Instance with an upfront payment, the raw billing data treats that upfront payment as one giant cost hitting on the day of purchase, with $0 attributed to the hours it actually covers afterward — clearly useless for month-over-month cost trending. CUR’s amortized cost columns solve this by spreading that upfront fee evenly across every hour of the commitment’s term, so a monthly cost report shows a smooth, representative cost each month rather than one enormous spike on purchase day followed by artificially cheap months afterward.

Unblended vs. Blended Cost in Consolidated Billing

unblended_cost reflects the actual rate charged for that specific account’s usage in that specific hour. blended_cost, relevant only in AWS Organizations consolidated billing, averages the effective rate for a given usage type across all linked accounts sharing a Reserved Instance or Savings Plan — meaning two accounts running identical usage can show different blended costs depending on what the rest of the organization is doing, which is precisely why most cost engineering work defaults to unblended cost for per-account accuracy.

The Full Lifecycle of a Report Period

Why the Manifest File Is Not Optional Reading

Every report refresh is accompanied by a manifest JSON file listing the exact set of data files that constitute the current, authoritative version of that period’s report. Any pipeline that ingests CUR data by simply globbing “all files in this month’s folder” without consulting the manifest risks double-counting or mixing stale files from a previous version with new ones — the manifest is the single source of truth for “which files actually belong together right now.”

The Trade-off That Matters Most: Granularity vs. Query Cost

Enabling every optional CUR column and resource-level detail maximizes analytical power but also maximizes file size and, downstream, the cost of scanning that data with a query engine like Athena. Advanced teams partition and format the data deliberately (Parquet over CSV, partitioned by billing period) specifically to keep this granularity affordable to query repeatedly rather than treating it as a one-time export.

Format Choice Is the Single Biggest Performance Lever

Storing CUR as gzip-compressed CSV is the legacy default but is dramatically slower and more expensive to query than Parquet — a columnar format that lets a query engine like Athena read only the specific columns a query actually needs, instead of decompressing and scanning every column of every row. For any organization running CUR queries regularly rather than as a one-off export, switching to Parquet is close to a mandatory first optimization.

Partitioning by Billing Period

CUR data delivered with proper partitioning (by year and month, and ideally further by day for very large organizations) allows a query engine to skip scanning entire partitions that aren’t relevant to a given query’s date range — the difference between an Athena query that scans a single month’s data versus one that scans every month of history ever generated, which directly translates into both query cost and query latency.

Query Engineering: Selecting Only What You Need

Because CUR schemas are extremely wide, queries that explicitly select only the columns needed for a given analysis (rather than SELECT *) meaningfully reduce both scan cost and result size on a columnar format — a habit worth enforcing across any team building recurring cost reports on top of CUR data.

Reliability Here Means Data Integrity, Not Uptime

CUR is not a running service with an availability SLA in the traditional sense — it’s a periodic data delivery pipeline. The reliability concern that actually matters is whether your downstream consumption (Athena tables, dashboards, cost allocation reports) correctly handles report refreshes, versioning, and the eventual finalization of a billing period without silently working from stale or partial data.

Protecting the Destination S3 Bucket

Because CUR is the authoritative record used for cost allocation, chargeback, and potentially audit purposes, the destination S3 bucket warrants the same protective controls as any critical data store: versioning enabled, lifecycle policies that don’t prematurely delete historical report versions, and bucket policies that prevent accidental deletion or unauthorized modification of delivered report files.

Handling Retroactive Corrections Gracefully

Because AWS can retroactively adjust even “finalized” historical billing periods (credits, corrections), a robust cost pipeline periodically re-checks the manifest of past periods rather than assuming a month’s data, once ingested, is permanently frozen — otherwise a legitimate credit applied months later silently never reaches downstream reports.

CUR Data Is Sensitive Business Information

A CUR export reveals detailed operational information — which services are used, at what scale, and by implication, aspects of an organization’s architecture and growth trajectory — alongside the financial data itself. Treating the destination S3 bucket with the same access rigor as financial records, rather than as generic operational log data, is the correct default posture.

Bucket Policy and Encryption

The CUR destination bucket should enforce server-side encryption (SSE-S3 or SSE-KMS), block public access unconditionally, and restrict write access to the AWS billing service principal alone — read access should be scoped narrowly to the specific roles and services (Athena, Glue, a BI tool’s execution role) that genuinely need to query the data, not broadly opened to convenience.

Cross-Account Access in Multi-Account Organizations

In an AWS Organizations setup, CUR is typically generated once at the management/payer account level covering all linked accounts, then made queryable by individual account or team owners through carefully scoped cross-account IAM roles or Lake Formation permissions — rather than granting every team direct access to the full organization-wide billing dataset, which would expose other teams’ cost data unnecessarily.

Because CUR itself has no native alerting layer, most of this monitoring is built by the consuming pipeline — S3 event notifications on new manifest delivery, scheduled data-quality checks on row counts and null rates, and dashboards tracking untagged spend percentage over time as a first-class FinOps KPI.

Reconciling CUR Numbers Against the Billing Console

When CUR-derived totals don’t match the Billing Console for the current month, the first check is always whether the CUR data being queried reflects the latest manifest version — current-month figures in both places are provisional and can differ simply due to refresh timing, not a data error in either system.

The Standard Reference Architecture

A mature CUR deployment typically flows: CUR delivered as partitioned Parquet to a dedicated S3 bucket, a Glue crawler (or manually defined Glue table) maintaining up-to-date partition metadata as new periods land, Athena as the query engine for ad hoc and scheduled analysis, and a BI layer (commonly QuickSight, or a purpose-built internal dashboard) presenting curated views to different audiences — engineering leads seeing their own team’s cost breakdown, finance seeing organization-wide trends.

graph LR
    BILLING[AWS Billing Pipeline] -->|CUR Files + Manifest| S3B[(S3 Bucket - Parquet, Partitioned)]
    S3B --> GLUE[Glue Crawler / Catalog]
    GLUE --> ATHENA[Athena Query Engine]
    ATHENA --> QS[QuickSight Dashboards]
    ATHENA --> CUSTOM[Custom FinOps Tooling]
        

Managing CUR Configuration as Code

The report definition itself — column selection, format, refresh settings, destination bucket — is defined as infrastructure (CloudFormation or Terraform) so it can be reviewed, versioned, and reliably reproduced if the organization needs to stand up an equivalent pipeline in a disaster-recovery or new-organization scenario.

CUDOS and Pre-Built Dashboard Frameworks

Rather than building cost dashboards entirely from scratch, many organizations start from AWS’s own published reference dashboard frameworks (commonly known by the acronym CUDOS) built specifically on top of CUR data, then customize from that baseline rather than reinventing common cost-visibility views like top spenders, commitment utilization, and untagged resource tracking.

Pattern: Cost Allocation Tags Joined Against Resource IDs

Combining resource-level CUR data with a well-enforced cost allocation tagging strategy (team, environment, project) turns raw billing rows into genuine chargeback and showback reports — the tags supply the “who owns this,” and CUR supplies the “how much did it actually cost.”

Pattern: Cost Categories for Non-Tag-Based Grouping

AWS Cost Categories let you define grouping rules based on account, service, or other billing dimensions independent of tags — useful for organizations where consistent tagging discipline isn’t fully achievable, letting a “which business unit” view be constructed from account structure or usage patterns instead of relying solely on tag compliance.

Pattern: Anomaly Detection Layered on Top of CUR Trends

Combining CUR historical data with AWS Cost Anomaly Detection (or a custom statistical model built on the same underlying data) catches unexpected spend spikes — a misconfigured auto-scaling group, an accidentally-public data transfer pattern — far earlier than a monthly manual review would.