Warum Cloud-Emissionen auf die Agenda der Geschäftsführung gehören

Fast das ganze vergangene Jahrzehnt lang war die Cloud vor allem eine praktische Metapher. Man schob seine Workloads dorthin, am Monatsende kam die Rechnung, und die Hallen voller GPUs in Nord-Virginia oder Südschweden blieben stumm und unsichtbar im Hintergrund. Damit ist es vorbei. Cloud-Emissionen haben den Nachhaltigkeitsbericht verlassen und sitzen jetzt mit am Tisch – dort, wo sich Finanzen, Recht und Technik gegenübersitzen.

Warum Cloud-Emissionen das Geschäft betreffen

Vier Kräfte machen Druck. Jede einzelne davon würde reichen, um das Thema ernst zu nehmen.

Die Betriebskosten laufen in die falsche Richtung

Das Versprechen, der Umzug in die Cloud senke die Kosten wie von selbst, hat sich nicht erfüllt. Elastizität ist keine Erfindung – aber ohne Governance ist sie bloß Verbrauch, den niemand im Blick behält.

Woran das liegt:

• Instanzen laufen weiter, weil sich niemand für sie zuständig fühlt
• Speichervolumes stehen verwaist herum, weil das zugehörige Projekt längst eingestellt wurde – nur dem Volume hat das keiner gesagt
• Test- und Staging-Umgebungen ziehen noch sechs Monate nach dem Teamwechsel des Entwicklers, der sie einst aufgesetzt hat, Strom

Vorschriften sind keine Kür

Im Zentrum der Debatte steht die EU-Richtlinie zur Nachhaltigkeitsberichterstattung von Unternehmen (CSRD). Nach den Europäischen Standards für die Nachhaltigkeitsberichterstattung müssen Unternehmen die Treibhausgasemissionen aus eingekauften Cloud- und Rechenzentrumsdiensten offenlegen – sie zählen als vorgelagerte Scope-3-Emissionen.

Bei Verstößen drohen:

• Geldbußen, die bewusst abschreckend bemessen sind
• das Aussetzen von Subventionen, Steuergutschriften und Projektfinanzierungen
• der Ausschluss von öffentlichen Ausschreibungen – für manche Branchen die wichtigste Einnahmequelle
• die öffentliche Bekanntgabe des Verstoßes, samt Reputationsschaden

Ergänzend verpflichtet die EU-Energieeffizienzrichtlinie von 2023 Rechenzentrumsbetreiber dazu, ihren Energie- und Wasserverbrauch zu melden.

Ineffiziente Cloud-Nutzung ist verschwendetes Geld

Jeder ungenutzte CPU-Zyklus, jede überdimensionierte Datenbankinstanz, jedes verwaiste Speichervolume ist zweierlei zugleich: ein Posten auf der Rechnung und eine Last für ein Stromnetz, das vielerorts noch immer zum Teil mit fossilen Brennstoffen läuft. Rechnung und Emissionen als zwei getrennte Probleme zu behandeln, war schon immer eine bequeme Illusion.

Teams, die wirklich vorankommen, denken in „Unit Economics“: Kosten und CO₂-Ausstoß, gemessen pro Transaktion, pro Sitzung, pro API-Aufruf. Verändern sich die Stückkosten, ohne dass das Nutzeraufkommen mitzieht, ist im Stillen etwas aus dem Ruder gelaufen – und das Team merkt es nach einer Woche statt nach einem Quartal.

Cloud-Ineffizienz ist meist ein Symptom tiefer liegender Probleme

Dauerhafte Verschwendung in der Cloud geht selten auf eine einzelne falsche Provisions-Entscheidung zurück. Sie ist die sichtbare Oberfläche älterer Versäumnisse:

• Eine monolithische Architektur, die durch Replikation statt nach Bedarf skaliert, verdoppelt ihren Platzbedarf mit jeder Verdopplung der Nutzerbasis.
• Ein Datenbankschema, das seit fünf Jahren niemand angefasst hat und das inzwischen bei jeder Kundenabfrage einen vollständigen Tabellenscan auslöst.
• Eine manuelle „ClickOps“-Kultur, die Konfigurationsabweichungen produziert, die kein Audit rechtzeitig einfängt.

Was die Emissionen tatsächlich nach oben treibt

Das große Bild ist schnell erzählt: Der Bedarf an Cloud-Rechenleistung wächst schneller als die Effizienz der Infrastruktur, die sie liefert. Drei Treiber verdienen es, beim Namen genannt zu werden.

KI bedeutet einen Sprung im Energiebedarf, keine Steigerung in kleinen Schritten

KI-Workloads sind keine rechenhungrigeren Varianten gewöhnlicher Cloud-Aufgaben. Sie bilden eine eigene Kategorie – und die IEA-Analyse zu Energie und KI für 2026 belegt das mit Zahlen:

• Der weltweite Strombedarf von Rechenzentren stieg 2025 um 17 %, der KI-bezogene Verbrauch im selben Jahr um 50 %
• Laut IEA-Prognose verdoppelt sich der Stromverbrauch von Rechenzentren nahezu: von 485 TWh im Jahr 2025 auf rund 950 TWh bis 2030
• Eine herkömmliche Cloud-CPU zieht unter Volllast 150 bis 300 Watt. Eine moderne KI-Trainings-GPU kommt auf 700 bis über 1.000 Watt – pro Chip. Und Cluster betreiben Zehntausende davon

Die Rechenzentren selbst

Die Cloud besteht inzwischen aus weltweit über 10.000 Standorten – und die sind längst nicht alle gleich effizient. Hyperscaler betreiben optimierte Gebäude mit einer Power Usage Effectiveness (PUE) zwischen 1,1 und 1,2; nahezu die gesamte Energie kommt dort bei der Rechentechnik an. Der europäische Durchschnitt für Standard-Rechenzentren liegt eher bei 1,58. Das heißt: Zusätzlich zur Rechenenergie versickern 50 bis 100 % im Overhead, vor allem in veralteter Luftkühlung.

Ein Workload in einem solchen Gebäude zahlt einen versteckten Aufschlag, den bessere Technik vermeiden könnte.

Organisatorische Silos und die fehlende Rückkopplung

Der dritte Treiber hat nichts mit Technologie zu tun. Es ist die Distanz zwischen dem Ingenieur, der die Ressource angefordert hat, dem Finanzteam, das die Rechnung in der Hand hält, und dem Nachhaltigkeitsteam, das die Zahlen am Ende gegenüber der Aufsicht erklären muss. Solange diese drei Bereiche keine gemeinsame Datenbasis haben, bleibt die Rückkopplungsschleife unterbrochen. Wenn die Monatsrechnung eintrifft, ist das CO₂ längst entwichen.

Wie ein Software-Engineering-Team wirklich etwas bewegt

Nichts von dem, was folgt, ist neu, und kein einzelnes Tool löst das Problem. Es sind Maßnahmen, die erfahrene Cloud-Beratungs- und Engineering-Teams umsetzen – und deren Wirkung sich im Zusammenspiel verstärkt.

Energieeffizientes Programmieren – mit einem Vorbehalt

Die Wahl der Programmiersprache wiegt schwerer, als in den üblichen „Sprachkriegen“ zugegeben wird. Grundlagenforschung des Green Software Lab zeigt: Kompilierte Systemsprachen wie C, Rust und Go verbrauchen um eine Größenordnung weniger Energie als interpretierte Sprachen wie Python oder Ruby – fast ausschließlich, weil sie schneller ausführen und die CPU früher wieder in den Leerlauf entlassen.

Wichtiger als die Sprache ist allerdings, wie gut der Algorithmus geschrieben ist. Einen Microservice mit hohem Durchsatz in Rust oder Go neu zu schreiben, lohnt sich meist. Eine ganze Codebasis umzuschreiben, lohnt sich selten.

Besseres Daten- und Ressourcenmanagement

Datenbanken sind in nahezu jeder Cloud-Umgebung die größten Konsumenten von CPU, Arbeitsspeicher und Festplatten-E/A. Damit ist Datenbank-Engineering eine ökologische Disziplin – ob man es so nennt oder nicht. Konkret:

• Nicht optimierte Abfragen, die vollständige Tabellenscans erzwingen, halten die CPU-Auslastung dauerhaft hoch; gezielte Indizierung bringt den Prozessor schneller zurück in den Leerlauf
• Konflikte bei Zeilensperren in hochparallelen Systemen lösen Spin-Loops aus, die den CPU-Verbrauch hochtreiben, ohne produktive Arbeit zu leisten
• Datenwucher – über Jahre angehäufte ungenutzte Tabellen, aufgegebene Indizes und veraltete Datensätze – bläht den Speicherbedarf auf, samt der Energie für dessen Pflege

GreenOps, Echtzeit-Telemetrie und CO₂-Dashboards

Was sich nicht messen lässt, lässt sich nicht optimieren. Die CO₂-Rechner der Hyperscaler sind für Führungskräfte gedacht: Sie liefern aggregierte, verzögerte Daten und helfen einem Ingenieur, der noch diese Woche ein Problem beheben will, kaum weiter. Der ehrliche Weg führt über Open-Source-Tools, die auf Kernel-Ebene ansetzen.

Das Kepler-Projekt, eine Sandbox-Initiative der CNCF, liest beispielsweise per eBPF die Leistungssensoren der Hardware direkt aus und ordnet den Verbrauch einzelnen Containern, Pods und Prozessen zu – bereitgestellt als Prometheus-Metriken. Die ausgereifte Form davon ist CO₂-bewusstes Computing: Fehlertolerante Workloads laufen dann und dort, wo das Netz gerade reichlich Wind- und Sonnenstrom liefert.

Serverless und Containerisierung

Moderne Rechenmuster beseitigen den Großteil der Leerlaufverschwendung – etwas, das monolithische Deployments nicht können. Serverless-Funktionen laufen nur, wenn ein Ereignis sie auslöst, und skalieren unmittelbar danach auf null; das ist die theoretische Grenze energieeffizienten Rechnens. Kubernetes-Orchestrierung erreicht Ähnliches über Dichte: Gut abgestimmte Cluster erzielen routinemäßig eine höhere Serverauslastung als manuell verwaltete VMs.

Welche Kompromisse damit einhergehen, beschreiben wir in unseren Prinzipien der Cloud-Architektur.

Strategische Migrationen aus lokalen Umgebungen

Für Unternehmen, die noch eine umfangreiche lokale Infrastruktur betreiben, ist eine sorgfältig geplante Migration zu einem Hyperscaler die Entscheidung mit dem größten Hebel, die aktuell zur Wahl steht. Ein „Lift-and-Shift“ verschiebt ineffiziente Workloads allerdings nur auf sauberere Infrastruktur – die Ineffizienz selbst bleibt. Echte Modernisierung, die tatsächlich Einsparungen bringt, sieht so aus:

• Neukompilierung für ARM-basierte Prozessoren, die pro gleichwertigem Workload deutlich weniger Strom brauchen.
• Ersatz von VMs durch Container und Serverless-Funktionen, wo es sinnvoll ist.
• Eine gründliche Neugestaltung der Datenschicht, statt sie unverändert mitzunehmen.

So entstehen kostenoptimierte Cloud-Umgebungen: Die Architektur folgt dem Workload, nicht der Vergangenheit.

Dieses Muster erkennt jeder Ingenieur aus der Praxis wieder. Bei den Cloud-Emissionen werden jene Unternehmen vorne liegen, deren Architektur, Beobachtbarkeit und betriebliche Disziplin in dieselbe Richtung zeigen. Die Regulierung ist da. Die Rechnung wird bezahlt. Offen ist nur noch, ob das Team, das den Code schreibt, verstanden hat, dass Watt und Dollar inzwischen dieselbe Zahl in verschiedenen Einheiten sind. Sie möchten mehr über Strategien erfahren, die Cloud-Transformationen mit Geschäftszielen in Einklang bringen? Sprechen Sie mit unserem Team.

FAQ

Was ist die CSRD, und warum ist sie für das Cloud-Computing relevant?

Die Corporate Sustainability Reporting Directive (CSRD) ist eine EU-Richtlinie, die Organisationen verpflichtet, Treibhausgasemissionen aus eingekauften Cloud- und Rechenzentrumsdiensten offenzulegen; sie zählen als vorgelagerte Scope-3-Emissionen. Wer sie ignoriert, riskiert Geldbußen, den Verlust von Fördermitteln und Steuergutschriften, den Ausschluss von öffentlichen Ausschreibungen und die öffentliche Bekanntgabe des Verstoßes.

Warum unterscheidet sich der Energiebedarf von KI-Workloads vom gewöhnlichen Cloud-Computing?

KI-Workloads bilden eine grundlegend andere Kategorie des Energiebedarfs und sind nicht bloß eine Steigerung des Verbrauchs. Eine herkömmliche Cloud-CPU zieht unter Volllast 150–300 Watt, eine moderne GPU für KI-Training dagegen 700 bis über 1.000 Watt pro Chip – und Cluster betreiben Zehntausende dieser Chips gleichzeitig. Das schlägt sich auch in den allgemeinen Trends nieder: Der weltweite Strombedarf von Rechenzentren stieg 2025 um 17 %, der KI-bezogene Verbrauch im selben Jahr sogar um 50 %.

Welche praktischen Schritte können Entwicklerteams gehen, um ihre Cloud-Emissionen zu senken?

Mehrere Maßnahmen verstärken einander, wenn sie zusammenkommen: energieeffiziente Sprachen für Hot-Path-Dienste (kompilierte wie Rust oder Go statt interpretierter), optimierte Datenbankabfragen und Indizierungen, die die CPU entlasten, Echtzeit-Tools für CO₂-Telemetrie wie das Kepler-Projekt sowie der Wechsel zu Serverless- und Container-Architekturen, die auf null skalieren und Leerlaufverschwendung eliminieren.