7 Min. Lesezeit

Nachhaltigkeit in der Cloud wird meistens als Marketing-Folie verkauft: grünes Logo, CO2-Kompensation, CSR-Bericht. Die interessante Diskussion spielt sich woanders ab. Carbon-aware Scheduling verschiebt Workloads dahin, wo der Strommix gerade sauber ist oder zeitlich dorthin, wo er es gleich sein wird. Das ist keine Ideologie, sondern eine Architektur-Entscheidung mit konkreten Zahlen, echten Trade-offs und einem Reifegrad, der sich je nach Pattern stark unterscheidet.

VerwandtKI treibt die Cloud – und den Energieverbrauch  /  KI-Inference-Kosten 2026: FinOps für GPU-Workloads

Treiber sind die Green Software Foundation (gegründet 2021 unter dem Dach der Linux Foundation, Mitglieder u. a. Accenture, Microsoft, GitHub, Intel) und eine Reihe von Daten-Providern, die die CO2-Intensität des Netzes regional und in Echtzeit liefern. Die Foundation hat in ihren Patterns drei Hebel herausgearbeitet: Demand Shifting (Location-Shifting und Time-Shifting) und Demand Shaping. Jeder Hebel hat eine andere Wirkung auf Emissionen, Latenz und Kosten. Wer die Unterschiede kennt, trifft bessere Architektur-Entscheidungen. Wer sie vermischt, bekommt ein Greenwashing-Projekt mit CI-Aufwand.

Dieser Artikel ordnet die drei Patterns technisch ein. Er zeigt wo der CO2-Hebel real ist, wo er klein bleibt und was das für Cloud-Architekten heute praktisch bedeutet. .

Was Carbon-aware Scheduling technisch ist

Carbon-aware Scheduling ist die Entscheidung wann und wo ein Workload läuft, getroffen auf Basis eines externen Signals: der CO2-Intensität des Stromnetzes in einer bestimmten Region zu einem bestimmten Zeitpunkt. Die Intensität wird in Gramm CO2-Äquivalent pro Kilowattstunde angegeben. Je höher der Wind- und Solaranteil, desto niedriger der Wert. Je höher der Kohle- oder Gasanteil, desto höher.

Das Signal liefern Dienste wie Electricity Maps oder WattTime über APIs. Typische Granularität sind 5-Minuten- oder Stunden-Intervalle. Das Scheduling selbst geschieht entweder im Cluster (über Kubernetes-Scheduler-Plugins), im CI/CD-System (GitHub Actions hat einen Carbon-aware Build-Modus via Azure-Integration) oder in der Anwendungslogik (Batch-Frameworks, die einen Job-Start verzögern, bis die Intensität unter einem Schwellwert liegt).

Die Green Software Foundation unterscheidet drei praktische Patterns. Sie sind keine Marketingbegriffe, sondern klare Architekturentscheidungen mit unterschiedlicher Wirkung und unterschiedlichen Risiken.

Location-Shifting: den Workload zum sauberen Strom bringen

Location-Shifting verschiebt einen Job in eine Region mit aktuell niedrigerer CO2-Intensität. Technisch ist das die naheliegendste Variante: Cloud-Provider haben ohnehin viele Regionen, die Workload-Definition ist meist region-agnostisch. Die großen Hyperscaler bieten regionale Emissions-Daten inzwischen als Teil ihrer Billing-Exporte an.

Der Hebel ist real, weil die Stromnetze in Europa sehr unterschiedlich zusammengesetzt sind. Ein Batch, der in einer Region mit hohem erneuerbarem Anteil läuft, verursacht deutlich weniger Emissionen als derselbe Batch in einer Region mit fossiler Grundlast. Das ist kein Bilanz-Trick: Strom ist ortsgebunden. Der Netzmix vor Ort bestimmt die tatsächliche Belastung.

Die Grenzen sind handfest. Data-Residency (DSGVO, Sektor-Regulierung, Verträge mit Kunden) kann einen Shift quer durch Europa verbieten. Latenz steigt, wenn Daten oder Nutzer nicht in der Ziel-Region sitzen. Und Inter-Region-Egress-Traffic kostet Geld – bei großen Datenmengen kann die Kostenseite den CO2-Vorteil auffressen, wenn man den Transfer nicht im Griff hat.

Am belastbarsten ist Location-Shifting dort, wo Daten bereits multiregional vorliegen: Trainings-Datensätze in Object Storage, die ohnehin repliziert werden. Oder Workloads ohne Persistenz: stateless Batch-Rechnungen, die nur Inputs lesen und Ergebnisse zurückschreiben.

Time-Shifting: den Workload in die saubere Stunde bringen

Time-Shifting belässt den Workload in seiner Region, verschiebt aber den Startzeitpunkt in ein Fenster mit niedrigerer Intensität. Der typische Fall: ein Nightly Build oder ein ML-Training, das heute Nacht um 2 Uhr startet, weil dann der Anteil an Windstrom im Netz hoch ist. Oder das eben erst um 4 Uhr startet, weil die aktuelle Intensitäts-Prognose das empfiehlt.

Technisch ist das meist einfacher als Location-Shifting: keine Netzwerk-Effekte, keine Residency-Fragen. Ein Scheduler-Plugin oder ein Poll-basierter Cron-Wrapper ruft die Intensitäts-API ab und triggert den Job, wenn der Schwellwert unterschritten ist. Kubernetes-Projekte wie der Carbon-Aware KEDA-Scaler oder Google Cloud’s Batch mit Carbon-Sensitivity-Flag gehen in genau diese Richtung.

Die Grenze ist die Verzögerungs-Toleranz. Ein CI-Build, der vier Stunden wartet, blockiert keinen Release – aber ein Log-Ingestion-Job, der sechs Stunden wartet, verletzt Compliance-Anforderungen (GDPR-Deadlines, Audit-Trails). Wer Time-Shifting ernsthaft betreibt, muss pro Workload definieren, wie viel Delay akzeptabel ist. Sonst entsteht eine zweite Klasse von „irgendwann-läuft-es“-Jobs, die niemand mehr debuggt.

„Nachhaltigkeit in der Cloud wird meistens als Marketing-Folie verkauft: grünes Logo, CO2-Kompensation, CSR-Bericht.“

Demand-Shaping: weniger rechnen, wenn der Strom schmutzig ist

Demand-Shaping ist das anspruchsvollste Pattern. Statt den Workload zu verschieben, passt die Anwendung ihren Ressourcenbedarf an das Signal an. Beispiele: ein Video-Encoder wählt bei hoher CO2-Intensität ein schwächeres Preset, eine Empfehlungs-Pipeline reduziert die Tiefe ihres Modells, ein Analytics-Job berechnet grobere Aggregate.

Der Charme: Demand-Shaping funktioniert auch für latenzkritische Anwendungen, die weder warten noch umziehen können. Der Preis: die Anwendung muss den Trade-off explizit modellieren. Das ist kein Infrastruktur-Thema mehr, sondern ein Produkt-Thema. Ein Team, das sein Video-Encoding bei schlechtem Strommix in „Standard statt High“ umstellt, muss das Ergebnis gegenüber dem Kunden verantworten. Wer das nicht kommuniziert, riskiert Support-Tickets.

Trade-offs: was sich gegen Carbon-aware Scheduling spricht

Carbon-aware Scheduling ist kein kostenloses Mittagessen. Die Patterns kollidieren mit anderen Architektur-Zielen. Diese Kollisionen sind nicht theoretisch. Wer das nicht früh klar bekommt, baut sich Technical Debt ein, der unter dem Label „Nachhaltigkeit“ schwerer zu diskutieren ist als gewöhnliche Komplexität.

Pilot: wie ein Einstieg realistisch aussieht

Die Versuchung ist groß, Carbon-aware Scheduling als Plattform-Initiative aufzusetzen. Das ist selten sinnvoll. Der bessere Pfad ist ein enger Pilot, der ein echtes Ergebnis produziert, bevor Richtlinien geschrieben werden.

1. Kandidaten identifizieren. Welche Workloads tolerieren Verzögerung von mehreren Stunden? Typisch: Nightly Builds, ML-Trainings, Log-Transformationen, Analytics-Rollups. Keine User-facing Services, keine synchronen Pipelines.
2. Signal-Quelle wählen und prüfen. Electricity Maps und WattTime sind etablierte Anbieter, die Hyperscaler haben eigene APIs. Einmal pro Tag die Werte gegen die Provider-Rechnung checken, bis das Signal verlässlich wirkt.
3. Einen Workload wirklich schedulen. Nicht „Konzept“, sondern ein Job, der im Produktions-Scheduler hängt und verzögert oder regional wechselt. Vier Wochen messen: Laufzeit, Kosten, CO2, Ausfälle.
4. Messbarkeit von Anfang an. Vorher-nachher-Vergleich im gleichen Dashboard, in dem auch Kosten und SLOs stehen. Wenn die CO2-Zahl nur im Nachhaltigkeitsbericht auftaucht, wird sie nicht betrieben.
5. Erst danach skalieren. Wenn der Pilot ein Muster zeigt, das reproduzierbar ist, in die Plattform-Schicht heben – als Scheduler-Option, nicht als Pflicht.

Was bleibt schwierig

Die größte offene Flanke ist Attribution. Cloud-Provider melden Emissionen pro Region, aber selten pro Job oder Service. Wer wissen will, wie viel CO2 ein konkreter Microservice über einen Sprint verursacht hat, muss selbst rechnen – mit Stromintensität, Laufzeit, Auslastung und Annahmen über die Power Usage Effectiveness des Rechenzentrums. Das ist machbar, aber es ist Engineering-Arbeit und kein Dashboard-Klick. In der Praxis bedeutet das: ein internes Telemetrie-Modell, das Laufzeit-Metriken aus dem Scheduler mit regionalen Intensitäts-Kurven verrechnet und Ergebnisse pro Team oder Service aggregiert. Teams ohne ein solches Modell landen bei Schätzungen, die sich schwer gegenüber Kunden oder Audit-Prozessen vertreten lassen.

Ein weiterer Punkt wird oft unterschätzt: die Betriebs-Verantwortung für den Scheduler selbst. Wenn der Carbon-Signal-Feed ausfällt, muss klar sein, was passiert – stoppt der Job, läuft er sofort, wartet er auf Timeout. Ohne definierten Fallback entstehen stille Ausfälle. Carbon-aware Scheduling braucht die gleiche Rigidität im Incident-Management wie jeder andere Produktions-Scheduler, sonst wird es zum Schatten-System neben dem eigentlichen Cron- oder Kubernetes-Betrieb.

Die zweite offene Flanke ist die Signal-Qualität. Prognosen für die nächsten Stunden sind genauer geworden, aber nicht exakt. Wer einen Scheduler baut, der bei jedem Mini-Spike im Grid-Mix reagiert, wird instabile Job-Starts bekommen. Pragmatischer ist eine einfache Regel: verzögere bis zum nächsten Fenster unter einem Schwellwert, sonst starte nach maximaler Wartezeit trotzdem. Keine Optimierung zweiter Ordnung, keine ML-Prognose auf die Prognose.

Und schließlich die ehrlichste Grenze: Carbon-aware Scheduling reduziert die Emissionen der verschobenen Workloads. Es reduziert nicht die absolute Stromnachfrage. Wer ernsthaft über Nachhaltigkeit in der IT sprechen will, kommt an Effizienz-Themen nicht vorbei: weniger Daten bewegen, schlankere Modelle, saubere Retention-Policies, bewusster Umgang mit idle Infrastruktur. Scheduling ist ein Hebel, nicht die Antwort.

Empfehlung

Für Teams, die viele Batch-Workloads betreiben, lohnt sich Time-Shifting als erster Schritt: geringe Komplexität, belastbare Einsparung, keine Residency-Fallen. Location-Shifting ist interessant, wenn Multi-Region ohnehin etabliert ist und die Daten es zulassen – ansonsten wird es schnell teuer. Demand-Shaping lohnt sich für ein paar gut gewählte Produkte mit latenzkritischen, rechenintensiven Anteilen, aber nicht als Querschnitts-Initiative.

Wer Carbon-aware Scheduling als Architektur-Thema behandelt, bekommt es in die Diskussionen, in die es gehört: zu Region-Auswahl, Scheduler-Design, Daten-Layout. Wer es als Kommunikations-Thema behandelt, baut ein Label, das wenig bewegt. Die Patterns der Green Software Foundation sind kein Manifest – sie sind ein Vokabular, mit dem sich diese Entscheidungen sauber treffen lassen.

Häufige Fragen

Brauche ich ein spezielles Tool für Carbon-aware Scheduling?

Nein. Für einen Pilot reicht ein Cron-Wrapper, der eine Intensitäts-API abfragt und den Job-Start verzögert. Plattform-Features wie KEDA-Carbon-Scaler oder Provider-eigene Batch-Modi sind sinnvoll, sobald mehrere Workloads koordiniert werden sollen.

Wie verlässlich sind die Emissions-Signale?

Für den aktuellen Netz-Mix in den meisten europäischen Regionen gut. Prognosen über mehrere Stunden sind brauchbar, aber nicht exakt. Wer auf Minuten-Prognosen optimiert, riskiert instabiles Scheduling. Robuster: Schwellwerte und maximale Wartezeiten kombinieren.

Konflikt mit Data-Residency – wie geht man damit um?

Location-Shifting nur innerhalb eines rechtlich freigegebenen Region-Clusters. Residency-Vorgaben sind meist stärker als jede Carbon-Regel – daher vorab mit Data Privacy und Compliance abstimmen, bevor ein Scheduler Regionen auswählen darf.

Lohnt sich Carbon-aware Scheduling finanziell?

Oft neutral bis leicht positiv: Zeiten niedriger CO2-Intensität überschneiden sich häufig mit Off-Peak-Stromtarifen und Spot-Instance-Verfügbarkeit. Bei Location-Shifting kann Egress-Traffic den Effekt auffressen – daher immer mit Netzwerk-Kosten rechnen.

Was eignet sich definitiv nicht für Carbon-aware Scheduling?

Synchrone, user-facing APIs. Transaktionale Systeme mit harten Latenz-Budgets. Workloads mit SLA-gebundenen Reaktionszeiten. Hier bleibt Demand-Shaping der einzige Pfad – und der ist ein Produkt-Thema, keine Infrastruktur-Entscheidung.

Quelle Titelbild: Pexels / Alfo Medeiros (px:15418504)