Sustainability-Prinzipien (SP1–SP7)

Jede Sustainability-Initiative, die nicht auf Messdaten basiert, ist bestenfalls wirkungslos — und schlimmstenfalls Greenwashing. Die Frage "Wie viel CO₂ verursacht dieser Workload?" muss beantwortbar sein, bevor Optimierungsmaßnahmen ergriffen werden.

Cloud-Provider stellen die notwendigen Werkzeuge bereit: AWS Customer Carbon Footprint Tool, Azure Emissions Impact Dashboard, GCP Carbon Footprint. Diese müssen aktiviert, regelmäßig abgefragt und in ESG-Reports integriert werden.

Energieeffizienz und Nachhaltigkeit sind strukturell ausgerichtet. Eine optimierte Lambda-Funktion, die in 100ms statt 500ms läuft, verbraucht 80% weniger Energie. Eine Graviton-Instanz, die die gleiche Last wie eine x86-Instanz bei 30% niedrigerem Energieverbrauch bewältigt, ist sowohl günstiger als auch grüner.

Das bedeutet: Jede Performance-Optimierung, jede Rightsizing-Maßnahme, jede Idle-Elimination ist auch eine Sustainability-Maßnahme — selbst wenn das nicht der primäre Motivator ist.

Gleiche Workloads haben unterschiedliche CO₂-Emissionen je nach Ausführungsort und -zeitpunkt. Ein identischer Batch-Job, der in Stockholm (95% erneuerbare Energie) statt in Hong Kong (hohe Kohleintensität) läuft, kann 60-80% weniger CO₂ emittieren — ohne Codeänderung.

Carbon-aware Architecture bedeutet, Ort (Region) und Zeit (Scheduling-Fenster) als Sustainability-Parameter in Architekturentscheidungen zu integrieren.

Jedes gespeicherte Byte verbraucht Energie — im Hot-Storage-Tier mehr als im Cold-Tier, und mehr über Zeit, wenn keine Lifecycle-Regeln existieren. Jedes über das Netzwerk transferierte Byte verbraucht Netzwerk-Energie.

Das Prinzip der Datenminimierung — ursprünglich aus dem Datenschutz (GDPR Art. 5) — ist zugleich ein Sustainability-Prinzip: Store only what you need, for as long as you need it, in the most efficient tier. Und: übermittele nur die Daten, die der Empfänger tatsächlich benötigt.

Eine EC2-Instanz, die bei 5% CPU-Utilization läuft, verbraucht fast die gleiche Energie wie eine unter 80% Last — aber liefert nur einen Bruchteil des wirtschaftlichen Wertes. Überprovisionierung ist daher eine Form der Energieverschwendung, die durch fehlende Rightsizing-Governance entsteht.

Das Gegenmodell: Ressourcen so dimensionieren, dass die tatsächliche Auslastung den Energieverbrauch rechtfertigt. Autoscaling, Serverless, und Spot-Instanzen sind technische Enabler dieses Prinzips.

Jedes Software-Rewrite verbraucht erhebliche Engineering-Energie: Infrastruktur aufbauen, Parallelentwicklung, Migrations-Compute, Testläufe. Software, die so entworfen ist, dass sie 10 Jahre wartbar und erweiterbar bleibt, ist nachhaltiger als Software, die nach 3 Jahren komplett ersetzt werden muss.

Dieses Prinzip schließt auch Hardware ein: Überengineering, das Hardware-Upgrades erzwingt, ist weniger nachhaltig als ein Design, das auf aktueller Infrastruktur effizient läuft.

Technische Schulden sind bekannte Abweichungen vom Zielzustand, die bewusst toleriert werden. Sustainability Debt ist das Äquivalent für bekannte CO₂-ineffiziente Architekturentscheidungen: x86-Instanzen, die aus Kompatibilitätsgründen noch nicht auf Graviton migriert wurden; S3-Buckets ohne Lifecycle-Policies; Batch-Jobs, die immer noch zu Peak-Zeiten laufen.

Der entscheidende Unterschied zu technischer Schuld: Sustainability Debt ist unter CSRD ein Governance-Risiko. Wenn bekannte Ineffizienzen nicht dokumentiert und adressiert werden, entstehen Lücken in der ESG-Berichterstattung und fehlende Nachweise für aktive Governance — beides Schwachpunkte in CSRD-Prüfungen.