Die durchgängige Zuordnung des CO₂-Fußabdrucks der IT-Infrastruktur – von der Serverhardware bis hin zu den darauf basierenden Services und Transaktionen – liefert einen einheitlichen Satz an Kennzahlen, der in beide Richtungen genutzt werden kann. Zusammengefasst lassen sich daraus Werte wie CO₂-Ausstoß pro Transaktion, pro Kunde oder pro Produkt ableiten, sodass Unternehmen nachvollziehen können, ob sich ihre Nachhaltigkeitsleistung im Laufe der Zeit verbessert. Gleichzeitig ermöglichen dieselben Daten bei einer detaillierten Betrachtung die Rückverfolgung bis zu einzelnen Services, Hosts und Komponenten. Dadurch erhalten Dev- und Opsteams eine klare Ursache-Wirkungs-Kette sowie konkrete Ansatzpunkte, um den CO₂-Ausstoß wirksam zu reduzieren.

Unser Ansatz zur Zuordnung, den wir „Green Native“ nennen, verleiht dieser Aufschlüsselung eine klare Struktur und bleibt zugleich flexibel genug, um sich an unterschiedliche Systemlandschaften anzupassen. Dabei greifen wir auf Metriken zurück, die von cloud-nativen Tools und Anbieter-APIs ohnehin bereits erfasst werden, anstatt eine zusätzliche Messschicht aufzubauen. Dadurch bleibt die Integration kostengünstig, und auch der ökologische Fußabdruck der Messung selbst ist vernachlässigbar gering.

Physische Realität

Drei Faktoren bestimmen den CO₂-Fußabdruck jeder Hardware-Komponente im Rechenzentrum: der Energieverbrauch, die CO₂-Intensität des Stromnetzes, das die Hardware versorgt, sowie die sogenannten eingebetteten Emissionen beziehungsweise die bei der Herstellung entstandenen Emissionen, die bereits in der Hardware „stecken“. Server, Speichersysteme und Netzwerk-Switches verbrauchen kontinuierlich Strom; dadurch ergeben sich aus den ersten beiden Faktoren gemeinsam die betrieblich verursachten Emissionen.

Die CO₂-Intensität des Stromnetzes beschreibt die Menge an CO₂, die pro verbrauchter Kilowattstunde Strom ausgestoßen wird (gCO₂/kWh). Sie variiert je nach Region und hängt vom jeweiligen Strommix ab: Stromnetze mit hohem Anteil fossiler Energieträger verursachen deutlich höhere Emissionen als Netze mit einem hohen Anteil erneuerbarer Energien. Die folgende Grafik veranschaulicht diese Unterschiede am Beispiel von Österreich, Deutschland und der Schweiz.

Die CO₂-Intensität verändert sich zudem im Tagesverlauf. Übersteigt die Stromnachfrage das Angebot aus erneuerbaren Energien, greifen Stromnetze verstärkt auf fossile Kraftwerke zurück, wodurch die Emissionsintensität steigt. Können erneuerbare Energien den Bedarf hingegen decken, sinkt sie. Deshalb spielt auch der Zeitpunkt der Ausführung von Workloads eine wichtige Rolle: Dieselbe Rechenlast kann zur Mittagszeit und um 3 Uhr morgens einen deutlich unterschiedlichen CO₂-Fußabdruck verursachen.

Wähle zunächst in der oben dargestellten Grafik eine Region und eine Uhrzeit aus und anschließend darunter ein Hardwareprofil. Die gewählte Region und Uhrzeit bestimmen die CO₂-Intensität des Stromnetzes, während das Hardwareprofil festlegt, wie viel Energie der Workload verbraucht. Der PUE-Wert (Power Usage Effectiveness) berücksichtigt zusätzlich den Overhead des Rechenzentrums, etwa für Kühlung, Beleuchtung und weitere Systeme, die parallel zur IT-Last betrieben werden. Das Produkt aus diesen drei Faktoren ergibt die Emissionen für den ausgewählten Zeitraum. Bei Auswahl einer einzelnen Stunde wird der Emissionswert pro Stunde angezeigt; beim Markieren eines Zeitbereichs werden die Werte aufsummiert.

Die sogenannten eingebetteten Emissionen („Embodied Carbon“) beschreiben den CO₂-Fußabdruck, der bei der Herstellung der Hardware entsteht und über deren gesamte Nutzungsdauer verteilt wird. Dieser Anteil gewinnt relativ an Bedeutung, je klimafreundlicher die Stromnetze werden. Deshalb sind die Lebensdauer der Hardware und deren effiziente Auslastung ebenso wichtig wie der eigentliche Energieverbrauch im Betrieb.

Der PUE-Wert (Power Usage Effectiveness) beschreibt das Verhältnis zwischen dem gesamten Energieverbrauch eines Rechenzentrums und dem Energieverbrauch der IT-Systeme allein. Ein PUE von 1,0 heißt: Jedes Watt aus dem Netz erreicht einen Server. Alles darüber zeigt den Anteil, der für Kühlung, Beleuchtung und sonstigen Overhead anfällt.

Komponenten eines Servers

Ein Server ist keine einzelne Energiequelle mit konstantem Verbrauch. Fast der gesamte Energiebedarf lässt sich auf vier Komponenten runterbrechen: CPU, RAM, Storage und GPU. Jede dieser Komponenten reagiert unterschiedlich auf Veränderungen der Auslastung und verbraucht abhängig davon unterschiedlich viel Energie. Um den CO₂-Ausstoß einzelnen Workloads korrekt zuzuordnen, modellieren wir diese Komponenten daher separat.

Netzwerkinfrastruktur stellt dabei einen Sonderfall dar. Sie läuft in der Regel auf dedizierter Hardware wie Switches, Netzwerkkarten (NICs) oder Load-Balancern, die nicht Teil des Energieverbrauchs eines Servers selbst sind. Dennoch verursacht auch sie CO₂-Emissionen, insbesondere bei Workloads mit hohem Datenverkehr. Dieser Aspekt wird jedoch im Rahmen dieses Artikels nicht näher behandelt.

Die Zusammenhänge unterscheiden sich je nach Komponente. Der Energieverbrauch der CPU steigt in etwa linear mit der Auslastung an. Arbeitsspeicher (RAM) hingegen verursacht nahezu einen konstanten Verbrauch pro Gigabyte - unabhängig davon, ob der Speicher aktiv genutzt wird oder nicht. Bei persistentem Speicher hängt der Verbrauch vom jeweiligen Medium ab: SSDs arbeiten auf einem weitgehend konstanten Leistungsniveau, während HDDs zwischen aktiven und inaktiven Zuständen wechseln. GPUs weisen die größte Dynamik auf: Eine leerlaufende Grafikkarte verbraucht vergleichsweise wenig Energie, während eine voll ausgelastete den CO₂-Fußabdruck des gesamten Hosts dominieren kann.

Komponentenbezogene Energieverbräuche sind heute grundsätzlich messbar, allerdings nicht immer durchgängig und einheitlich. Die Leistungsaufnahme der CPU kann man (wenn verfügbar) über RAPL (Running Average Power Limit) auslesen; RAM ist oft im selben "RAPL-Package" enthalten. Der Energieverbrauch von GPUs wird über herstellerspezifische Werkzeuge ausgelesen, etwa NVIDIAs NVML oder AMDs ROCm-SMI. Bei persistentem Speicher ist die Lage am schwierigsten: Moderne Laufwerke liefern zwar über SMART Informationen zu Zustand und Leistung, jedoch nur selten Echtzeitdaten zum Energieverbrauch. Daher wird dieser häufig indirekt aus Zugriffsprofilen oder aus NVMe-Herstellerprotokollen geschätzt.

Den Server mit Virtualisierung aufteilen

Beginnen wir mit einem einzelnen Server. Sein Energie- bzw. CO₂-Fußabdruck lässt sich klar in Beiträge von CPU, RAM, Speicher und GPU aufteilen. Der nächste Schritt besteht darin, diesen Fußabdruck wieder den Workloads zuzuordnen, die sich den Server teilen.

In der Cloud ist die VM die Standard-Aufteilungseinheit. Physische Exklusivität ist zwar möglich, aber mit höheren Kosten verbunden. Verschiedene Workloads landen über Virtualisierung auf demselben Host, der Fußabdruck des Servers muss also nach Ressourcenanteil über die VMs verteilt werden.

Für jede VM zeigt die Virtualisierungsplattform, wie viel CPU, RAM, Storage und GPU ihr zugewiesen sind und wie viel davon sie tatsächlich nutzt. Diese Werte bilden die Grundlage für die Aufteilung des Fußabdrucks. Dadurch werden diejenigen VMs sichtbar, die am meisten zum Gesamtausstoß beitragen, und es zeigt sich, wo Optimierungen den größten Effekt haben.

Die Aufteilung des Fußabdrucks einer VM nach Komponenten zeigt, wo tatsächlich CO₂ verursacht wird - und wo nicht. Wenn beispielsweise die GPU den größten Anteil ausmacht, haben Optimierungen auf CPU-Ebene kaum Einfluss auf den Gesamtwert. Dieselbe Betrachtung macht auch die Auswirkungen von Änderungen bei der Ressourcenzuteilung sichtbar: Wird der Arbeitsspeicher erhöht, steigt entsprechend der RAM-Anteil des Fußabdrucks. Ob das relevant ist, hängt jedoch davon ab, wie stark diese Komponente im Gesamtmix des Workloads ins Gewicht fällt.

Virtualisierung bringt einen eigenen Overhead mit sich: den Hypervisor, die Management-Ebene und die gesamte Plattform-Infrastruktur. Dieser Anteil sollte klein sein; ist er es nicht, ist das bereits ein wichtiger Hinweis auf ein mögliches Problem. Im Modell wird dieser Overhead gleichmäßig auf alle VMs eines Hosts verteilt, eine pragmatische Entscheidung, da dieser Aufwand keinem einzelnen Mandanten eindeutig zugeordnet werden kann.

Die Gewichtung nach tatsächlicher Nutzung löst auch das Problem sogenannter „noisy neighbour“ ohne zusätzlichen Aufwand. Wird eine VM in der Abbildung in Box 5 als „noisy“ markiert, erhöht sich ihr Anteil am CO₂-Fußabdruck des Hosts, ohne dass sich ihre zugewiesenen Ressourcen verändern. Die Formel erkennt schlicht die höhere Auslastung, wodurch die VM, die tatsächlich die Arbeit verursacht, automatisch den größeren Anteil des Fußabdrucks erhält.

Die VM mit Containern weiter aufteilen

Die meisten modernen Deployments enden nicht bei der VM. Kubernetes (oder ein anderer Orchestrator) legt eine weitere Schicht darüber. Ein Workload steht hier für eine Anwendung oder einen Service, die im Cluster als ein oder mehrere Container laufen, zum Beispiel ein API-Service, eine Datenbank oder Monitoring. Ein einzelner Node hostet viele davon gleichzeitig. Die gleiche Aufteilung muss daher eine Ebene tiefer erneut erfolgen: Der CO₂-Fußabdruck des Nodes wird anteilig den einzelnen Workloads zugewiesen, die darauf ausgeführt werden.

Die Aufteilungsfaktoren haben auf dieser Ebene dieselbe Struktur wie eine Ebene darüber: CPU-Zeit (reserviert und tatsächlich genutzt) pro Container, RAM-Zuweisung, Nutzung persistenter Volumes sowie GPU-Zeit. All das sind Standardmetriken in Kubernetes. Der CO₂-Fußabdruck eines Nodes wird entsprechend seines anteiligen Beitrags auf die Container aufgeteilt. Diese Anteile werden anschließend pro Workload über alle Nodes hinweg aufsummiert, auf denen er ausgeführt wird.

Eine Regel in unserem Attributionsmodell verdient besondere Aufmerksamkeit: Jedes Gramm CO₂ wird immer zugeordnet. Wird ein Container korrekt dimensioniert, ein Node entfernt oder eine ungenutzte GPU abgeschaltet, zeigt sich das direkt als sinkender Wert – es verschwindet nicht unbemerkt in einer Nebenrechnung. Alles, was nicht sinnvoll einem Workload zugeordnet werden kann (z. B. ein leerer Node oder eine GPU ohne aktive Nutzung), wird in einer expliziten Kategorie für ungenutzte Kapazität erfasst. Dieser Anteil steht für Reservekapazität, die bewusst vorgehalten wird, um Lastspitzen abzufangen. In Box 8 wird diese Reserve später auf die Transaktionen verteilt, die von dieser verfügbaren Kapazität profitieren. Dadurch bleibt die gesamte Bilanz durchgängig nachvollziehbar und vollständig zurechenbar.

Ein Vorbehalt: Der Wert für ungenutzte Kapazität ist hier eher pessimistisch angesetzt. In der Realität verbrauchen inaktive Nodes und nicht zugewiesene GPUs eher ihre Leerlaufleistung als ihre Volllastleistung, sodass die tatsächlichen Emissionen von Reservekapazitäten niedriger sind als hier dargestellt. Das Modell in dieser interaktiven Erklärung führt die Auslastung der einzelnen Komponenten nicht wieder zurück in die Gesamtleistungskurve des Hosts. Dadurch wird ungenutzte Kapazität so behandelt, als würde sie den gesamten durchschnittlichen Verbrauch des Hosts mittragen, anstatt auf den echten Leerlaufverbrauch zu fallen. Für den Alltag zählt vor allem das Richtungssignal: „dieser Node erledigt keine nützliche Arbeit".

Services und Transaktionen

Workloads stehen nicht für sich allein. Ein Webservice ruft einen Authentifizierungsdienst auf; dieser nutzt wiederum eine Datenbank; und ein Monitoring-System beobachtet alle Komponenten. Jeder dieser Aufrufe trägt einen Anteil der verursachten Emissionen weiter an den aufrufenden Dienst. Die in Box 6 berechneten Werte auf Workload-Ebene sind daher nur der Ausgangspunkt. Der nächste Schritt besteht darin, diese Emissionen entlang des Service-Graphen zurück bis zu der Transaktion weiterzureichen, die die gesamte Kette ausgelöst hat.

Geteilte Dienste wie Monitoring, Authentifizierung oder Datenbanken werden von nahezu allen Workloads genutzt. Ihr CO₂-Fußabdruck muss deshalb auf die einzelnen Verbraucher verteilt werden, basierend auf einem Signal, das die tatsächliche Nutzung bzw. den verursachten Aufwand widerspiegelt, etwa Anzahl der Aufrufe, Telemetrievolumen, Query-Last oder Anzahl der Sessions. Die Wahl dieser Aufteilungsbasis ist selbst eine Designentscheidung: Unterschiedliche Teams können denselben Dienst unterschiedlich attribuieren. Box 7 zeigt daher mehrere mögliche Ansätze pro Datenquelle, sodass diese Entscheidung transparent bleibt und nicht in einer versteckten Formel verborgen ist.

Pragmatisch mit Zyklen umgehen

Dabei ist zu beachten, dass auch das Monitoring auf den Kubernetes-Overhead zurückverweist: Es beobachtet die Cluster-Control-Plane genauso wie alle anderen Komponenten. Ein Teil der Emissionen des Monitorings muss daher wiederum Kubernetes zugerechnet werden. Dadurch entsteht im Graphen eine zyklische Abhängigkeit: Kubernetes verteilt Emissionen an das Monitoring, und das Monitoring gibt einen Teil davon wieder zurück. Eine einzelne Zuordnungsrunde kann dieses Problem nicht sauber lösen, da die Rückverteilung erst erfolgt, nachdem Kubernetes seine Anteile bereits an Datenbank, Authentifizierung und andere Dienste weitergegeben hat.

Pragmatisch löst man das durch Iteration: In jedem Durchlauf wird nur der Anteil weitergegeben, den ein Dienst im vorherigen Schritt erhalten hat. Dadurch konvergiert die Verteilung nach wenigen Iterationen geometrisch (in dieser Simulation nach sechs Durchläufen). In der Praxis treten solche Zyklen häufig auf und der noch pragmatischere Ansatz ist schlichtes Ignorieren, der dadurch entstehende Fehler ist meist vernachlässigbar. Probiere es aus: Setze den Selbstbezug des Monitorings im Panel oben auf null (Monitoring überwacht seine eigenen Daten nicht) oder kappe die k8s↔monitoring-Schleife, und schau zu, wie kaum etwas an den Gesamtsummen passiert. Für den produktiven Einsatz ist ein eigenes Meta-Monitoring auch aus anderer Hinsicht die sauberere Lösung.

Transaktionen bilden die nächste Detailebene. Sie stehen für einen konkreten Geschäftsvorgang – etwa eine Benutzeranfrage, einen Inferenzaufruf oder einen Batch-Job –, der eine Reihe von Service-Aufrufen auslöst. Jede Transaktion übernimmt dabei einen anteiligen CO₂-Fußabdruck aller Services, die sie nutzt. Daraus ergibt sich ein CO₂-Wert pro Transaktion, den das Unternehmen direkt zur Bewertung und Steuerung verwenden kann.

Die Aufteilung zwischen Transaktionen innerhalb eines Service kann auch über unterschiedliche Wege erfolgen. APM-Tools, Request-Traces oder einfache Zeitmessungen zeigen, welchen Anteil der Arbeit eines Services jede einzelne Transaktion verursacht. Auf dieser Grundlage lässt sich der CO₂-Fußabdruck anschließend über eine gewichtete Zuordnung direkt auf die jeweiligen Transaktionen verteilen.

Die endgültige Einordnung hängt vom jeweiligen Geschäftsmodell ab. Für einen Händler ist beispielsweise der CO₂-Ausstoß pro Bestellung oder pro Euro Umsatz (GMV) relevant, für einen SaaS-Anbieter der CO₂-Ausstoß pro Nutzerlizenz oder Sitzung und für einen KI-Dienst der CO₂-Ausstoß pro 1.000 Tokens. Der Zweck der vollständigen Herunterbrechung bis auf Transaktionsebene besteht darin, am Ende eine Kennzahl zu erhalten, die im Unternehmen ohnehin bereits verwendet wird. So können Engineering- und Produktteams auf Grundlage derselben Zahlen entscheiden, welche Optimierungen den größten Nutzen bringen.

Was man in der Cloud tut

n der Cloud ist die VM-Ebene der Einstiegspunkt für dieses Modell. Provider stellen nur selten direkte Energiedaten der zugrunde liegenden Hardware bereit. Deshalb werden Emissionen auf VM-Ebene meist anhand der Hardwarearchitektur und der tatsächlichen Auslastung geschätzt. Projekte wie cloudcarbonfootprint.org formalisieren genau das. Veröffentlicht ein Provider Sustainability-Daten zu VMs oder konkreten Managed Services (Datenbanken, Queues, KI-APIs), klinken sich diese mit geringem Aufwand in dieselbe Attributionskette ein.

Die Qualität des Modells folgt der Qualität der Aufteilungsfaktoren: Je direkter eine Metrik mit dem Energieverbrauch korreliert, desto besser die Attribution. Sind die notwendigen Daten einmal vorhanden, ergibt sich die Reihenfolge der Optimierung nahezu von selbst. Beginne bei den Services und Komponenten mit dem größten Anteil und arbeite dich zu den kleineren vor, sobald die ersten erledigt sind. Wichtig ist, das Modell zu verstehen: Erst wenn klar ist, wie es Emissionen über Komponenten und Services routet, wird aus einer Attributionszahl eine belastbare Änderung.

Verbesserungen

Das Ergebnis ist eine einzige Kennzahl: der CO₂-Fußabdruck – aufgeschlüsselt von der physischen Hardware bis hinunter zu den Emissionen pro einzelner Transaktion. Ziel ist es, diesen Wert zu reduzieren. Erst durch diese Kennzahl wird Optimierung zu einer messbaren Aufgabe statt nur zu einer groben Orientierung.

Fang mit den größten Beiträgen an. Ein Service, der einen großen Anteil am gesamten CO₂-Fußabdruck verursacht, bietet auch das größte absolute Einsparpotenzial – unabhängig davon, ob die Verbesserung durch effizienteren Code (z. B. geringere CPU-Last), Kapazitätsoptimierung (Right-Sizing oder Entfernen ungenutzter Ressourcen) oder architektonische Änderungen erreicht wird. Verbesserungen kommen auf jeder Schicht des Stacks vor; der Wert des Modells liegt darin, dir zu sagen, welche Schicht du zuerst aufmachen solltest.

Bei Posedio führen wir CO₂-Assessments für IT-Systeme durch und begleiten Teams dabei, die Ergebnisse umzusetzen, von Workload Right-Sizing bis zur architektonischen Änderung. Das Self-Assessment ist ein Vorgeschmack darauf, wie wir an das Thema herangehen. Mehr dazu findest du unter greennative.posedio.com, oder melde dich, um über deinen Stack zu sprechen.