Wombat

WAF-SUS-070 – Sustainable Software Design Standards

Säule: Sustainability | Schweregrad: Mittel | Kategorie: Sustainability Efficiency | Automatisierbar: High

Beschreibung

Software MUST be designed with energy efficiency as an explicit quality attribute. Architecture Decision Records MUST include energy efficiency considerations for algorithm and data structure choices. Dependencies MUST be reviewed for efficiency: unused libraries, heavy frameworks, and polling patterns MUST be replaced with lightweight alternatives and event-driven designs. Software Carbon Intensity (SCI) SHOULD be measured for critical workloads and included in architecture reviews. Teams MUST avoid over-engineering: monolithic frameworks, excessive microservice proliferation, and redundant compute layers all increase energy consumption without delivering proportional value.

Begründung

Risiko Beschreibung

Risk

Software that ignores energy efficiency consumes resources disproportionately.

Risk

Inefficient algorithms or polling patterns waste CPU cycles and increase carbon emissions.

Anforderungen

  • Software MUST be designed with energy efficiency as an explicit quality attribute.

  • Architecture Decision Records MUST include energy efficiency considerations for algorithm and data structure choices.

  • Dependencies MUST be reviewed for efficiency: unused libraries, heavy frameworks, and polling patterns MUST be replaced with lightweight alternatives and event-driven designs.

  • Software Carbon Intensity (SCI) SHOULD be measured for critical workloads and included in architecture reviews.

  • Teams MUST avoid over-engineering: monolithic frameworks, excessive microservice proliferation, and redundant compute layers all increase energy consumption without delivering proportional value.

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-070.tf.aws.lambda-no-large-layers

Engine: terraform | Provider: aws | Automated: Ja

Lambda functions should not attach excessive numbers of layers

Lambda functions with many layers have larger deployment packages, higher cold-start energy consumption, and more complex dependency footprints. Each layer must be justified by the functionality it provides.

Scope: resource — aws_lambda_function

Assertions: * layers attribute exists — No layers attribute found – this check passes; single-package deployments are preferred.

Remediation: Review Lambda layer usage. Consolidate multiple utility layers into a single optimized layer. Use dependency management (requirements.txt, package.json) to control package size. Consider Lambda container images for complex dependency trees with multi-arch builds.

Compliant
resource "aws_lambda_function" "api" {
  function_name = "api-handler"
  runtime       = "python3.12"
  architectures = ["arm64"]
  handler       = "main.handler"
  role          = aws_iam_role.lambda.arn
  filename      = "function.zip"
  # No unnecessary layers – slim deployment package
}
Non-Compliant
resource "aws_lambda_function" "api" {
  function_name = "api-handler"
  runtime       = "python3.12"
  architectures = ["x86_64"]
  layers = [
    aws_lambda_layer_version.utils.arn,
    aws_lambda_layer_version.logging.arn,
    aws_lambda_layer_version.db_client.arn,
    aws_lambda_layer_version.aws_sdk_extras.arn,
    aws_lambda_layer_version.common.arn,
    # WAF-SUS-070 Warning: 5 layers – review and consolidate
  ]
}

waf-sus-070.tf.aws.sqs-not-polling

Engine: terraform | Provider: aws | Automated: Ja

SQS event source mapping should use long polling for Lambda triggers

Lambda functions triggered by SQS should use long polling (maximum_batching_window_in_seconds > 0) to batch messages and reduce the number of Lambda invocations. Short polling or no batching causes excessive invocations per message, increasing energy consumption per unit of work.

Scope: resource — aws_lambda_event_source_mapping

Assertions: * maximum_batching_window_in_seconds greater than or equal 1 — SQS Lambda trigger uses no batching window – enable long polling to reduce invocations per message.

Remediation: Set maximum_batching_window_in_seconds = 30 (or higher) and batch_size = 100 on SQS event source mappings to maximize message batching. This reduces Lambda invocations by up to 90% for high-volume queues, directly reducing energy per message processed.

Compliant
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn                   = aws_sqs_queue.events.arn
  function_name                      = aws_lambda_function.processor.arn
  batch_size                         = 100
  maximum_batching_window_in_seconds = 30  # batch for 30s before invoking
  function_response_types            = ["ReportBatchItemFailures"]
}
Non-Compliant
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn = aws_sqs_queue.events.arn
  function_name    = aws_lambda_function.processor.arn
  batch_size       = 1  # WAF-SUS-070 Warning: 1 invocation per message, very inefficient
}

waf-sus-070.tf.google.cloud-run-min-instances-zero

Engine: terraform | Provider: google | Automated: Ja

GCP Cloud Run services should scale to zero in non-production

Cloud Run services with min_instance_count > 0 maintain warm instances continuously even when there is no traffic. Setting min_instance_count = 0 allows scale-to-zero, eliminating idle compute energy consumption.

Scope: resource — google_cloud_run_v2_service

Assertions: * template.scaling.min_instance_count equals 0 — Cloud Run service has minimum instances > 0 – idle instances consume energy. Consider scale-to-zero.

Remediation: Set min_instance_count = 0 for all non-production Cloud Run services. For production services with strict cold-start SLAs, use min_instance_count = 1 and document the sustainability trade-off in the architecture decision record.

Compliant
resource "google_cloud_run_v2_service" "api" {
  name     = "api-service"
  location = "europe-north1"

  template {
    scaling {
      min_instance_count = 0   # scale to zero – no idle energy
      max_instance_count = 10
    }
  }
}
Non-Compliant
resource "google_cloud_run_v2_service" "api" {
  name     = "api-service"
  location = "us-east1"

  template {
    scaling {
      min_instance_count = 5   # WAF-SUS-070 Warning: always-on instances, idle energy
      max_instance_count = 50
    }
  }
}

waf-sus-070.tf.azurerm.service-plan-consumption

Engine: terraform | Provider: azurerm | Automated: Ja

Azure App Service plans for event-driven workloads should be Consumption or Elastic Premium

Azure Function Apps and event-driven workloads should run on Consumption (Y1) or Elastic Premium (EP1/EP2/EP3) plans so they scale to zero when idle, reducing baseline energy consumption.

Scope: resource — azurerm_service_plan

Assertions: * sku_name in ['Y1', 'EP1', 'EP2', 'EP3'] — Azure Service Plan should use Consumption (Y1) or Elastic Premium (EP1/EP2/EP3) for event-driven/energy-efficient workloads.

Remediation: Set azurerm_service_plan.sku_name to Y1 for Consumption or EP1/EP2/EP3 for Elastic Premium. Avoid Dedicated (S1/P1V2) App Service plans for purely event-driven workloads.

Compliant
resource "azurerm_service_plan" "consumption" {
  name                = "asp-consumption"
  resource_group_name = azurerm_resource_group.main.name
  location            = "germanywestcentral"
  os_type             = "Linux"
  sku_name            = "Y1"
}

resource "azurerm_linux_function_app" "processor" {
  name                = "processor-func"
  resource_group_name = azurerm_resource_group.main.name
  location            = "germanywestcentral"
  service_plan_id     = azurerm_service_plan.consumption.id
  site_config {}
}
Non-Compliant
resource "azurerm_service_plan" "dedicated" {
  name                = "asp-dedicated"
  resource_group_name = azurerm_resource_group.main.name
  location            = "germanywestcentral"
  os_type             = "Linux"
  sku_name            = "S1"
}

resource "azurerm_linux_function_app" "processor" {
  name            = "processor-func"
  service_plan_id = azurerm_service_plan.dedicated.id
  # Dedicated plan keeps workers always on
}

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) – measurement and optimization standard * Energy Efficiency – algorithmic and architectural efficiency * Carbon Efficiency – reducing energy per functional unit

EU CSRD (Corporate Sustainability Reporting Directive)

* ESRS E1 – Climate Change – operational measures to reduce emissions

ISO 14001

* 6.1.2 – Environmental Aspects – software design as environmental aspect