Wombat

WAF-PERF-080 – Serverless & Managed Services for Variable Load

Säule: Efficiancy | Schweregrad: Niedrig | Kategorie: Container Security | Automatisierbar: High

Beschreibung

Workloads with highly variable, spiky, or unpredictable traffic patterns SHOULD be evaluated for serverless or fully managed compute architectures. Where serverless is appropriate, Lambda, Cloud Functions, Azure Functions, or managed container services (Fargate, Cloud Run) MUST be configured with appropriate memory, timeout, concurrency, and cold-start mitigation strategies. Serverless function configurations MUST be optimized to avoid under-memory allocation, excessive timeouts, and uncontrolled concurrency.

Begründung

Risiko Beschreibung

Risk

Spiky workloads on slow-starting resources suffer cold-start latency and poor user experience.

Risk

Missing serverless or auto-scaling options lead to over-provisioning during idle periods.

Anforderungen

  • Workloads with highly variable, spiky, or unpredictable traffic patterns SHOULD be evaluated for serverless or fully managed compute architectures.

  • Where serverless is appropriate, Lambda, Cloud Functions, Azure Functions, or managed container services (Fargate, Cloud Run) MUST be configured with appropriate memory, timeout, concurrency, and cold-start mitigation strategies.

  • Serverless function configurations MUST be optimized to avoid under-memory allocation, excessive timeouts, and uncontrolled concurrency.

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-perf-080.tf.aws.lambda-memory-timeout-configured

Engine: terraform | Provider: aws | Automated: Ja

AWS Lambda functions must have explicit memory and timeout configuration

Lambda functions must not use default memory (128MB) or default timeout (3s) for production use. Both must be explicitly configured based on measured performance profiles.

Scope: resource — aws_lambda_function

Assertions: * memory_size greater than or equal 256 — Lambda memory_size must be explicitly set >= 256MB for production functions (default 128MB is rarely optimal). * timeout greater than or equal 1 — Lambda timeout must be explicitly set (not default 3s) and sized appropriately. * reserved_concurrent_executions attribute exists — Lambda reserved_concurrent_executions should be configured to control account concurrency usage.

Remediation: Run AWS Lambda Power Tuning to find optimal memory allocation. Set timeout = 2x measured P99 execution time. Set reserved_concurrent_executions to limit blast radius on account concurrency.

Compliant
resource "aws_lambda_function" "payment_processor" {
  function_name = "payment-processor"
  runtime       = "python3.12"
  handler       = "handler.process"
  filename      = data.archive_file.lambda.output_path
  memory_size   = 512    # Tuned with Lambda Power Tuning
  timeout       = 30     # 2x measured P99 of 15s
  reserved_concurrent_executions = 100  # Prevent consuming all account concurrency
  environment {
    variables = {
      LOG_LEVEL = "INFO"
    }
  }
}
Non-Compliant
resource "aws_lambda_function" "payment_processor" {
  function_name = "payment-processor"
  runtime       = "python3.12"
  handler       = "handler.process"
  filename      = data.archive_file.lambda.output_path
  # memory_size defaults to 128MB – not profiled – WAF-PERF-080 violation
  # timeout defaults to 3s – may cause timeouts
  # No reserved_concurrent_executions – uncontrolled concurrency
}

waf-perf-080.tf.azurerm.function-app-plan-configured

Engine: terraform | Provider: azurerm | Automated: Ja

Azure Function Apps for production should use Premium or Dedicated plan

Azure Function Apps in production should use Premium or Dedicated (App Service) plan to avoid cold starts, enable VNet integration, and provide predictable performance.

Scope: resource — azurerm_service_plan

Assertions: * sku_name not in ['Y1'] — Production Function Apps should not use Y1 (Consumption) plan due to cold starts and unpredictable performance.

Remediation: For production latency-sensitive functions, use EP1/EP2/EP3 (Premium) or P1v3/P2v3 (Dedicated). Consumption plan (Y1) is acceptable for truly event-driven, non-latency-critical workloads.

Compliant
resource "azurerm_service_plan" "functions" {
  name                = "plan-payment-functions"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  os_type             = "Linux"
  sku_name            = "EP1"  # Premium plan – consistent performance, no cold starts
}
Non-Compliant
resource "azurerm_service_plan" "functions" {
  name     = "plan-payment-functions"
  os_type  = "Linux"
  sku_name = "Y1"  # Consumption – cold starts for production latency SLO – advisory
}

waf-perf-080.tf.google.cloud-run-min-instances

Engine: terraform | Provider: google | Automated: Ja

GCP Cloud Run services with latency SLOs must set min-instances > 0

GCP Cloud Run services that have latency SLOs must configure minimum instances > 0 to eliminate cold starts. Services scaling to zero will experience cold start latency that may violate P99 SLO targets.

Scope: resource — google_cloud_run_service, google_cloud_run_v2_service

Assertions: * template.metadata.annotations["autoscaling.knative.dev/minScale"] not empty — Cloud Run service should set minimum instance annotation to prevent cold starts.

Remediation: Set the autoscaling.knative.dev/minScale annotation to >= 1 for latency-sensitive services. For cost optimization, consider min=1 during business hours and scheduled scaling to 0 overnight.

Compliant
resource "google_cloud_run_v2_service" "app" {
  name     = "payment-api"
  location = "europe-west3"
  template {
    scaling {
      min_instance_count = 1
      max_instance_count = 50
    }
    containers {
      image = "europe-west3-docker.pkg.dev/${var.project}/services/payment-api:latest"
      resources {
        limits = {
          cpu    = "2"
          memory = "512Mi"
        }
      }
    }
  }
}
Non-Compliant
resource "google_cloud_run_v2_service" "app" {
  name     = "payment-api"
  location = "europe-west3"
  template {
    # No scaling config – scales to zero, cold starts – WAF-PERF-080 advisory
    containers {
      image = "europe-west3-docker.pkg.dev/${var.project}/services/payment-api:latest"
    }
  }
}

waf-perf-080.tf.stackit.latency-monitored

Engine: terraform | Provider: stackit | Automated: Ja

Workloads with highly variable, spiky, or unpredictable traffic patterns…​ for stackit

Workloads with highly variable, spiky, or unpredictable traffic patterns…​ must be documented in IaC via a latency-monitored tag/label on stackit_project. This validates the control is tracked as code.

Scope: resource — stackit_project

Assertions: * labels key exists — stackit_project is missing the latency-monitored tag/label.

Remediation: Add a latency-monitored tag/label to the stackit_project resource to show the stackit implementation of WAF-PERF-080 is tracked in IaC.

Compliant
resource "stackit_project" "example" {
  labels = {
    latency-monitored = "true"
  }
}
Non-Compliant
resource "stackit_project" "example" {
  # Missing latency-monitored labels
}

waf-perf-080.tf.ovh.latency-monitored

Engine: terraform | Provider: ovh | Automated: Ja

Workloads with highly variable, spiky, or unpredictable traffic patterns…​ for ovh

Workloads with highly variable, spiky, or unpredictable traffic patterns…​ must be documented in IaC via a latency-monitored tag/label on ovh_cloud_project. This validates the control is tracked as code.

Scope: resource — ovh_cloud_project

Assertions: * tags key exists — ovh_cloud_project is missing the latency-monitored tag/label.

Remediation: Add a latency-monitored tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-PERF-080 is tracked in IaC.

Compliant
resource "ovh_cloud_project" "example" {
  tags = {
    latency-monitored = "true"
  }
}
Non-Compliant
resource "ovh_cloud_project" "example" {
  # Missing latency-monitored tags
}

waf-perf-080.tf.hcloud.latency-monitored

Engine: terraform | Provider: hcloud | Automated: Ja

Workloads with highly variable, spiky, or unpredictable traffic patterns…​ for hcloud

Workloads with highly variable, spiky, or unpredictable traffic patterns…​ must be documented in IaC via a latency-monitored tag/label on hcloud_server. This validates the control is tracked as code.

Scope: resource — hcloud_server

Assertions: * labels key exists — hcloud_server is missing the latency-monitored tag/label.

Remediation: Add a latency-monitored tag/label to the hcloud_server resource to show the hcloud implementation of WAF-PERF-080 is tracked in IaC.

Compliant
resource "hcloud_server" "example" {
  labels = {
    latency-monitored = "true"
  }
}
Non-Compliant
resource "hcloud_server" "example" {
  # Missing latency-monitored labels
}

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

ISO/IEC 25010

* Performance Efficiency – Time Behavior * Performance Efficiency – Capacity