Granularity is the resolution of billing data in two dimensions: time (hour, day, month) and object (account, service, SKU, resource, container). It decides which questions an export can answer, how many rows it produces and what storing and querying it costs. It matters for the bill twice over: a level that is too coarse hides which resource or which hour caused a cost, and a level not chosen when the export was set up can rarely be produced for past months afterwards.
How it works
Every row of an export is a sum over an interval (time) down to a key (object). A finer level changes the number of rows, not a month's total, and it adds no dimension the provider does not record, such as the cost of a single process on a VM.
AWS
In AWS Data Exports the time granularity of a CUR 2.0 export is chosen at creation: hourly, daily or monthly, and line items are aggregated to that interval. Table options control the object dimension. Include resource IDs creates a line item per resource, which AWS warns can increase the export significantly. Split cost allocation data adds line items per Amazon ECS task and Amazon EKS pod: two usage records per task or pod per hour (CPU and memory), three for accelerated EKS instances. Two levels need two exports; Data Exports allows five CUR 2.0 exports. For periods before a changed setting, AWS describes only a backfill through a support case, with limits set out in Retention and history of billing data. The export itself is covered in AWS Cost and Usage Report and Data Exports.
Cost Explorer has limits of its own, which the management account extends under Cost Management preferences: multi-year data up to 38 months at monthly granularity only, hourly data and daily resource-level data for the past 14 days only. The hourly level is charged, and a change to the settings takes up to 48 hours to show (AWS Cost Explorer and AWS Budgets).
Azure
Cost Management exports deliver cost details rows per day: the Date field holds the usage or purchase date, and the row carries the resource (ResourceId), the meter and the prices. The Exports API knows only Daily and Monthly as granularity, and Microsoft states that Daily is currently supported for most cases; there is no hourly level for exports. Actual, amortized and FOCUS are separate datasets in separate files (Azure cost exports). For volume, Microsoft gives a rule of thumb: a GB of cost details data is roughly one million rows. Above 2 GB a month it points from the Cost Details API to exports, which split their files into parts under 1 GB uncompressed and list them in a manifest.json.
Google Cloud
On Google Cloud the time granularity is fixed. The standard export into the table gcp_billing_export_v1_XXXXXX_XXXXXX_XXXXXX reports cost in hourly usage windows (usage_start_time, usage_end_time), so long-running usage is spread across several hours. The object dimension follows from the export type. The standard export stops at service, SKU, project and labels and holds no resource data. The detailed export into gcp_billing_export_resource_v1_XXXXXX_XXXXXX_XXXXXX carries every standard field plus resource.name and resource.global_name, but only for the services on Google's list, among them Compute Engine, Cloud Storage, Cloud SQL, BigQuery and GKE, the last only once cost allocation for GKE is enabled. Google notes that resource-level data increases the number of rows and that BigQuery charges separately for storage and queries (Google Cloud billing export).
What it means for your cost
The question sets the level. A cost report for the budget needs month and account, utilisation of a commitment measured per hour, such as AWS Savings Plans, needs hourly values, and rightsizing needs the individual resource.
| Question | Time | Object | Export that delivers it |
|---|---|---|---|
| Budget, invoice, month-end close | month | account, project, subscription | all three |
| Anomaly, trend | day | service, account | all three |
| Commitment utilisation | hour | usage type, resource | AWS CUR 2.0 hourly, Google standard export; Azure exports daily only |
| Rightsizing, orphaned resources | day | resource | AWS with resource IDs, Azure cost details, Google detailed export |
| Cost per team in a cluster | hour | pod, namespace | AWS split cost allocation data, Google detailed export with GKE cost allocation |
Each finer level multiplies the rows: by the hours a resource ran, by the number of resources, by the number of pods. That lands on storage and queries in Amazon Athena or BigQuery, not on the cost of the services used. Allocation through tags and unit economics can only be as fine as the export: a resource without a row of its own cannot be assigned to a team, and pods only reach the report with container data (Kubernetes cost data). Since a missing level is rarely available retroactively, the set-up has to serve the finest question anyone will ask later.
Where it goes wrong
- Daily export, hourly question. Symptom: commitment utilisation can only be shown as a daily average. Cause: the time granularity of CUR 2.0 is chosen at creation and deliveries are aggregated to it; Azure exports have no hourly level.
- No resources in the export. Symptom: the rightsizing list shows only service totals. Cause: on AWS, Include resource IDs was not selected; on Google Cloud only the standard export runs, or the service is not on the list for the detailed export.
- GKE cost only as node cost. Symptom: namespaces are missing from the detailed export. Cause: cost allocation for GKE is not enabled.
- Query cost jumps after a change. Symptom: Athena or BigQuery charges rise after split cost allocation data or the detailed export was switched on. Cause: both add rows per pod and hour or per resource.
- Daily totals differ from the console. Symptom: a day in Google's Cloud Billing report sums to a different figure than the same day in an in-house report. Cause: the report starts the day at midnight Pacific Time, while the in-house report groups the export's timestamps in UTC or Europe/London.
Example
AWS publishes two calculations on this (read on 2026-10-16, US dollars, not tied to a region). For split cost allocation data: with 1,000 pods running each hour across a cluster of ten EC2 instances and a pod lifetime under one hour, (1,000 × 1 × 2) × 24 = 48,000 new usage records are added per day. For Cost Explorer: hourly granularity costs USD 0.00000033 per usage record per day, which AWS states as USD 0.01 per 1,000 records a month. One EC2 instance running all the time yields 336 records (24 hours × 14 days) and about USD 0.003 a month.
Sources
Read on 2026-10-16. AWS Creating a standard export, Understanding split cost allocation data, Quotas and restrictions, Troubleshooting Cost and Usage Reports, Configuring multi-year and granular data, Estimating cost for Cost Explorer hourly granularity; Microsoft Understand usage details fields, Exports - Create Or Update, Cost details best practices, Tutorial - Create and manage Cost Management exports; Google Structure of Standard data export, Structure of Detailed data export, Analyze billing data and cost trends with Reports, BigQuery pricing.