WAF++ WAF++
Back to WAF++ Homepage

WAF-SUS-030 – Green Region & Carbon-Aware Workload Placement

Pillar: Sustainability | Severity: Medium | Kategorie: Region Selection | Automatisierbar: Mittel

Beschreibung

Workloads ohne strikte Data-Residency-Anforderungen MÜSSEN Carbon Intensity von Cloud-Regionen in Placement-Entscheidungen berücksichtigen. Architekturentscheidungen (ADRs) MÜSSEN Carbon-Impact als expliziten Faktor dokumentieren. Batch-Workloads mit flexiblem Placement MÜSSEN grüne Regionsalternativen evaluieren. Wenn ein identischer Workload in Stockholm statt Hong Kong deployed wird, kann er 60–80% weniger CO₂ emittieren — ohne Code-Änderung.

Rationale

Cloud-Regionen unterscheiden sich erheblich in ihrer Energie-Zusammensetzung. eu-north-1 (Stockholm) hat ~95% erneuerbare Energie (~10 gCO₂eq/kWh), während ap-east-1 (Hong Kong) ~25% erneuerbare Energie (~500 gCO₂eq/kWh) hat. Ohne Dokumentation dieser Entscheidungen entsteht ein Carbon-Footprint, der weder verstanden noch für CSRD-Berichterstattung begründbar ist.

Bedrohungskontext

Risiko Beschreibung

Unnötige Scope-3-Emissionen

Workloads in hohe-Kohlenstoff-Regionen emittieren 50–80% mehr als gleiche Workloads in grünen Regionen.

CSRD-Governance-Gap

Fehlende Dokumentation der Carbon-Berücksichtigung in Architekturentscheidungen ist ein Governance-Gap für ESG-Audits.

SBTi Scope-3-Zielverfehlung

Region-Auswahl beeinflusst maßgeblich das erreichbare SBTi-Ziel — undokumentierte Hochkohlenstoff-Deployments gefährden Ziele.

Anforderung

  • Region-Auswahl-Entscheidungen MÜSSEN Carbon Intensity als dokumentierten Faktor enthalten

  • ADR-Template SOLL einen Carbon-Impact-Abschnitt enthalten

  • Grüne Regionen SOLLEN als Default bevorzugt werden, wenn Compliance und Latenz es erlauben

  • Batch-Workloads mit flexiblem Placement MÜSSEN grüne Regionen evaluieren

  • Abweichungen von grünen Regionen MÜSSEN dokumentiert und begründet werden

Implementierungsanleitung

  1. Cloud-Provider-Sustainability-Seiten konsultieren: AWS, Azure, GCP veröffentlichen Energie-Mix pro Region

  2. Regionsauswahl-ADR-Template erweitern: Carbon-Intensity-Sektion zu Architecture Decision Records hinzufügen

  3. Terraform-Validation: variable "aws_region" mit validation-Block auf genehmigte grüne Regionen beschränken

  4. Batch-Workloads prüfen: Alle Batch-Jobs ohne Residency-Anforderung auf grüne Regionen umplanen

  5. Carbon-Aware-Routing: Für fortgeschrittene Teams: electricityMaps API für dynamisches Regionsrouting

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Keine Berücksichtigung

Region nach Kosten/Latenz; Carbon nicht betrachtet; kein ADR-Requirement.

2

Informelles Bewusstsein

Team kennt Carbon-Intensitäts-Unterschiede; informelle Berücksichtigung bei Neudeployments.

3

ADR-Dokumentiert

Architecture Decision Template mit Carbon-Sektion; grüne Regionen als Präferenz dokumentiert.

4

Carbon-Aware Placement

Batch-Workloads aktiv in grüne Regionen; Carbon-API-Integration evaluiert oder aktiv.

5

Dynamic Carbon Routing

Echtzeit-Carbon-Intensity für Workload-Routing; RECs/PPAs für alle deployed Regionen.

Terraform Checks

waf-sus-030.tf.aws.preferred-regions

Prüft: AWS-Provider-Region ist eine vorgenehmigte grüne Region.

Compliant Non-Compliant 
provider "aws" {
  region = "eu-north-1"
  # Stockholm: ~95% erneuerbare Energie
  # ~10 gCO₂eq/kWh
}
 
provider "aws" {
  region = "ap-east-1"
  # Hong Kong: ~25% erneuerbare Energie
  # WAF-SUS-030 Warning: Carbon-Begründung fehlt
}

Remediation: Für hohe-Carbon-Regionen: Begründung in ADR dokumentieren. Grüne Alternativen: eu-north-1, eu-west-1, us-west-2, ca-central-1.

Evidenz

Typ Pflicht Beschreibung

Governance

✅ Pflicht

ADR oder Region-Selection-Dokument mit Carbon-Intensity als berücksichtigtem Faktor.

Config

✅ Pflicht

Terraform-Provider-Konfiguration mit eingesetzten Regionen; Zuordnung zu Carbon-Intensity-Daten.

Governance

Optional

REC oder PPA für deployed Regionen.

Process

Optional

Carbon-Aware-Scheduling-Konfiguration für Batch-Workloads.

Regulatorisches Mapping

Framework Controls

EU CSRD (Corporate Sustainability Reporting Directive)

ESRS E1 – Climate change; ESRS G1 – Governance; ESRS S1 – Own workforce; ESRS S2 – Workers in own workforce; ESRS S3 – Affected communities; ESRS S4 – Human rights

GHG Protocol (Corporate Accounting and Reporting Standard)

Scope 1 – Direct emissions; Scope 2 – Indirect emissions from purchased energy; Scope 3 – Other indirect emissions

Green Software Foundation (GSF)

Software Engineering Principles – Carbon-aware computing; Carbon accounting standards

SBTi (Science Based Targets initiative)

Target setting methodology; Validation and verification; Corporate target standards

ISO 14001:2015

Clause 6.1 – Actions to address risks and opportunities; Clause 8.1 – Operational planning and control; Clause 9.1.1 – Monitoring, measurement, analysis and evaluation

ISO 14064-1:2018

Clause 5 – GHG inventory quantification; Clause 6 – GHG inventory validation and verification

GDPR

Art. 28 – Processor obligations; Art. 32 – Security of processing

CSRD

ESRS E1-6 – Emissions; ESRS G1-3 – Governance

NIST SP 800-53

AU-1 – Audit and accountability policy; AU-2 – Audit events; AU-3 – Content of audit records

NIST CSF 2.0

GV.PO – Policy; DE.CM – Continuous monitoring; RV.RP – Recovery planning

TISAX

Information security – Sustainability; Prototype protection – Environmental protection

ANSSI SecNumCloud

Domain – Environmental impact

BIO

BIO – Milieueffecten

ENS High

op.exp.9 – Gestión del impacto ambiental

UK NCSC CAF

B6 – Environmental impact

CMMC 2.0

AU.L2-3.8.1 – Automated audit logging

IRAP

ISM – Environmental monitoring

CCCS PBMM

AU-2 – Audit events

MAS TRM

Ch.12 – Outsourcing risk management

ISMAP

Sustainability and environmental impact

FISC

Operational measures – Environmental impact

Verwandte Controls

Best Practice