Granularität ist die Auflösung von Abrechnungsdaten in zwei Dimensionen: in der Zeit (Stunde, Tag, Monat) und im Objekt (Konto, Dienst, SKU, Ressource, Container). Sie entscheidet, welche Fragen ein Export beantworten kann, wie viele Zeilen er erzeugt und was Speicherung und Abfragen kosten. Für die Rechnung zählt sie doppelt: Eine zu grobe Stufe verbirgt, welche Ressource oder welche Stunde die Kosten verursacht hat, und eine beim Einrichten nicht gewählte Stufe lässt sich für vergangene Monate in der Regel nicht mehr herstellen.
So funktioniert es
Jede Zeile eines Exports ist eine Summe über ein Intervall (Zeit) bis zu einem Schlüssel (Objekt). Eine feinere Stufe ändert die Zahl der Zeilen, nicht die Summe eines Monats, und sie fügt keine Dimension hinzu, die der Anbieter nicht erfasst, etwa die Kosten eines einzelnen Prozesses auf einer VM.
AWS
In AWS Data Exports wird die Zeitgranularität für CUR 2.0 beim Anlegen gewählt: stündlich, täglich oder monatlich. Die Positionen werden auf dieses Intervall aggregiert. Die Objektdimension steuern Tabellenoptionen. Include resource IDs erzeugt eine eigene Position je Ressource, was den Export nach Angabe von AWS deutlich vergrößern kann. Split cost allocation data fügt für Amazon ECS und Amazon EKS Positionen je Task und Pod hinzu, und zwar zwei Nutzungsdatensätze je Task oder Pod und Stunde (CPU und Arbeitsspeicher), bei beschleunigten EKS-Instanzen drei. Wer zwei Stufen braucht, legt zwei Exporte an; Data Exports erlaubt fünf CUR-2.0-Exporte. Für Zeiträume vor einer geänderten Einstellung beschreibt AWS nur eine Nachlieferung über einen Support-Fall, mit Grenzen, die Aufbewahrung und Historie der Abrechnungsdaten nennt. Den Export selbst beschreibt AWS Cost and Usage Report und Data Exports.
Cost Explorer hat eigene Grenzen, die das Verwaltungskonto in den Cost Management Preferences erweitert: mehrjährige Daten bis 38 Monate nur in monatlicher Granularität, stündliche Daten und tägliche Daten auf Ressourcenebene nur für die letzten 14 Tage. Die stündliche Stufe ist kostenpflichtig, und eine Änderung der Einstellungen wird erst nach bis zu 48 Stunden sichtbar (AWS Cost Explorer und AWS Budgets).
Azure
Die Exporte von Cost Management liefern Cost-Details-Zeilen je Tag: Das Feld Date trägt das Nutzungs- oder Kaufdatum, die Zeile trägt Ressource (ResourceId), Meter und Preise. Die Exports-API kennt als Granularität nur Daily und Monthly, und Microsoft schreibt, dass derzeit in den meisten Fällen Daily unterstützt wird; eine stündliche Stufe gibt es für Exporte nicht. Actual, Amortized und FOCUS sind getrennte Datensätze in eigenen Dateien (Azure-Kostenexporte). Für das Volumen nennt Microsoft eine Faustregel: Ein GB Cost-Details-Daten entspricht etwa einer Million Zeilen. Ab 2 GB im Monat verweist Microsoft von der Cost Details API auf Exporte, die ihre Dateien in Teile unter 1 GB (unkomprimiert) zerlegen und in einer manifest.json auflisten.
Google Cloud
Bei Google ist die Zeitgranularität fest. Der Standard-Export in die Tabelle gcp_billing_export_v1_XXXXXX_XXXXXX_XXXXXX weist Kosten in stündlichen Nutzungsfenstern aus (usage_start_time, usage_end_time); lang laufende Nutzung verteilt sich auf mehrere Stunden. Die Objektdimension folgt aus dem Exporttyp. Der Standard-Export endet bei Dienst, SKU, Projekt und Labels und enthält keine Ressourcendaten. Der Detailed-Export in gcp_billing_export_resource_v1_XXXXXX_XXXXXX_XXXXXX enthält alle Felder des Standard-Exports plus resource.name und resource.global_name, allerdings nur für die Dienste auf Googles Liste, darunter Compute Engine, Cloud Storage, Cloud SQL, BigQuery und GKE, Letzteres nur mit aktivierter Kostenzuordnung für GKE. Google weist darauf hin, dass die Ressourcenebene die Zahl der Zeilen erhöht und BigQuery Speicher und Abfragen gesondert berechnet (Google-Cloud-Abrechnungsexport nach BigQuery).
Was es für Ihre Kosten bedeutet
Die Frage bestimmt die Stufe. Ein Kostenbericht für das Budget braucht Monat und Konto, die Auslastung eines stündlich bemessenen Commitments wie AWS Savings Plans braucht Stundenwerte, und Rightsizing braucht die einzelne Ressource.
| Frage | Zeit | Objekt | Export, der es liefert |
|---|---|---|---|
| Budget, Rechnung, Monatsabschluss | Monat | Konto, Projekt, Abonnement | alle drei |
| Anomalie, Trend | Tag | Dienst, Konto | alle drei |
| Commitment-Auslastung | Stunde | Nutzungsart, Ressource | AWS CUR 2.0 stündlich, Google Standard-Export; Azure-Exporte nur täglich |
| Rightsizing, verwaiste Ressourcen | Tag | Ressource | AWS mit Resource IDs, Azure Cost Details, Google Detailed-Export |
| Kosten je Team im Cluster | Stunde | Pod, Namespace | AWS Split cost allocation data, Google Detailed-Export mit GKE-Kostenzuordnung |
Jede feinere Stufe vervielfacht die Zeilen: mit den Stunden, in denen eine Ressource lief, mit der Zahl der Ressourcen, mit der Zahl der Pods. Das trifft Speicher und Abfragen in Amazon Athena oder BigQuery, nicht die Kosten der genutzten Dienste. Die Zuordnung über Tags und Unit Economics kann nur so fein sein wie der Export: Eine Ressource ohne eigene Zeile lässt sich keinem Team zuordnen, und Pods kommen erst mit Containerdaten in den Bericht (Kubernetes-Kostendaten). Weil eine fehlende Stufe rückwirkend selten zu haben ist, muss die Einrichtung die feinste Frage tragen, die später gestellt wird.
Wo es schiefgeht
- Täglicher Export, stündliche Frage. Symptom: Die Auslastung eines Commitments lässt sich nur als Tagesmittel zeigen. Ursache: Die Zeitgranularität von CUR 2.0 wird beim Anlegen gewählt und die Lieferung darauf aggregiert; Azure-Exporte kennen keine Stundenstufe.
- Keine Ressourcen im Export. Symptom: Die Rightsizing-Liste zeigt nur Dienstsummen. Ursache: Bei AWS fehlte Include resource IDs, bei Google läuft nur der Standard-Export, oder der Dienst steht nicht auf der Liste für den Detailed-Export.
- GKE-Kosten nur als Knotenkosten. Symptom: Namespaces fehlen im Detailed-Export. Ursache: Die Kostenzuordnung für GKE ist nicht aktiviert.
- Abfragekosten springen nach einer Umstellung. Symptom: Athena- oder BigQuery-Kosten steigen, nachdem Split cost allocation data oder der Detailed-Export aktiviert wurde. Ursache: Beide fügen Zeilen je Pod und Stunde oder je Ressource hinzu.
- Tagessummen weichen von der Konsole ab. Symptom: Ein Tag im Cloud-Billing-Bericht von Google ergibt eine andere Summe als derselbe Tag im eigenen Bericht. Ursache: Der Bericht beginnt den Tag um Mitternacht pazifischer Zeit, der eigene Bericht gruppiert die Zeitstempel des Exports in UTC oder Europe/Berlin.
Beispiel
AWS veröffentlicht zwei Rechnungen dazu (gelesen am 2026-10-16, US-Dollar, ohne Regionsbezug). Für Split cost allocation data: Laufen in einem Cluster aus zehn EC2-Instanzen stündlich 1.000 Pods mit einer Lebensdauer unter einer Stunde, entstehen (1.000 × 1 × 2) × 24 = 48.000 neue Nutzungsdatensätze am Tag. Für Cost Explorer: Stündliche Granularität kostet 0,00000033 USD je Nutzungsdatensatz und Tag, nach Angabe von AWS 0,01 USD je 1.000 Datensätze im Monat. Eine EC2-Instanz, die durchgehend läuft, ergibt 336 Datensätze (24 Stunden × 14 Tage) und rund 0,003 USD im Monat.
Quellen
Gelesen am 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.