WAF-PERF-080 – Serverless & Managed Services for Variable Load
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
-
Workload-Eignung evaluieren: Variable Last? Async-tolerant? Zustandslos? → Serverless-Kandidat
-
Lambda Power Tuning ausführen:
aws-lambda-power-tuningfür optimale Memory-Konfiguration -
Timeout messen: P99 der Ausführungszeit messen; Timeout = 2x P99 setzen
-
Reserved Concurrency konfigurieren: Pro Service maximal X% der Account-Concurrency zuteilen
-
Cold-Start-Analyse: Latenz-SLO prüfen; bei P99-SLO < 500ms: Provisioned Concurrency evaluieren
-
CloudWatch-Alarme: Duration-P99, Throttles, ConcurrentExecutions überwachen
-
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 |
|---|---|
|
|
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 – Select the right resource types and sizes |
Azure Well-Architected Framework |
Performance Efficiency – Choose the right resources |
Google Cloud Architecture Framework |
Performance optimization – Right-size your instances |
TOGAF 10 |
ADM Phase B – Business architecture; ADM Phase C – Application architecture |
DORA |
DORA 2024 – Technical practices; DORA 2024 – Performance monitoring |
ISO/IEC 29119 |
4.4.3 – Test design techniques; 4.5.3 – Test execution |
ISO/IEC 12207 |
8.2.2.3 – Design and development of software |
ITIL 4 |
SVS – Service value system; DP – Design principle |
BSI C5:2020 |
OPS-01 – Operational monitoring; OPS-02 – Operational control |
CIS Controls v8 |
CIS 8 – Continuous Vulnerability Management |
NIST SP 800-53 |
RA-1 – Security assessment policy; RA-2 – Security assessment controls |
NIST CSF 2.0 |
DE.CM – Continuous monitoring; DE.AE – Anomaly detection |
FedRAMP |
RA-2, RA-5 (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 |
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 |