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

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

Pillar: Performance Efficiency | Severity: Low | Kategorie: Compute Architecture | Automatisierbar: Mittel

Beschreibung

Workloads mit stark variablem, unvorhersehbarem Traffic SOLLEN auf Serverless-Eignung evaluiert werden. Serverlose Funktionen (Lambda, Cloud Functions, Azure Functions) MÜSSEN mit explizit konfiguriertem Memory, Timeout und Concurrency deployed werden. Cold-Start-Latenz MUSS für latenz-sensitive Funktionen durch Provisioned Concurrency oder Min-Instances-Konfiguration mitigiert werden. Lambda-Memory MUSS durch Profiling optimiert werden, nicht durch Standardwerte.

Rationale

Serverlose Architekturen eliminieren idle-Kapazitätskosten und skalieren instantan auf Demand. Für Spike-Workloads kann Serverless 10–100x kostengünstiger sein als Auto-Scaled EC2. Aber: Standard-Lambda mit 128MB Memory ist für die meisten produktiven Workloads suboptimal – CPU skaliert proportional zur Memory-Konfiguration, mehr Memory kann sogar günstiger sein durch schnellere Ausführung. Falsch konfigurierter Serverless-Code hat unvorhersehbare Performance.

Bedrohungskontext

Risiko Beschreibung

Cold-Start-Latenz

Erste Anfrage nach Idle-Phase ist 1–10x langsamer → SLO-Verletzung für erste Nutzer.

Unter-Memory = langsamere Ausführung

Lambda CPU ist proportional zu Memory; 256MB = 2x CPU-Credits vs 128MB.

Unkontrollierte Concurrency

Keine Reserved Concurrency → eine Funktion verbraucht alle Account-Concurrency-Credits.

Timeout-Misconfiguration

Default 3s-Timeout zu kurz → Silent Failures; 15min-Timeout zu lang → Zombie-Executions.

Anforderung

  • Variable-Load-Workloads SOLLEN auf Serverless-Eignung evaluiert werden (dokumentierte Entscheidung)

  • Lambda-Memory MUSS explizit konfiguriert sein (nicht Default 128MB)

  • Lambda-Timeout MUSS explizit auf 2x P99-Ausführungszeit gesetzt werden

  • Reserved Concurrency MUSS konfiguriert sein um Kontrollverlust über Account-Concurrency zu verhindern

  • Cold-Start-Mitigation MUSS für latenz-sensitive Funktionen evaluiert und implementiert werden

Implementierungsanleitung

  1. Workload-Eignung evaluieren: Variable Last? Async-tolerant? Zustandslos? → Serverless-Kandidat

  2. Lambda Power Tuning ausführen: aws-lambda-power-tuning für optimale Memory-Konfiguration

  3. Timeout messen: P99 der Ausführungszeit messen; Timeout = 2x P99 setzen

  4. Reserved Concurrency konfigurieren: Pro Service maximal X% der Account-Concurrency zuteilen

  5. Cold-Start-Analyse: Latenz-SLO prüfen; bei P99-SLO < 500ms: Provisioned Concurrency evaluieren

  6. CloudWatch-Alarme: Duration-P99, Throttles, ConcurrentExecutions überwachen

  7. Cloud Run Min-Instances: Für GCP: min_instance_count >= 1 für latenz-sensitive Services

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Default-Konfiguration

128MB Memory; Default-Timeout; keine Reserved Concurrency; keine Cold-Start-Analyse.

2

Manuell angepasst

Memory angepasst (nicht gemessen); Timeout gesetzt; Cold Starts bekannt aber nicht mitigiert.

3

Optimiert durch Profiling

Lambda Power Tuning durchgeführt; Timeout = 2x P99; Reserved Concurrency konfiguriert.

4

Erweiterte Optimierung

Provisioned Concurrency für latenz-kritische Funktionen; Cost-per-Invocation optimiert.

5

Vollständig managed

Autonomes Cost-Performance-Balancing; Edge Functions für ultra-low Latency.

Terraform Checks

waf-perf-080.tf.aws.lambda-memory-timeout-configured

Prüft: Lambda-Funktionen müssen explizites Memory >= 256MB, Timeout und Reserved Concurrency haben.

Compliant Non-Compliant 
resource "aws_lambda_function" "processor" {
  function_name = "payment-processor"
  runtime       = "python3.12"
  memory_size   = 512    # Aus Power Tuning
  timeout       = 30     # 2x P99 = 15s
  reserved_concurrent_executions = 100
}
 
resource "aws_lambda_function" "processor" {
  function_name = "payment-processor"
  runtime       = "python3.12"
  # memory_size default 128MB
  # timeout default 3s
  # Keine reserved_concurrent_executions
  # WAF-PERF-080 Violation
}

Remediation: memory_size >= 256, timeout = 2x_p99, reserved_concurrent_executions setzen. Lambda Power Tuning ausführen: https://github.com/alexcasalboni/aws-lambda-power-tuning

Evidenz

Typ Pflicht Beschreibung

IaC

✅ Pflicht

Lambda-/Function-Konfiguration mit explizitem Memory, Timeout, Concurrency.

Governance

✅ Pflicht

Dokumentation der Serverless-Adoption-Entscheidung für variable Workloads.

Config

Optional

Lambda Power Tuning-Ergebnisse oder Memory-Optimierungsanalyse.

Process

Optional

Kostenvergleich Serverless vs. EC2/Container für Spike-Workloads.

Regulatorisches Mapping

Framework Controls

ISO/IEC 25010:2011

8.3.2 – Performance efficiency; 8.3.2.1 – Time behaviour; 8.3.2.2 – Resource utilisation; 8.3.2.3 – Capacity

AWS Well-Architected Framework

Performance Efficiency Pillar – Selection; Performance Efficiency Pillar – Review; Performance Efficiency Pillar – Efficiency

Azure Well-Architected Framework

Performance – Performance monitoring; Performance – Load and stress testing; Performance – Auto-scaling

Google Cloud Architecture Framework

Performance – Performance design principles; Performance – Monitoring and debugging

TOGAF 10

ADM Phase B – Business architecture; ADM Phase C – Application architecture; ADM Phase D – Technology architecture

DORA

DORA 2024 – Technical practices; DORA 2024 – Performance monitoring

ISO/IEC 29119

4.4.3 – Test design techniques; 4.5.3 – Test execution; 5.3.3 – Test reporting

ISO/IEC 12207

8.2.2.3 – Design and development of software; 9.4.2 – Verification

ITIL 4

SVS – Service value system; DP – Design principle; OV – Operation value chain

BSI C5:2020

OPS-01 – Operational monitoring; OPS-02 – Operational control; OPS-03 – Operational capacity

CIS Controls v8

CIS 8 – Continuous Vulnerability Management; CIS 8.1 – Vulnerability scanning

NIST SP 800-53

RA-1 – Security assessment policy; RA-2 – Security assessment controls; RA-5 – Security assessments; RA-9 – External information system attacks

NIST CSF 2.0

DE.CM – Continuous monitoring; DE.AE – Anomaly detection; DE.DP – Data performance

FedRAMP

RA-2, RA-5, RA-9 (Moderate/High baseline)

SOC 2 Type II

CC6.1 – Logical access security software; CC7.1 – Infrastructure and software monitoring

TISAX

Information security – Performance monitoring

ANSSI SecNumCloud

Domain – Performance monitoring

BIO

BIO – Prestatiedoelstellingen

ENS High

op.exp.2 – Configuración de seguridad; op.exp.3 – Gestión de la configuración

UK NCSC CAF

B4 – System security; B5 – System performance

CMMC 2.0

RA.L2-3.8.1 – Automated monitoring

IRAP

ISM – Performance monitoring

CCCS PBMM

RA-2 – Security assessment controls; RA-5 – Security assessments

MAS TRM

Ch.5 – Technology risk governance

ISMAP

Performance monitoring and validation

FISC

Technical measures – Performance monitoring

Verwandte Controls

Best Practice