WAF-SUS-020 – Energy-Efficient Compute Selection

Beschreibung

All compute resources MUST prefer energy-efficient processor architectures (ARM64/Graviton for AWS, Ampere Altra for Azure, T2A for GCP) over equivalent x86 instance families. AWS Lambda functions MUST use arm64 architecture unless the workload has a verified incompatibility. EC2 instances MUST NOT use previous-generation families (t2, m4, c4, r4) when current-generation equivalents are available. ARM/Graviton instances deliver 20-40% better performance-per-watt compared to equivalent x86 instances, reducing both cost and carbon emissions simultaneously.

Begründung

Risiko Beschreibung

Risk

Energy-inefficient processors increase carbon footprint and operating cost without added value.

Risk

Outdated instance families do not use hardware optimally and waste power.

Anforderungen

  • All compute resources MUST prefer energy-efficient processor architectures (ARM64/Graviton for AWS, Ampere Altra for Azure, T2A for GCP) over equivalent x86 instance families.

  • AWS Lambda functions MUST use arm64 architecture unless the workload has a verified incompatibility.

  • EC2 instances MUST NOT use previous-generation families (t2, m4, c4, r4) when current-generation equivalents are available.

Implementierungsleitfaden

  1. Document the requirement in a version-controlled policy or standard.

  2. Assign ownership and establish a review cadence (e.g., quarterly).

  3. Implement the required configuration as code in Terraform or equivalent IaC.

Reifegrade

Level Name Kriterien

L1

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

L2

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

L3

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

L4

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

L5

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

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

Engine: terraform | Provider: aws | Automated: Ja

AWS Lambda functions must use arm64 architecture

Lambda functions running on arm64 (Graviton2) use 20% less energy per invocation than x86_64 equivalents at equivalent performance. All Lambda functions MUST declare architectures = ["arm64"] unless there is a documented compatibility exception.

Scope: resource — aws_lambda_function

Assertions: * architectures not in ['x86_64'] — Lambda function uses x86_64 architecture; switch to arm64 for 20% energy reduction.

Remediation: Set architectures = ["arm64"] on all Lambda functions. Verify that all Lambda layers and dependencies support arm64. Most Python, Node.js, Java and Go runtimes are fully supported. For container image functions, rebuild the image for linux/arm64 platform.

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

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

Engine: terraform | Provider: aws | Automated: Ja

EC2 instances must not use previous-generation instance families

Previous-generation EC2 instance families (t2, m4, c4, r4, i2, d2, m3, c3) have significantly worse performance-per-watt than current-generation equivalents. They also lack support for modern EBS optimized I/O and network performance features.

Scope: resource — aws_instance, aws_launch_template

Assertions: * instance_type not matches pattern ^(t2|m4|c4|r4|i2|d2|m3|c3)\. — Instance type uses a previous-generation family with poor energy efficiency. Migrate to t4g, m7g, c7g, or r7g.

Remediation: Replace previous-generation instance types with current-generation equivalents: t2 → t4g (Graviton2, 40% better price-performance), m4 → m7g (Graviton3, best performance-per-watt), c4 → c7g (Graviton3, compute-optimized), r4 → r7g (Graviton3, memory-optimized). Test compatibility before migration using AWS Graviton migration guide.

Compliant
resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu_arm.id
  instance_type = "m7g.large"  # Graviton3, 40% better performance/watt
  tags = {
    environment = "production"
    workload    = "payment-service"
  }
}
Non-Compliant
resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "m4.large"  # WAF-SUS-020 Violation: previous-gen, poor efficiency
  tags = {
    environment = "production"
  }
}

waf-sus-020.tf.azurerm.vm-efficient-series

Engine: terraform | Provider: azurerm | Automated: Ja

Azure VMs should use Ampere Altra (Dpsv5/Epsv5) or equivalent efficient series

Azure Dpsv5 and Epsv5 series VMs use Ampere Altra ARM processors with 40% better performance per watt than equivalent Dv4/Ev4 series. These should be preferred for general and memory-optimized workloads.

Scope: resource — azurerm_linux_virtual_machine, azurerm_windows_virtual_machine

Assertions: * size not matches pattern ^Standard_(D|E)[0-9]+_v[0-3]$ — VM uses an older series with poor energy efficiency. Consider Dpsv5, Epsv5, or Ddsv5 series.

Remediation: Migrate VMs to Dpsv5 (Ampere Altra ARM) for general workloads or Epsv5 for memory-intensive. For x86-only workloads, use Ddsv5 or Edsv5 as the most energy-efficient x86 option. Run Azure Migrate assessment to validate compatibility before resizing.

Compliant
resource "azurerm_linux_virtual_machine" "app" {
  name                = "vm-app-prod"
  resource_group_name = var.resource_group_name
  location            = var.location
  size                = "Standard_D4ps_v5"  # Ampere Altra ARM – best efficiency
  admin_username      = "adminuser"
  network_interface_ids = [azurerm_network_interface.app.id]
}
Non-Compliant
resource "azurerm_linux_virtual_machine" "app" {
  name                = "vm-app-prod"
  resource_group_name = var.resource_group_name
  location            = var.location
  size                = "Standard_D4_v3"  # WAF-SUS-020 Warning: older series, lower efficiency
  admin_username      = "adminuser"
  network_interface_ids = [azurerm_network_interface.app.id]
}

waf-sus-020.tf.google.compute-efficient-machine-type

Engine: terraform | Provider: google | Automated: Ja

GCP compute instances should use energy-efficient machine families

GCP compute instances should prefer energy-efficient machine types such as e2, n2d, c3d, or t2d families over legacy n1/n2 where workloads allow.

Scope: resource — google_compute_instance

Assertions: * machine_type matches pattern ^(e2|n2d|c3d|t2d)- — GCP compute instance should use an energy-efficient machine family (e2, n2d, c3d, t2d).

Remediation: Choose energy-efficient machine types (e2-standard-2, n2d-standard-2, c3d-standard-4, t2d-standard-1) for new workloads and migrate legacy n1/n2 instances where feasible.

Compliant
resource "google_compute_instance" "web" {
  name         = "web-server"
  machine_type = "e2-standard-2"
  zone         = "europe-west3-a"
}
Non-Compliant
resource "google_compute_instance" "legacy" {
  name         = "legacy-server"
  machine_type = "n1-standard-4"
  zone         = "us-central1-a"
}

Evidenz

Art Erforderlich Beschreibung

iac

Erforderlich

Terraform configuration implementing the control.

governance

Erforderlich

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Verwandte Controls

Framework Controls

Green Software Foundation

* Software Carbon Intensity (SCI) – hardware efficiency component * Energy Efficiency – compute selection guidance

EU CSRD (Corporate Sustainability Reporting Directive)

* ESRS E1 – Climate Change – Scope 3 emission reduction measures

GHG Protocol

* Scope 2 – Location-based and market-based methods * Scope 3 Category 11 – efficiency of purchased cloud compute

SBTi (Science Based Targets initiative)

* ICT Sector Guidance – energy intensity reduction targets