AWS, Azure und Google Cloud liefern für einen CO2-Bericht nach CSRD monatliche, geschätzte Emissionen je Konto, Region und Service, jeweils in einem eigenen Werkzeug und nie im Kostenexport. Die überarbeiteten ESRS ordnen diese Werte als Teilmenge Scope 3, Kategorie 1 (eingekaufte Waren und Dienstleistungen) zu, auch wenn der Anbieter sie als seine Scopes 1, 2 und 3 ausweist. Dieser Leitfaden zeigt, was jede Quelle liefert, was sie nicht kann und wie Sie die Daten für ESRS E1 oder eine Kundenanfrage aufbereiten. Er ist keine Rechts- oder Prüfungsberatung.
Wer 2026 nach CSRD berichten muss
Der Geltungsbereich hat sich zweimal verschoben. Die „Stop-the-clock“-Richtlinie (EU) 2025/794 hat die zweite Welle um zwei Jahre verschoben. Die Omnibus-Richtlinie (EU) 2026/470, in Kraft seit dem 18. März 2026, beschränkt die Pflicht auf Unternehmen mit mehr als 1.000 Beschäftigten und mehr als 450 Mio. EUR Nettoumsatz, für Geschäftsjahre ab dem 1. Januar 2027. Die Mitgliedstaaten müssen sie bis 19. März 2027 umsetzen und dürfen Unternehmen der ersten Welle, die nicht mehr darunter fallen, für die Geschäftsjahre 2025 und 2026 befreien.
In Deutschland lag der Regierungsentwurf zur CSRD-Umsetzung (BT-Drucksache 21/1857) am 13. April 2026 zur Anhörung im Rechtsausschuss. Eine Verkündung im Bundesgesetzblatt konnten wir bis zum 10. Oktober 2026 nicht feststellen. Den aktuellen Stand klären Sie mit Ihrer Wirtschaftsprüfung.
Die überarbeiteten ESRS (Delegierte Verordnung (EU) 2026/1563) treten am 10. November 2026 in Kraft und gelten für Geschäftsjahre ab dem 1. Januar 2027; für 2026 besteht ein Wahlrecht zwischen alter und neuer Fassung.
Die meisten Start-ups und kleinen Unternehmen berichten danach nicht selbst. Sie werden aber von berichtspflichtigen Kunden gefragt. Hier greift die Wertschöpfungskettenbegrenzung: Unternehmen mit bis zu 1.000 Beschäftigten dürfen Angaben ablehnen, die über die in Anhang II des freiwilligen Standards (Delegierte Verordnung (EU) 2026/1560) gelisteten Datenpunkte hinausgehen; diese Begrenzung gilt für Geschäftsjahre ab dem 1. Januar 2027. Für Unternehmen mit mehr als zehn Beschäftigten gehören dazu die Treibhausgasangaben aus Basismodul B3, also eigener Scope 1 und standortbasierter Scope 2. Scope 3, also auch Ihre Cloud-Emissionen, steht nicht auf dieser Liste.
Wo die Cloud in ESRS E1 steht
In den überarbeiteten ESRS verlangt die Angabepflicht E1-8 die Brutto-Emissionen für Scope 1, Scope 2 standort- und marktbasiert sowie jede wesentliche Scope-3-Kategorie. Nach der Anwendungsanforderung AR 24 (g) weisen Unternehmen Emissionen aus eingekauften Cloud- und Rechenzentrumsdiensten, falls zutreffend, als Teilmenge von Scope 3, Kategorie 1 aus. Google und Microsoft schreiben in ihrer Methodik ebenfalls, dass die zugeordneten Werte beim Kunden Scope 3 sind.
Die Unterscheidung standort- oder marktbasiert betrifft Ihren eigenen Scope 2 als Pflicht. Für die Cloud-Zeile in Scope 3 wählen Sie eine Basis und wenden sie über alle Anbieter und Jahre gleich an.
Was die drei Anbieter liefern
| AWS | Microsoft Azure | Google Cloud | |
|---|---|---|---|
| Werkzeug | AWS Sustainability Console; Tabelle CARBON_EMISSIONS in Data Exports | Carbon optimization im Portal und per REST-API; Emissions Impact Dashboard in Power BI | Carbon Footprint in der Konsole; BigQuery-Export über Data Transfer Service |
| Anbieter-Scopes | 1, 2 standort- und marktbasiert, 3 | Carbon optimization: 1, 2 marktbasiert, 3; Dashboard: 1 und 2 zusammengefasst, 3 | 1, 2 standort- und marktbasiert, 3 |
| Inhalt Scope 3 | vorgelagerte Energie, graue Emissionen von IT-Hardware, Gebäuden und Technik | Dashboard: Kategorien 1, 2, 4, 5, 9 und 12 | graue Emissionen von Geräten und Gebäuden, Dienstreisen, Pendeln, Netzverluste, vorgelagerte Brennstoffe |
| Granularität | Monat je Konto, Region, Service | Carbon optimization: Ressource und Ressourcengruppe; Dashboard: Subscription | Monat je Rechnungskonto, Projekt, Service, Region |
| Verfügbar | bis zum 21. des Folgemonats | bis Tag 19 bzw. 15 nach Monatsende | Export am 15. des Folgemonats |
| Historie | ab Januar 2022 | Carbon optimization: 12 Monate | Backfill bis Januar 2021, marktbasiert ab Januar 2023 |
| Einheit | MTCO2e | kgCO2e (API) | kgCO2e (Export) |
| Methodenstand | Spalte model_version; Historie wird neu berechnet | Neuberechnung der Historie bei Methodenänderung | Spalte carbon_model_version, seit 15. September 2026 Version 17 |
Zwei Termine und eine Frist gehören in den Kalender. Microsoft hat die Microsoft for Sustainability API am 30. Mai 2025 abgekündigt und verweist auf Carbon optimization. Das Emissions Impact Dashboard wird am 31. März 2027 eingestellt; Microsoft empfiehlt, die Daten vorher zu exportieren. Und weil Carbon optimization nur zwölf Monate vorhält, brauchen Sie einen monatlichen Export, um ein Berichtsjahr samt Vorjahresvergleich zu belegen.
Was die Daten nicht leisten
- Keine Genauigkeit pro Workload. Die Anbieter verteilen ihre Emissionen über Nutzungs- und Wirtschaftsschlüssel. Microsoft schreibt, dass die Nutzung für die Emissionsberechnung nicht der abgerechneten Nutzung entsprechen muss.
- Keine Vollständigkeit. AWS schließt über den Marketplace gekaufte Drittsoftware aus; Google nennt Dienste ohne Abdeckung. SaaS-Werkzeuge, Colocation und Endgeräte fehlen ganz.
- Keine Prüfungssicherheit. Google weist darauf hin, dass die kundenspezifischen Daten nicht extern geprüft sind und sich mit Methodenänderungen wesentlich ändern können.
- Keine stabilen Vergangenheitswerte. AWS rechnet die Historie mit neuen Modellversionen neu; ältere Versionen bleiben nur in einem Data Export unter eigenem Präfix erhalten. Bei Google erreichen Korrekturen den BigQuery-Export nur über einen manuellen Backfill.
- Keine Umrechnung aus Euro. Ein Emissionsfaktor auf Cloud-Ausgaben ignoriert Region, Strommix und Rabatte. Für Lücken kann eine ausgabenbasierte Schätzung ein dokumentierter Notbehelf sein, für die abgedeckten Dienste ersetzt sie die Anbieterdaten nicht.
Die Daten monatlich sichern
AWS- und Google-Exporte lassen sich mit SQL zusammenfassen. Für den BigQuery-Export von Google Cloud:
SELECT
usage_month,
project.id AS project_id,
carbon_model_version,
SUM(carbon_footprint_total_kgCO2e.location_based) AS kg_co2e_location_based,
SUM(carbon_footprint_total_kgCO2e.market_based) AS kg_co2e_market_based
FROM `{projekt}.{dataset}.carbon_footprint`
WHERE usage_month BETWEEN DATE '2026-01-01' AND DATE '2026-12-01'
GROUP BY usage_month, project_id, carbon_model_version
ORDER BY usage_month, project_id;
Für die AWS-Tabelle, etwa mit Athena über dem S3-Export:
SELECT
usage_period_start,
usage_account_id,
model_version,
SUM(total_lbm_emissions_value) AS mtco2e_location_based,
SUM(total_mbm_emissions_value) AS mtco2e_market_based
FROM carbon_emissions
GROUP BY usage_period_start, usage_account_id, model_version
ORDER BY usage_period_start, usage_account_id;
Behalten Sie die Modellversion in jeder Auswertung. Zwei Monate mit unterschiedlicher Version sind nur nach einer Neuberechnung vergleichbar.
Ablauf für Bericht oder Kundenanfrage
- Rolle klären. Berichten Sie selbst nach ESRS, antworten Sie einem Kunden nach dem freiwilligen Standard, oder liefern Sie freiwillig mehr? Das bestimmt die Tiefe.
- Exporte einrichten. AWS Data Export für die Emissionstabelle (Berechtigung
sustainability:GetCarbonFootprintSummary), Google-BigQuery-Übertragung (Rolleroles/billing.carbonViewer), Azure-Carbon-Optimization-API (Rolle Carbon Optimization Reader) monatlich. - Unveränderlich ablegen. Jeden Monatsstand mit Abrufdatum und Modellversion archivieren, nie überschreiben.
- Basis festlegen. Markt- oder standortbasiert für alle Anbieter gleich; bei Azure ist in der Dokumentation nur der marktbasierte Scope 2 ausgewiesen.
- Berichtsgrenze abbilden. Konten, Subscriptions und Projekte den Gesellschaften zuordnen, mit derselben Zuordnung wie im monatlichen Cloud-Kostenreview.
- Jahr schließen. Erst nach dem spätesten Anbietertermin, also nicht vor dem 21. Januar für Dezemberdaten von AWS.
- Lücken dokumentieren. Nicht abgedeckte Dienste, Marketplace und andere SaaS-Anbieter mit Methode und Annahme getrennt ausweisen.
Was Costfluent dazu beiträgt
Costfluent berichtet keine Emissionen. Übertragbar ist die Routine eines Kostenberichts: Ein gespeicherter Bericht in den Kostenberichten zeigt die Cloud-Kosten je Konto, Service und Tag, und eine Berichtszustellung schickt monatlich einen Link auf den aktuellen Stand. Verwenden Emissionsregister und Kostenbericht dieselbe Kontozuordnung und denselben Stichtag, sieht Ihr Team, wo Kosten und Emissionen auseinanderlaufen. Wie Sie die Abrechnungsexporte selbst einrichten, zeigen AWS CUR 2.0 oder FOCUS 1.2 und Google-Cloud-Abrechnungsexport für Kostenberichte einrichten.
Quellen und Methode
Geprüft am 10. Oktober 2026: Richtlinie (EU) 2025/794, Richtlinie (EU) 2026/470, Delegierte Verordnung (EU) 2026/1563 (überarbeitete ESRS), Delegierte Verordnung (EU) 2026/1560 (freiwilliger Standard), Kommission zur Annahme der überarbeiteten ESRS, Bundestag: Anhörung zur Nachhaltigkeitsberichterstattung, AWS Sustainability: Einstieg, AWS: Emissionstabelle in Data Exports, AWS: Spalten der Emissionstabelle, AWS Sustainability: Schlüsselbegriffe, AWS: Berechnungsmethodik, AWS: Methodik und Systemgrenze, Azure Carbon optimization, Azure Carbon optimization: Emissionsdaten ansehen, Microsoft: Emissions Impact Dashboard, Microsoft: Berechnungsmethodik, Microsoft: Abkündigungen Sustainability, Google Cloud Carbon Footprint: Methodik, Google Cloud: BigQuery-Export, Google Cloud: Exportschema, Google Cloud: Versionshinweise. Die Tabellen, Abfragen und Schritte sind Costfluent-Empfehlungen und keine Rechts-, Steuer- oder Prüfungsberatung.
