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

WAF-SUS-020 – Energy-Efficient Compute Selection

Pillar: Sustainability | Severity: High | Kategorie: Compute Efficiency | Automatisierbar: Hoch

Beschreibung

Alle Compute-Ressourcen MÜSSEN energieeffiziente Prozessor-Architekturen bevorzugen. AWS Lambda-Funktionen MÜSSEN architectures = ["arm64"] nutzen. EC2-Instanzen DÜRFEN NICHT previous-generation Familien (t2, m4, c4, r4) für Neudeployments verwenden. ARM/Graviton-Instanzen liefern 20–40% bessere Performance-per-Watt als äquivalente x86-Instanzen — bei gleichzeitig niedrigeren Kosten.

Rationale

Compute-Instanztypen haben einen direkten, messbaren Einfluss auf Energieverbrauch pro Workload. Graviton3 (m7g, c7g, r7g) bietet ~40% bessere Performance-per-Watt als vergleichbare Intel-Instanzen. Lambda arm64 verbraucht ~20% weniger Energie pro Invocation. Previous-Generation-Instanzen haben bekannt schlechte Energieeffizienz und keine technische Rechtfertigung für Neudeployments. Dieser Control hat den höchsten Automatisierungsgrad aller WAF-SUS-Controls.

Bedrohungskontext

Risiko Beschreibung

Excess Scope 3 Emissionen

Previous-Gen x86-Instanzen emittieren 30–50% mehr CO₂/Workload als aktuelle Graviton-Äquivalente.

SCI-Ziele verfehlt

Software Carbon Intensity kann ohne energieeffiziente Hardware-Basis nicht nachhaltig verbessert werden.

Sustainability-Schulden

Ungeprüfte Instanztypen akkumulieren sich und werden bei Skalierung proportional teurer in CO₂ und Kosten.

CI-Gate fehlt

Ohne automatisierte Prüfung im Pipeline werden Previous-Gen-Typen unkontrolliert weiter deployed.

Anforderung

  • Neudeployments EC2 MÜSSEN aktuelle Instanzfamilien nutzen (t4g, m7g, c7g, r7g für Graviton-bevorzugte Workloads)

  • Lambda-Funktionen MÜSSEN architectures = ["arm64"] setzen

  • Previous-Generation-Instanztypen (t2, m4, c4, r4) DÜRFEN NICHT für neue Ressourcen verwendet werden

  • x86-Instanzen für Brownfield-Workloads MÜSSEN im Sustainability Debt Register dokumentiert sein

  • Ein CI-Gate SOLL bei Previous-Gen-Instanztypen warnen oder blockieren

Implementierungsanleitung

  1. Inventar erstellen: aws ec2 describe-instances + Grouping nach Instanzfamilie; Previous-Gen identifizieren

  2. Migrationsreihenfolge: Lambda (einfachste), Container (AMI-Rebuild), EC2 (Test erforderlich)

  3. Lambda migration: architectures = ["arm64"] in allen Lambda-Ressourcen setzen

  4. EC2 Graviton: ARM64-kompatibles AMI wählen; Graviton3-Äquivalent nutzen (m4 → m7g, c4 → c7g)

  5. CI-Gate: Regex-Check für Previous-Gen-Instanztypen in Terraform-Pipeline einbauen

  6. Sustainability Debt Register: Nicht-migrierbare x86-Workloads mit Begründung und Zieldatum dokumentieren

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Keine Policy

Keine ARM/Graviton-Instanzen; Previous-Gen für Neudeployments; Lambda auf x86_64.

2

Awareness

Einige Graviton-Instanzen vorhanden; keine verbindliche Policy; kein Tracking.

3

Policy + CI-Gate

Compute-Sustainability-Policy dokumentiert; CI-Gate für Previous-Gen; >30% ARM; Lambda-Standard arm64.

4

Brownfield aktiv migriert

>60% vCPU-Stunden auf ARM/Graviton; Migrationsplan in Umsetzung; >80% Lambda arm64.

5

ARM-First

>85% ARM; alle Ausnahmen im Debt Register; SCI verbessert sich nachweislich YoY.

Terraform Checks

waf-sus-020.tf.aws.lambda-arm64

Prüft: Lambda-Funktionen nutzen arm64-Architektur.

Compliant Non-Compliant 
resource "aws_lambda_function" "handler" {
  function_name = "api-handler"
  runtime       = "python3.12"
  architectures = ["arm64"]
  handler       = "main.handler"
  role          = aws_iam_role.lambda.arn
  filename      = "function.zip"
}
 
resource "aws_lambda_function" "handler" {
  function_name = "api-handler"
  runtime       = "python3.12"
  architectures = ["x86_64"]
  # WAF-SUS-020 Violation: nutze arm64
  handler  = "main.handler"
  role     = aws_iam_role.lambda.arn
  filename = "function.zip"
}

Remediation: architectures = ["arm64"] setzen. Python, Node.js, Java, Go sind vollständig arm64-kompatibel.

waf-sus-020.tf.aws.ec2-no-previous-gen

Prüft: EC2-Instanzen nutzen keine Previous-Generation-Familien.

Compliant Non-Compliant 
resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu_arm.id
  instance_type = "m7g.large"
  # Graviton3 – 40% besser als m4.large
}
 
resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "m4.large"
  # WAF-SUS-020 Violation: Previous-Gen
  # Migriere zu m7g.large
}

Remediation: m4.large → m7g.large (Graviton3). ARM64-kompatibles AMI erforderlich.

Evidenz

Typ Pflicht Beschreibung

IaC

✅ Pflicht

Terraform-Konfiguration mit Graviton/arm64 Instanztypen für EC2 und Lambda.

Config

✅ Pflicht

Cloud-Inventory-Report mit Verteilung der Instanztypen nach Familie (ARM-Share in %).

Governance

Optional

Compute-Sustainability-Policy mit bevorzugten Instanzfamilien.

Process

Optional

Migrationsplan für verbleibende x86-Workloads mit Timeline und Progress-Tracking.

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