Carbon-bewusste SaaS-Architektur: Was CSRD und Green-Procurement-Fragen tatsächlich verlangen
In der Enterprise-Beschaffung hat sich 2025 etwas verschoben. Neben den üblichen Fragen zu Uptime-SLAs, SOC-2-Status und DSGVO-Datenverarbeitungsverträgen enthielten Anbieterfragebögen plötzlich einen neuen Abschnitt: Umweltauswirkungen. Scope-3-Emissionen. Software Carbon Intensity Scores. Jahresverbrauchsschätzungen in GWh.
Fur die meisten SaaS-Anbieter kam das uberraschend. Carbon-bewusste SaaS-Architektur war ein Nischenthema auf Green-Computing-Konferenzen - nichts, was einen Deal mit einem deutschen Maschinenbauunternehmen oder einer britischen Finanzdienstleistungsfirma blockieren wurde. Das änderte sich, als CSRD-Meldepflichten mitteleuropäische Unternehmen zu treffen begannen und die erste Welle von Lieferkettenemissions-Datenanfragen in Postfächern landete.
Dieser Beitrag behandelt, was tatsächlich gefordert wird, wie die Engineering-Seite funktioniert und was Enterprise-Käufer realistischerweise als Nachweis akzeptieren, wenn sie diese Fragen stellen.
Warum Beschaffungsteams nach deinem CO2-Fußabdruck fragen
Die Corporate Sustainability Reporting Directive (CSRD) verpflichtet große EU-Unternehmen - und ab 2026 viele mittelgroße - zur Offenlegung von Scope-3-Emissionen in ihren Nachhaltigkeitsberichten. Scope 3, Kategorie 1 umfasst zugekaufte Waren und Dienstleistungen. Das schließt SaaS-Abonnements ein.
Fur einen Beschaffungsmanager eines deutschen Herstellers mit 5.000 Mitarbeitern, der seinen ESRS-E1-Offenlegungen nachkommen muss, ist deine Software eine Zeile in seiner Lieferkettenemissionsinventur. Wenn du keine Daten liefern kannst, schließen sie dich entweder aus der Lieferantenliste aus, weisen einen konservativen Schätzwert zu (der fur ihre Offenlegungen schlechter sein kann als dein tatsächlicher Fußabdruck) oder wählen einfach einen Anbieter, der die Frage beantworten kann.
Der Geschäftsdruck ist real und wächst. Er beschränkt sich nicht auf große Unternehmen - da CSRD durch Lieferketten kaskadiert, erhalten auch mittelständische Käufer dieselben Fragen von ihren Kunden und leiten sie weiter.
Die Software Carbon Intensity Specification
Der praktische Ausgangspunkt ist die Software Carbon Intensity (SCI) Specification der Green Software Foundation. Sie bietet eine standardisierte, auditierbare Formel:
SCI = (E × I) + M pro R
Dabei ist:
- E = vom Softwaresystem verbrauchte Energie (kWh)
- I = Kohlenstoffintensität des Stromnetzes (gCO₂eq/kWh)
- M = embodied carbon aus Hardware
- R = funktionale Einheit (pro API-Aufruf, pro aktivem Nutzer, pro Transaktion - du wählst und dokumentierst sie)
Der SCI-Score zeigt dir, wie kohlenstoffintensiv deine Software relativ zur geleisteten Arbeit ist. Im Gegensatz zu einer rohen Emissionszahl ist er skalenunabhängig, was ihn fur Anbietervergleiche geeignet macht.
Fur die meisten SaaS-Anwendungen, die auf großen Cloud-Anbietern laufen, beginnt die Berechnung von E mit deinen Cloud-Abrechnungsdaten und den vom Anbieter veröffentlichten Power Usage Effectiveness (PUE)- und Energiedaten. AWS veröffentlicht Kohlenstoffintensitätsdaten auf Regions-Ebene. Google Cloud hat seit Jahren CO2-freie Energieprozentsätze nach Region. Das Emissions-Impact-Dashboard von Azure stellt diese Daten programmgesteuert per API bereit.
Die embodied-carbon-Komponente (M) deckt die beim Herstellen und Entsorgen der physischen Hardware emittierte Kohlenstoffmenge ab. Fur Cloud-gehostete Software kannst du veröffentlichte Cloud-Anbieter-Zahlen oder das Open-Source-Tool Cloud Carbon Footprint verwenden, das Abrechnungsdaten von AWS, GCP und Azure abruft und Emissionsschätzungen einschließlich embodied carbon berechnet.
Was Enterprise-Beschaffungsteams typischerweise als Nachweis akzeptieren: einen SCI-Score mit dokumentierter Methodik, den verwendeten Datenquellen und idealerweise einem Jahresvergleich. Sie erwarten kein Drittparteien-Audit von Anfang an. Eine glaubwurdige Selbsteinschätzung mit sichtbarer Methodik genugt fur die meisten Deals.
Regionsauswahl fur emissionsärmere Workloads
Die Kohlenstoffintensität von Strom variiert je nach Geografie erheblich, und Cloud-Anbieter legen dies auf Regions-Ebene offen. Die grünsten großen Cloud-Regionen sind typischerweise jene mit Zugang zu erheblicher Wasser- oder Kernkraftkapazität: Stockholm, Oslo, Zurich, Oregon und Teile Kanadas.
Fur eine europäische SaaS-Anwendung ist die Wahl der richtigen Primärregion wichtig. Wenn deine Datenschutzanforderungen es erlauben - und viele DSGVO-konforme Anwendungen können in eu-west-2 (London), eu-north-1 (Stockholm) oder eu-central-1 (Frankfurt) hosten - gibt es einen bedeutenden Unterschied in der Netzkohlenstoffintensität zwischen diesen Optionen.
Manche Teams gehen weiter und implementieren dynamische Regionsauswahl fur Workloads ohne strenge Latenzanforderungen. Hintergrundverarbeitungsjobs, Berichtserstellung, ML-Inferenz und Datenexporte sind allesamt Kandidaten fur Carbon-Aware-Scheduling.
Die Electricity Maps API ermöglicht es dir, aktuelle und 24-Stunden-prognostizierte Kohlenstoffintensität nach Region abzufragen. Eine einfache Implementierung sieht so aus:
- Definiere eine Menge zulässiger Regionen, in denen dein Workload laufen darf.
- Frage bei der Job-Weiterleitung die Kohlenstoffintensität fur jede Region ab.
- Leite den Job in die emissionsärmste verfugbare Region, vorbehaltlich einer maximalen akzeptablen Latenz-Schwelle.
- Protokolliere die gewählte Region und die Kohlenstoffintensität zum Weiterleitungszeitpunkt - das fließt in deine SCI-Berechnung ein.
Das ist nicht komplex in einem Hintergrundjob-System zu implementieren. Wenn du Symfony Messenger verwendest, kannst du eine Middleware hinzufugen, die Nachrichten vor dem Weiterleiten an einen Remote-Queue-Consumer mit einem Zielregion-Hinweis anreichert.
Carbon-Aware-Scheduling fur Hintergrundjobs
Regionsrouting ist ein Hebel. Zeitverschiebung ein anderer. Netzkohlenstoffintensität folgt vorhersehbaren täglichen und wöchentlichen Mustern in den meisten Märkten. Solarenergie-lastige Netze wie das deutsche sind an Wochentagen mittags am saubersten und fruhmorgends vor dem Hochfahren der Solarenergie am schmutzigsten. Wind-lastige Netze wie das britische sind variabler.
Fur Workloads mit flexiblem Timing - nächtliche ETL-Jobs, wöchentliche Berichtserstellung, Cache-Warming, ML-Retraining - kannst du sie in Niedrig-Kohlenstoff-Fenster planen statt zu einer festen Zeit.
Das Carbon-Aware-SDK der Green Software Foundation stellt Libraries fur dieses Muster bereit. Du ubergibst ein Zeitfenster und eine gewunschte Ausfuhrungsdauer, und das SDK fragt die Electricity-Maps-Prognose ab, um den emissionsärmsten Slot in deinem Fenster vorzuschlagen.
Das Geschäftskalkul ist doppelt: Es reduziert deine tatsächlichen Emissionen und gibt dir eine echte Engineering-Geschichte fur Beschaffungsfragebögen. "Wir planen nicht zeitkritische Batch-Jobs in Niedrig-Kohlenstoff-Netzfenstern" ist spezifisch, glaubwurdig und unterscheidet dich von Anbietern, die einfach die Nachhaltigkeitsseite ihres Cloud-Anbieters umformuliert haben.
Was in eine Anbieter-Nachhaltigkeitsantwort gehört
Wenn ein Enterprise-Beschaffungsteam dir einen Nachhaltigkeitsfragebogen schickt, arbeiten sie meist mit einem von wenigen Standard-Frameworks: EcoVadis, CDP (ehemals Carbon Disclosure Project) oder einer intern entwickelten Vorlage nach ISO-14001-Grundsätzen. Die Fragen sind konsistenter als sie erscheinen.
Das wollen sie tatsächlich wissen - und wie du jede Kategorie beantwortest:
Scope-3-upstream-Emissionsmethodik. Sie wollen wissen, wie du den Beitrag deiner Software zu ihrer Scope-3-Inventur schätzt. Dein SCI-Score, das Methodikdokument und das verwendete Tool (z.B. Cloud Carbon Footprint) ist eine vollständige Antwort.
Energieverbrauch. Gesamte kWh, die deine Infrastruktur pro Jahr verbraucht, nach Region aufgeschlusselt wenn möglich. Hol diese Daten aus deinen Cloud-Abrechnungsdaten.
Erneuerbare-Energie-Zertifikate oder matched clean energy. Kaufst du RECs, EU-GOs (Herkunftsnachweise) oder profitierst du von den Power-Purchase-Agreements deines Cloud-Anbieters? Beachte, dass RECs marktbasiert sind und nicht garantieren, dass deine Workloads auf sauberem Strom liefen - versierte Käufer kennen diesen Unterschied.
CO2-Reduktionsziele. Hast du ein Science-Based-Target (SBT) oder eine ähnliche Verpflichtung gemacht? Wenn nicht, ist ein dokumentiertes internes Ziel mit einem Basisjahr auf KMU-Ebene ein vernunftiger Ersatz.
Infrastruktureffizienz. Fragen zu Virtualisierung, Serverless oder Container-Nutzung, Auto-Scaling (Reduktion ungenutzter Ressourcen) und CDN-Nutzung fließen alle ein. Die meisten modernen SaaS-Architekturen machen diese Dinge bereits - die Frage ist, ob du sie dokumentiert hast.
Wenn du an einem Custom-Software-Development oder Legacy-Code-Optimierung Projekt arbeitest, das eine Infrastruktur-Neugestaltung umfasst, ist jetzt der richtige Zeitpunkt, diese Praktiken einzubauen statt sie später nachzurusten.
Praktische Implementierungsprioritäten
Wenn du bei null anfängst, ist das eine sinnvolle Reihenfolge:
Erstens: Messen. Fuhre Cloud Carbon Footprint gegen deine Abrechnungsdaten aus und ermittle eine Ausgangszahl. Das dauert ein paar Stunden und kostet nichts. Du hast jetzt eine Zahl zum Melden und einen Ausgangspunkt fur Reduktionen.
Zweitens: Methodik dokumentieren. Schreibe ein einseitiges Dokument, das beschreibt, wie du deinen SCI-Score berechnet hast, welche Datenquellen du verwendet hast und was deine funktionale Einheit ist. Das ist es, was Beschaffungsteams tatsächlich sehen wollen.
Drittens: Wähle die emissionsärmste Region, die deine Datenschutzanforderungen erlauben. Fur EU-Kunden mit DSGVO-Anforderungen ist eu-north-1 (Stockholm) häufig deutlich sauberer als eu-central-1 (Frankfurt). Prufe aktuelle Zahlen, bevor du Annahmen triffst.
Viertens: Implementiere Carbon-Aware-Scheduling fur deine energieintensivsten Hintergrundjobs. Beginne mit den höchstenergetischen Workloads - ML-Jobs, große Batch-Exporte, Full-Table-Analytics-Abfragen.
Funftens: Monitoring hinzufugen. Exportiere Carbon-Metriken in deinen Observability-Stack neben CPU, Arbeitsspeicher und Latenz. Das hält die Daten fur die Jahresberichterstattung aktuell.
Die ehrlichen Grenzen der aktuellen Praxis
Einige Punkte, die klar sein sollten:
Carbon-Aware-Scheduling reduziert Emissionen, eliminiert sie aber nicht. Fur Anwendungen mit strengen Latenzanforderungen - interaktive APIs, Echtzeit-Features, alles Nutzerorientierte - kann die Arbeit nicht zeitlich verschoben werden. Carbon-Awareness hilft primär bei Hintergrund- und Batch-Workloads.
RECs und Kohlenstoff-Offsets sind tatsächlich umstritten. Die Science-Based-Targets-Initiative erlaubt es nicht mehr, Offsets fur kurzfristige Ziele anzurechnen. Versierte Käufer wissen das. Wenn deine Nachhaltigkeitsposition hauptsächlich auf gekauften Offsets basiert, wird das wahrscheinlich Scrutiny auf sich ziehen.
Die Datenqualität fur embodied carbon ist noch schlecht. Cloud-Anbieter veröffentlichen Schätzungen, aber die Methoden variieren und die Zahlen ändern sich, wenn Hardwaregenerationen wechseln. Berichte, was du hast, und sei ehrlich uber die Genauigkeit.
Erste Schritte
Wenn du ein SaaS-Produkt hast und diese Fragen in der Beschaffung zu sehen beginnst, ist die Priorität Messung und Dokumentation. Eine glaubwurdige, methodisch fundierte SCI-Berechnung, auf die du in einem Anbieter-Fragebogen verweisen kannst, ist mehr wert als Absichtserklärungen, die du mit Daten nicht unterstutzen kannst.
Fur Teams, die Carbon-Awareness in eine neue Architektur oder ein Code-Modernisierungsprojekt einbauen, sind die Engineering-Muster - Carbon-Aware-Scheduling, Routing in emissionsarme Regionen, Infrastruktureffizienz - gut etabliert und werden zunehmend durch Cloud-Anbieter-Tooling unterstutzt.
Wenn du besprechen möchtest, wie eine Carbon-Aware-Architektur-Bewertung fur dein System aussehen wurde, erreichst du uns unter hello@wolf-tech.io oder uber wolf-tech.io.
Häufig gestellte Fragen
Brauche ich ein Drittparteien-Audit, um CSRD-bezogene Beschaffungsfragen zu beantworten? Auf Anbieterebene noch nicht. Käufer fragen nach deinen selbst gemeldeten Daten und deiner Methodik. Drittparteien-Verifizierung ist fur die eigenen CSRD-Offenlegungen des Kaufunternehmens erforderlich, aber fur Anbieterfragebögen genugt eine dokumentierte Selbsteinschätzung im Allgemeinen.
Welche Cloud-Regionen sind fur EU-basiertes SaaS am emissionsärmsten? Das ändert sich mit den Netzbedingungen, aber eu-north-1 (Stockholm) rangiert aufgrund Schwedens Wasser- und Kernkraftmix konstant unter den saubersten. eu-west-1 (Irland) profitiert von erheblicher Windenergie. eu-central-1 (Frankfurt) und eu-west-3 (Paris) variieren stärker saisonal. Prufe Electricity Maps oder die Nachhaltigkeits-Dashboards deines Cloud-Anbieters fur aktuelle Zahlen.
Ist die SCI-Specification fur die CSRD-Compliance obligatorisch? Nein. CSRD schreibt nicht speziell die SCI-Specification vor. Sie erfordert Scope-3-Emissionsberichterstattung, und SCI ist eine nutzliche Methodik zur Berechnung des Softwarebeitrags dazu. Du könntest andere Methoden verwenden, aber SCI wird zunehmend zum Branchenstandard fur softwarespezifische Emissionsberechnungen.
Was ist der Unterschied zwischen standortbasierter und marktbasierter Emissionsrechnung? Standortbasierte Rechnung verwendet die durchschnittliche Kohlenstoffintensität des Netzes, in dem sich deine Server befinden. Marktbasierte Rechnung berucksichtigt Erneuerbare-Energie-Zertifikate oder Power-Purchase-Agreements. Beide sollten berichtet werden. Versierte Käufer - insbesondere jene, die nach GHG-Protocol-Scope-3-Leitlinien arbeiten - werden beide Zahlen anfragen.
Kann Carbon-Aware-Scheduling unsere SLA-Verpflichtungen gefährden? Nur wenn es auf latenzempfindliche Workloads angewendet wird, was es nicht sollte. Carbon-Aware-Scheduling ist fur Hintergrundjobs, Batch-Verarbeitung und nicht dringende Rechenaufgaben geeignet, bei denen du zeitlich flexibel bist. Nutzerorientierte Anfragen sollten nicht auf Basis der Kohlenstoffintensität geroutet werden.