WAF-SUS-060 – Workload Scheduling & Time-Shifting
Beschreibung
Batch-Workloads, Report-Generierung und Datenverarbeitungs-Pipelines ohne harte Latenz-SLAs MÜSSEN auf Off-Peak-Stunden (22:00–06:00 UTC) geplant werden. EventBridge Schedules für nicht-latenz-sensitive Jobs MÜSSEN Flexible Time Windows aktivieren. Workloads mit flexiblem Ausführungsfenster SOLLEN Carbon-Intensity-APIs (WattTime, electricityMaps) für dynamisches Scheduling evaluieren. Alle Scheduling-Entscheidungen MÜSSEN die Carbon-Rationale dokumentieren.
Rationale
Stromnetze haben zu verschiedenen Tageszeiten unterschiedliche Carbon Intensity. In Regionen mit hohem Solaranteil ist die Carbon Intensity mittags am niedrigsten und nachts tendenziell höher — in Regionen mit viel Windenergie kann es umgekehrt sein. Temporal Shifting — Batch-Jobs in das Zeitfenster mit niedrigster Carbon Intensity verschieben — kann 20–60% der Batch-Emissionen reduzieren ohne Code-Änderungen. EventBridge Flexible Time Windows ermöglichen diese Optimierung ohne zusätzliche Infrastruktur.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Peak-Stunden-Batch |
Batch-Jobs um 09:00 Uhr ausgeführt, wenn Stromverbrauch und Carbon Intensity ihr Tages-Maximum erreichen. |
Fehlende Dokumentation |
Scheduling-Entscheidungen ohne Carbon-Rationale sind CSRD-Governance-Gap. |
Kein Flexible Window |
Starre Ausführungszeiten verhindern Carbon-Aware-Optimierung ohne zusätzlichen Engineering-Aufwand. |
AWS Batch auf ON_DEMAND |
Batch-Workloads auf On-Demand statt SPOT verbrauchen dedizierte Kapazität statt geteilter ungenutzter. |
Anforderung
-
Alle Batch-Workloads ohne Latenz-SLA MÜSSEN auf 22:00–06:00 UTC geplant werden
-
EventBridge Schedules SOLLTEN
flexible_time_window { mode = "FLEXIBLE" }haben -
AWS Batch SOLL
type = "SPOT"für alle Batch Compute Environments nutzen -
Scheduling-Entscheidungen MÜSSEN Carbon-Rationale dokumentieren
-
Carbon-Intensity-APIs SOLLEN für Tier-1-Batch-Workloads evaluiert werden
Implementierungsanleitung
-
Batch-Workload-Inventar: Alle EventBridge, Cron, Step-Functions-Jobs inventarisieren; Latenz-Klassifizierung
-
Off-Peak-Scheduling: Alle flexiblen Jobs auf
cron(0 22 * * ? *)oder später umplanen -
Flexible Windows:
maximum_window_in_minutes = 120für alle non-latency-sensitive Jobs -
AWS Batch SPOT:
type = "SPOT",allocation_strategy = "SPOT_CAPACITY_OPTIMIZED" -
Carbon-API: electricityMaps oder WattTime API für dynamisches Scheduling evaluieren
-
Dokumentation: Scheduling-Entscheidung für alle Major-Batch-Jobs mit Carbon-Begründung
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Willkürliche Zeiten |
Batch läuft zu Entwickler-Convenience-Zeiten; kein Carbon-Bewusstsein. |
2 |
Einige Off-Peak-Jobs |
Einzelne große Jobs manuell auf Nacht verschoben; kein systematischer Ansatz. |
3 |
Systematisch Off-Peak |
Alle Flex-Jobs auf 22:00–06:00 UTC; EventBridge Flexible Windows; dokumentiert. |
4 |
Carbon-API-Integration |
electricityMaps/WattTime für dynamisches Scheduling; Carbon-Savings getrackt. |
5 |
Temporal + Spatial Shifting |
Region- und Zeit-Optimierung kombiniert; Carbon-Einsparungen in SCI documentiert. |
Terraform Checks
waf-sus-060.tf.aws.eventbridge-flexible-window
Prüft: EventBridge Schedules nutzen Flexible Time Windows.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: schedule_expression auf Off-Peak-Zeit setzen; flexible_time_window { mode = "FLEXIBLE"; maximum_window_in_minutes = 120 } aktivieren.
waf-sus-060.tf.aws.batch-compute-spot
Prüft: AWS Batch Compute Environments nutzen SPOT-Allocation.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: type = "SPOT" und allocation_strategy = "SPOT_CAPACITY_OPTIMIZED" setzen; min_vcpus = 0 für echtes Scale-to-Zero.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
Config |
✅ Pflicht |
EventBridge Scheduler oder Cron-Konfiguration mit Off-Peak-Scheduling und Flexible Windows. |
Process |
Optional |
Carbon-Intensity-API-Integration für dynamisches Scheduling. |
Governance |
Optional |
Scheduling-Dokumentation für Major-Batch-Pipelines mit Carbon-Rationale. |
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 |