AWS Data Exports bietet 2026 zwei ernsthafte Optionen: den Cost and Usage Report 2.0 und FOCUS 1.2 mit zusätzlichen AWS-Spalten. Welcher Export besser ist, hängt vor allem davon ab, wer die Daten liest. CUR 2.0 ist die detaillierte, AWS-nahe Quelle. FOCUS 1.2 liefert eine standardisierte Kosten- und Nutzungssemantik, die sich über mehrere Anbieter hinweg auswerten lässt.
Entscheidend ist, welche Entscheidungen die Daten tragen sollen und welche Felder dafür nötig sind. Braucht Finance eine gemeinsame Sicht über alle Anbieter, während Engineering AWS-spezifische Discounts oder Produktattribute untersucht, sind zwei sauber geführte Exporte oft besser als einer, der beides leisten soll.
Die kurze Entscheidung
| Bedarf | Bevorzugter Startpunkt | Grund |
|---|---|---|
| Bestehende CUR-Pipeline migrieren | CUR 2.0 | AWS dokumentiert einen kompatiblen Migrationspfad und eine AWS-nahe Struktur |
| AWS-spezifische Kostenanalyse | CUR 2.0 | Breitere AWS-Felder, verschachtelte Produkt-, Discount-, Tag- und Cost-Category-Daten |
| Gemeinsames Modell für mehrere Provider | FOCUS 1.2 | Standardisierte Begriffe und Spalten über Anbietergrenzen |
| Rechnungsabstimmung in einer FOCUS-Pipeline | FOCUS 1.2 | Enthält unter anderem InvoiceID und InvoiceIssuerId |
| Capacity-Reservation-Analyse im Standardmodell | FOCUS 1.2 | Eigene Felder für ID und Status der Capacity Reservation |
| Tiefe AWS-Analyse und providerübergreifendes Reporting | Beide | Getrennte Consumer rechtfertigen getrennte, abgestimmte Datenprodukte |
Einen neuen Export würden wir heute nicht mehr auf FOCUS 1.0 aufsetzen. AWS unterstützt inzwischen FOCUS 1.2 mit AWS-Spalten und dokumentiert Breaking Changes gegenüber 1.0.
Was CUR 2.0 auszeichnet
CUR 2.0 hat gegenüber Legacy CUR ein festes Schema. Mehrere vormals dynamische Spaltengruppen liegen als verschachtelte Key-Value-Felder vor, darunter Resource Tags, Cost Categories, Product und Discount. Data Exports erlaubt außerdem eine eingeschränkte SQL-Auswahl, Filterung und Alias-Vergabe.
CUR 2.0 passt, wenn:
- bestehende AWS-Abfragen und Datenprodukte migriert werden;
- AWS-spezifische Produkt- oder Discount-Details benötigt werden;
- einzelne Spalten und Zeilen bereits im Export begrenzt werden sollen;
- AWS-Engineering und FinOps die Hauptverbraucher sind.
Auch ein festes Schema bleibt nicht stehen. Werte, verschachtelte Keys und Exporteinstellungen können Downstream-Logik brechen. Versionieren Sie Ihre Schemaannahmen und testen Sie mit echten Zeilen für jeden Charge Type, der für Sie zählt.
Was FOCUS 1.2 auszeichnet
FOCUS liefert gemeinsame Definitionen für Felder wie Billed Cost, Effective Cost, Service, SKU, Charge Category und Commitment Discount. AWS ergänzt den Standardexport um wenige AWS-spezifische Spalten.
AWS nennt für FOCUS 1.2 gegenüber 1.0 unter anderem:
- InvoiceID für die Rechnungszuordnung;
- Felder für Capacity Reservation ID und Status;
- zusätzliche Pricing-Currency-Felder;
- neue Service- und SKU-Details;
- geänderte Zeilenbildung und Werte bei einzelnen Commitment-Fällen;
- konfigurierbare stündliche, tägliche oder monatliche Granularität.
FOCUS passt, wenn eine gemeinsame Downstream-Logik AWS, Azure oder weitere unterstützte Quellen lesen soll. Der Standard spart Übersetzungsarbeit, die Unterschiede zwischen Anbietern bleiben trotzdem: Nullwerte, Conformance Gaps und die zusätzlichen AWS-Spalten wollen bewusst behandelt werden.
Nicht vom Spaltennamen zur Geschäftslogik springen
Dass zwei Anbieter denselben Spaltennamen verwenden, heißt nicht, dass er im eigenen Unternehmen dasselbe bedeutet. Legen Sie diese Regeln fest, bevor jemand eine Pipeline baut:
| Geschäftsbegriff | Festzulegende Regel |
|---|---|
| Monatskosten | Billed, Actual, Amortized oder Effective Cost? |
| Verbrauchsowner | Account, Tag, Cost Category oder eigene Regel? |
| Commitment-Kauf | In welchem Report und Zeitraum erscheint er? |
| Nicht genutztes Commitment | Welcher Owner trägt den Rest? |
| Credit und Refund | Wird die Wirkung dem Ursprungsmonat oder Buchungsmonat zugeordnet? |
| Rechnung | Welche IDs und Summen gelten als Abstimmungsbasis? |
| Währung | Billing-, Pricing- oder Reportingwährung? |
Diese Regeln gehören in Mappings und Tests, nicht nur ins Dashboard. Stehen sie nur dort, verschiebt ein Exportwechsel still und leise eine Kennzahl, auf die sich das Management verlässt.
Wann beide Exporte gerechtfertigt sind
AWS erlaubt mehrere Exporte pro Tabelle. Daraus folgt nicht, dass man sie braucht. Eine zweite Datenquelle lohnt sich nur, wenn sie einen anderen Abnehmer mit stabilem Bedarf bedient.
Ein Muster, das funktioniert:
- FOCUS 1.2 speist das normalisierte providerübergreifende Reporting.
- CUR 2.0 speist AWS-spezifische Untersuchungen, die der Standardexport nicht abdeckt.
- Beide werden pro Abrechnungszeitraum gegen dieselbe AWS-Rechnung abgestimmt.
- Ein dokumentierter Schlüssel verbindet Payer, Billing Period und relevante Charge-Population.
- Keine Kennzahl summiert beide Exporte zusammen.
Bauen Sie keine fast identische zweite Pipeline auf Vorrat. Deckt FOCUS alle heutigen Entscheidungen ab, ist ein zusätzlicher CUR-2.0-Feed nur etwas, das betrieben und überwacht werden muss.
Lieferung und Korrekturen richtig verarbeiten
AWS liefert zu Data Exports Datenfiles plus Manifest.json. CUR 2.0 wird mindestens täglich aktualisiert; AWS kann den vorherigen Abrechnungszeitraum nach Periodenende erneut aktualisieren. Exporte können frühere Files überschreiben oder jede Ausführung separat ablegen.
Eine Pipeline, die das aushält, tut sechs Dinge:
- Immer das Manifest statt eines Dateiglobs als Lieferumfang verwenden.
- Exportausführung und Billing Period idempotent verarbeiten.
- Korrekturen eines bereits geladenen Zeitraums als neue Version akzeptieren.
- Leere Chunks im Overwrite-Modus nicht als Nullkostenzeitraum interpretieren.
- Source Total, geladene Zeilen und transformiertes Total abstimmen.
- Schema- und Nullwertänderungen vor dem Update der Managementsicht blockieren.
Ein kurzer Auswahltest
Nehmen Sie einen repräsentativen, abgeschlossenen Monat und stellen Sie jedem Kandidaten dieselben Fragen:
- Lässt sich die Rechnung auf die definierte Summe abstimmen?
- Sind Account, Service, SKU, Region und Ressource ausreichend verfügbar?
- Lassen sich Commitments, Credits, Refunds, Tax und Support korrekt einordnen?
- Funktioniert die bestehende Ownership- und Allokationslogik?
- Kann der Consumer die Daten ohne providerbezogene Sonderregel lesen?
- Bleiben unbekannte oder nicht abgedeckte Fälle sichtbar?
Die Spaltenzahl taugt nicht als Kriterium. Nehmen Sie den Export, der Ihre Fragen mit der wenigsten Zusatzlogik beantwortet, ohne dass Wesentliches verloren geht.
Die Wahl zeigt sich zuerst im monatlichen Cloud-Kostenreview, das eine festgelegte Kostenbasis braucht. Welche AWS-Abrechnungsdaten Costfluent liest, steht auf der AWS-Integrationsseite.
Quellen und Prüfgrenze
Geprüft am 6. September 2026: AWS Migration zu CUR 2.0, Data Exports table dictionary, Migration von FOCUS 1.0 zu 1.2, Export delivery und Quotas and restrictions. Prüfen Sie Tabellenwörterbuch und Conformance-Hinweise erneut, bevor ein Schema produktiv festgeschrieben wird.