Bildquelle: extern
GreenOps im Multi-Cloud-Betrieb: Welche 5 Reporting-Bausteine IT-Leitungen 2026 aus AWS- und Google-Carbon-Daten wirklich bauen sollten
Viele IT-Leitungen haben 2026 ein ähnliches Problem: Die Cloud-Kosten werden inzwischen halbwegs monatlich gesteuert, die Nachhaltigkeitsdaten aber noch nicht. Dabei liefern die großen Plattformen längst verwertbare CO2-Daten, nur eben nicht in einer Form, die automatisch zu gutem Management führt. Wer Carbon-Dashboards aus AWS oder Google Cloud nur als ESG-Beilage betrachtet, verschenkt einen operativen Hebel. Wer sie dagegen in die laufende IT-Steuerung integriert, bekommt ein zusätzliches Lagebild für Architektur, Abschaltlogik, Regionswahl und Auslastung.
Gerade im Multi-Cloud-Betrieb reicht es nicht, einzelne Screenshots aus Provider-Portalen in ein Reporting-Deck zu kopieren. Die Methoden unterscheiden sich, die Aktualisierung erfolgt zeitverzögert, und die eigentliche Führungsfrage lautet nicht, wie hoch eine Zahl im Portal ist, sondern welche Entscheidungen daraus folgen. Fünf Reporting-Bausteine sind deshalb besonders wichtig.
1. Den Monatsverzug als feste Steuerungsrealität einplanen
Ein häufiger Denkfehler lautet, Carbon-Daten wie Echtzeit-Monitoring behandeln zu wollen. Das funktioniert so nicht. Google Cloud beschreibt, dass Daten für den Vormonat erst bis zu 21 Tage später verfügbar sein können. AWS aktualisiert seine Werte üblicherweise zwischen dem 15. und 21. Tag des Folgemonats. Für das Management ist das kein Mangel, sondern eine Planungsbedingung.
Praktisch heißt das: Wer GreenOps ernsthaft steuern will, braucht einen festen Monatsrhythmus. Idealerweise werden Cloud-Kosten, CO2-Daten und zentrale Auslastungs- oder Abschaltbefunde in derselben Review betrachtet. Dann diskutiert das Team nicht am 3. eines Monats über unvollständige Nachhaltigkeitswerte, sondern beispielsweise in der dritten oder vierten Woche über einen konsistenten Datensatz. Genau dieser Takt verhindert hektische Ad-hoc-Deutungen.
Für IT-Leitungen ist wichtig, den Monatsverzug offen zu dokumentieren. Sonst verwechseln Fachbereiche oder Nachhaltigkeitsteams spätere Nachlieferungen mit Datenfehlern. Ein guter Report enthält daher immer klar erkennbare Stände, Abdeckungszeiträume und den Hinweis, ob Daten bereits vollständig oder noch vorläufig sind.
2. Market-based und location-based Werte nicht vermischen
Der zweite große Stolperstein ist die Vermischung unterschiedlicher Emissionslogiken. Google Cloud trennt im Carbon-Footprint-Bericht explizit zwischen market-based und location-based Emissionsdaten. AWS arbeitet ebenfalls mit beiden Berechnungsmethoden. Für die operative Steuerung ist diese Unterscheidung entscheidend.
Location-based Werte helfen dabei zu verstehen, wie sich Workloads in bestimmten Regionen oder Lastmustern auf Emissionen auswirken, unabhängig von eingekaufter CO2-freier Energie. Market-based Werte sind näher an klassischer Unternehmensberichterstattung, weil sie die vertragliche Beschaffungsseite der Provider einbeziehen. Wer beides in einem Diagramm zusammenzieht, erhält schnell politisch bequeme, aber fachlich unklare Aussagen.
Die einfache Führungsregel lautet deshalb: Für die interne Architektur- und Betriebssteuerung sollte location-based immer sichtbar bleiben. Für externe Berichte oder Scope-3-Logiken kann market-based zusätzlich notwendig sein. Reif wird das Reporting erst, wenn beide Sichten getrennt ausgewiesen und sauber erklärt werden. Dann lässt sich auch nüchterner diskutieren, ob eine Workload-Verlagerung tatsächlich operativ sinnvoll ist oder nur bilanziell hübscher aussieht.
3. Region, Service und Projekt als Pflichtdimensionen normalisieren
Carbon-Daten ohne brauchbare Zerlegung sind für IT-Management kaum nutzbar. Google Cloud stellt Emissionen unter anderem nach Region, Projekt und Produkt dar. AWS zeigt Verläufe nach Regionen und Services und erlaubt CSV- beziehungsweise Data-Export-Pfade. Genau daraus ergibt sich der dritte Reporting-Baustein: Die Daten müssen providerübergreifend auf wenige, stabile Managementdimensionen normalisiert werden.
Bewährt haben sich mindestens drei Achsen. Erstens die Region, weil Standort- und Architekturentscheidungen oft dort ansetzen. Zweitens der Service- oder Produktblick, damit sichtbar wird, ob Compute, Storage, CDN oder andere Leistungen den Schwerpunkt bilden. Drittens ein Owner- oder Projektbezug, damit Emissionen nicht im Nirgendwo landen.
Gerade in Multi-Cloud-Umgebungen entstehen sonst typische Missverständnisse. Ein Team optimiert Compute-Laufzeiten, ein anderes verschiebt Daten zwischen Regionen, ein drittes betreibt ungenutzte Projekte weiter. Im Gesamtbild sieht die IT-Leitung nur eine Gesamtsumme, aber keinen Hebel. Erst die Normalisierung auf Region, Service und Verantwortlichkeit macht aus Carbon-Daten ein steuerbares Instrument.
4. Export statt Screenshot: Carbon-Daten gehören in die eigene Datenplattform
Sobald mehrere Konten, Projekte oder Provider im Spiel sind, ist Portal-Reporting zu klein. Google Cloud bietet den Export der Carbon-Footprint-Daten nach BigQuery an. AWS verweist auf CSV-Downloads und Data Exports, um Daten tiefer auszuwerten oder in eigene Dashboards zu integrieren. Genau das sollte 2026 der Standard sein.
Der Grund ist simpel: Nur exportierte Daten lassen sich mit Kosten, Auslastung, Inventaren oder Abschaltlisten verbinden. Ein Screenshot aus einem Provider-Portal beantwortet keine Frage wie diese: Welche Anwendungen verursachen in einer emissionsintensiven Region gleichzeitig hohe Kosten und geringe Nutzung? Genau dort entsteht aber Managementnutzen.
IT-Leitungen sollten deshalb Carbon-Reporting technisch ähnlich behandeln wie FinOps-Daten. Es braucht einen belastbaren Exportpfad, definierte Berechtigungen, eine nachvollziehbare Historie und klare Eigentümerschaft für das Datenmodell. Google nennt für den Zugriff eigene IAM-Rollen wie den Carbon Footprint Viewer. Auch das ist ein wichtiger Punkt: Nachhaltigkeitsdaten sind kein hübscher Zusatz, sondern ein Governance-Thema mit Rollen, Berechtigungen und Auditfähigkeit.
5. Aus Reporting muss eine konkrete Maßnahmenliste werden
Der fünfte Baustein ist der wichtigste, weil hier viele Programme scheitern. Ein Carbon-Report ohne Maßnahmenlogik wird schnell zur Folie für den Lenkungskreis. Die Providerdaten selbst geben aber schon Hinweise auf sinnvolle nächste Schritte. Google verweist etwa auf Empfehlungen zu unbeaufsichtigten Projekten, also klassisch auf Abschalt- und Aufräumthemen. AWS zeigt Emissionen nach Region und Service über bis zu 38 Monate und macht Trends damit vergleichbar.
Für die Praxis lohnt sich eine kleine, feste Maßnahmenmatrix mit immer denselben Fragen:
- Welche Workloads laufen dauerhaft in Regionen mit hoher Emissionswirkung, obwohl es betriebliche Alternativen gäbe?
- Welche Services wachsen beim CO2-Ausstoß schneller als beim Geschäftsnutzen?
- Welche Umgebungen wirken verwaist, untergenutzt oder nachts beziehungsweise am Wochenende unnötig aktiv?
- Wo gibt es Einsparpotenzial zugleich bei Kosten und Emissionen, etwa durch Rightsizing, Lifecycle-Regeln oder Storage-Bereinigung?
- Welche Produktteams müssen ihre Architekturentscheidungen künftig mit einer zusätzlichen Carbon-Sicht begründen?
Erst wenn aus dem Report eine wiederkehrende Liste solcher Entscheidungen entsteht, wird GreenOps im Multi-Cloud-Betrieb relevant. Dann sprechen IT-Leitungen nicht mehr abstrakt über Nachhaltigkeit, sondern über Abschaltfenster, Regionswahl, Datenhaltung und Architekturstandards.
Was IT-Leitungen jetzt konkret festziehen sollten
- Einen festen Review-Termin in der zweiten Monatshälfte setzen, damit die zeitverzögerten Providerdaten vollständig vorliegen.
- Location-based und market-based Werte getrennt führen, statt sie für schnelle Managementgrafiken zusammenzuwerfen.
- Region, Service und Owner als Pflichtdimensionen definieren, damit aus Summen operative Hebel werden.
- Providerdaten exportieren und mit Kosten- und Nutzungsdaten verbinden, statt Portal-Screenshots manuell weiterzureichen.
- Jede Review mit einer Maßnahmenliste schließen, zum Beispiel zu Abschaltung, Rightsizing, Datenverlagerung oder Architekturvorgaben.
Fazit
GreenOps wird 2026 im Multi-Cloud-Betrieb erst dann wirksam, wenn Carbon-Daten denselben Führungsstatus bekommen wie Kosten- oder Verfügbarkeitsdaten. AWS und Google liefern dafür längst mehr als reine Symbolzahlen: Regionen, Services, Exporte, Methodenunterschiede und Verlaufssichten. Der Engpass liegt nicht mehr im Fehlen von Daten, sondern in ihrer operativen Übersetzung.
Wer den Monatsverzug akzeptiert, Berechnungsmethoden sauber trennt, die Daten auf wenige Managementachsen normalisiert und konsequent mit Maßnahmen verknüpft, macht aus Nachhaltigkeitsmetriken ein brauchbares Steuerungsinstrument. Genau dort beginnt der fachliche Nutzwert, und genau dort trennt sich GreenOps von reiner Berichtspflicht.
