Bildquelle: Pexels / Foto-ID 433308 / Solarfeld und Windrad als Motiv für Strommix, Energieort und Green-IT-Entscheidung / https://www.pexels.com/photo/433308/
Cloud-Regionen wirken im Freigabealltag oft wie eine technische Auswahl: kurze Wege, passende Funktionen, akzeptable Kosten. Für Green IT reicht diese Sicht nicht mehr. Der Ort, an dem Rechenleistung tatsächlich Strom verbraucht, gehört in dieselbe Entscheidung wie Latenz, Ausfallsicherheit und Datenschutz.
Green IT meint nicht nur sparsame Geräte oder weniger Ausdrucke. Für ITSM-Generalisten geht es um die Frage, wie digitale Dienste mit Energie, Ressourcen und Betriebsverantwortung umgehen. Bei Cloud-Diensten ist dafür wichtig, in welcher Region Workloads laufen, wie transparent der Anbieter zum Strommix berichtet und ob die Organisation diese Information vor dem Go-live bewusst bewertet.
Die Region ist mehr als eine technische Zone
Eine Cloud-Region wird häufig nach Nähe zum Nutzer, vorhandenen Diensten, Datenresidenz und Preis gewählt. Diese Kriterien bleiben richtig. Sie beantworten aber nicht vollständig, welche Umweltwirkung der Dienst im Betrieb hat. Rechenzentren brauchen Strom für Server, Speicher, Netzwerk und Kühlung. Wenn ein Dienst dauerhaft hohe Last erzeugt, wird der Stromort zu einer Betriebsgröße.
Für den Servicebetrieb entsteht daraus eine einfache, aber ungewohnte Prüffrage: Warum läuft dieser Dienst genau dort? Die Antwort darf nicht nur lauten, dass die Region im Standardtemplate stand. Sie sollte erklären, welche fachliche Anforderung die Region trägt, welche Alternativen geprüft wurden und ob ein Standort mit besserer Energie- oder Emissionsbilanz technisch vertretbar gewesen wäre.
Nachhaltigkeit darf nicht erst nach dem Go-live beginnen
Viele Organisationen sprechen über Nachhaltigkeit in Berichten, Portfoliorunden oder Architekturleitlinien. In der konkreten Cloud-Freigabe taucht sie dann aber zu spät auf. Ist ein Dienst erst produktiv, werden Region, Datenhaltung, Integrationen und Überwachungswege selten ohne Aufwand geändert. Wer den Stromort erst nach dem Go-live prüft, macht Green IT zu einer nachträglichen Rechtfertigung statt zu einem Steuerungskriterium.
Darum gehört die Frage in den normalen Freigabeprozess. Der Change oder das Architekturboard muss nicht selbst zum Energiemarkt-Experten werden. Es reicht ein klarer Mindestnachweis: Welche Region ist geplant, welche Hauptgründe sprechen dafür, welche Anbieterinformationen zum Energie- oder Emissionsprofil liegen vor und welche Einschränkungen verhindern eine bessere Alternative?
Anbieterberichte ersetzen keine eigene Entscheidung
Große Cloud-Anbieter veröffentlichen Nachhaltigkeitsinformationen, regionale Emissionshinweise oder Programme zur Nutzung erneuerbarer Energie. Diese Angaben sind hilfreich, aber sie nehmen dem Kunden die Entscheidung nicht ab. Ein allgemeines Nachhaltigkeitsversprechen des Anbieters beantwortet noch nicht, ob der konkrete Workload in der gewählten Region sinnvoll liegt.
ITSM sollte deshalb zwischen Anbieterstrategie und Dienstentscheidung unterscheiden. Anbieterstrategie beschreibt, wohin der Provider insgesamt will. Die Dienstentscheidung beschreibt, warum ein bestimmter Service mit bestimmter Last, bestimmter Verfügbarkeit und bestimmtem Datenbedarf an einem bestimmten Ort betrieben wird. Nur der zweite Blick hilft im Betrieb, wenn Kosten, Kapazität oder Nachhaltigkeitsziele später gegeneinander abgewogen werden.
Der Stromort steht neben Risiko und Kosten
Green IT wird stärker, wenn sie nicht als Sonderprüfung neben dem Betrieb steht. Der Stromort sollte neben bekannten Kriterien auftauchen: Datenschutz, Latenz, Ausfallsicherheit, Kosten, Supportfähigkeit und Wiederanlauf. Manchmal gewinnt eine Region trotz schlechterer Energiewerte, weil rechtliche oder technische Gründe schwerer wiegen. Dann ist die Entscheidung nicht automatisch falsch. Sie muss nur bewusst und nachvollziehbar sein.
Genau diese Nachvollziehbarkeit fehlt oft. Ein Projekt kann sauber kalkuliert sein und trotzdem keine Antwort auf die Energiefrage haben. Ein Dienst kann technisch stabil laufen und trotzdem unnötig weit entfernt oder in einer ungünstigen Region betrieben werden. Ohne dokumentierte Abwägung merkt das Team erst bei Kosten- oder Nachhaltigkeitsreporting, dass die Entscheidung nie wirklich getroffen wurde.
Welche Informationen in die Freigabe gehören
Ein praktikabler Prüfblock muss kurz bleiben. Er sollte den Dienstnamen, die geplante Cloud-Region, die erwartete Lastklasse, die Datenresidenz-Anforderung, die Latenzanforderung, die wichtigste technische Abhängigkeit und eine kurze Energieeinordnung enthalten. Dazu gehört auch, ob der Anbieter regionale Emissionsdaten oder Nachhaltigkeitsinformationen bereitstellt und wann diese zuletzt geprüft wurden.
Für kritische oder besonders laststarke Dienste lohnt eine zusätzliche Frage: Gibt es eine technisch gleichwertige Region mit besserem Nachhaltigkeitssignal? Wenn ja, warum wurde sie gewählt oder verworfen? Wenn nein, welche Maßnahme reduziert den Verbrauch an anderer Stelle, etwa Abschaltzeiten für Testumgebungen, saubere Skalierung, Speicherbereinigung oder ein Lifecycle-Termin für nicht mehr benötigte Ressourcen?
Service Owner brauchen eine verständliche Entscheidung
Die Energiefrage darf nicht im Architekturdokument verschwinden. Service Owner, FinOps, Security und Betrieb brauchen eine gemeinsame Kurzfassung. Sie muss erklären, welche Region genutzt wird, welcher Zielkonflikt geprüft wurde und wann die Entscheidung erneut angesehen wird. So kann der Dienst später verändert werden, ohne wieder bei Null zu beginnen.
Für ITSM ist der Nutzen konkret. Eine dokumentierte Cloud-Freigabe verhindert, dass Nachhaltigkeit nur als Jahresbericht existiert. Sie verbindet Energie, Kosten und Betrieb an der Stelle, an der der Dienst wirklich entsteht. Der Stromort wird damit nicht zum alleinigen Entscheidungskriterium. Er wird zu einer sichtbaren Frage, die vor dem Go-live beantwortet werden muss.
Quellen und Einordnung: International Energy Agency zu Data Centres and Data Transmission Networks, Google Cloud zu regionalen Carbon-Informationen, Microsoft Cloud Adoption Framework zur Nachhaltigkeit, AWS Nachhaltigkeitsinformationen. Stand der Quellenprüfung: 15.07.2026. Bildquelle: Pexels, Foto-ID 433308.