WAF-PERF-090 – Storage I/O Performance & Throughput Optimization
Beschreibung
Alle Block-Storage-Volumes MÜSSEN den für den Workload geeigneten Storage-Typ verwenden. AWS EBS MUSS gp3 statt gp2 für neue Deployments verwenden. IOPS und Throughput MÜSSEN explizit konfiguriert sein (nicht Default-Werte). Storage-I/O-Metriken (Queue-Depth, Throughput, Burst-Balance) MÜSSEN überwacht und bei Sättigung alarmiert werden. Datenbank-Volumes MÜSSEN Premium-SSD oder äquivalent verwenden.
Rationale
Storage-I/O-Sättigung ist ein häufig übersehener Performance-Bottleneck. CPU und Netzwerk erscheinen normal, aber Datenbanklatenz steigt – weil das EBS-Volume die maximale IOPS erreicht hat oder die gp2-Burst-Bucket erschöpft ist. gp3 bietet 3.000 IOPS und 125 MB/s Baseline (ohne Burst-Mechanik) zu 20% niedrigerem Preis als gp2. Für Datenbanken ist der richtige Disk-Typ oft wichtiger als der Instanztyp.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
gp2 Burst-Erschöpfung |
gp2-Volumes akkumulieren I/O-Credits und verlieren sie bei anhaltender Last → plötzlicher Performance-Einbruch. |
I/O-Sättigung |
Zu wenige IOPS für Workload → Query-Latenz steigt bei normaler CPU/Network → schwer zu diagnostizieren. |
Falscher Disk-Typ |
Standard-HDD (pd-standard, Standard_LRS) für Datenbankvolumes → 10x höhere Latenz als SSD. |
Snapshot-I/O-Interferenz |
Backup-Snapshots auf gleichem Volume wie Produktions-Daten → I/O-Spikes während Backup-Fenster. |
Anforderung
-
Alle neuen AWS EBS Volumes MÜSSEN gp3 statt gp2 verwenden
-
IOPS und Throughput MÜSSEN für gp3-Volumes explizit konfiguriert sein (wenn > Default benötigt)
-
Datenbank-Volumes MÜSSEN Premium-SSD/io2/pd-ssd verwenden
-
Storage-I/O-Monitoring MUSS aktiv sein mit Alerts bei Queue-Depth > 1 oder Burst-Balance < 30%
Implementierungsanleitung
-
Inventory: gp2-Volumes identifizieren:
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 -
gp3-Migration planen: Online-Migration (kein Downtime):
aws ec2 modify-volume --volume-type gp3 -
IOPS/Throughput konfigurieren: Basis: 3000 IOPS, 125 MB/s; Datenbanken: basierend auf
pg_stat_bgwriteroder equivalent -
Terraform aktualisieren:
volume_type = "gp3",iops,throughputexplizit setzen -
I/O-Monitoring aktivieren: CloudWatch
VolumeQueueLength,BurstBalance,VolumeReadOps,VolumeWriteOps -
Alerts konfigurieren:
VolumeQueueLength > 1für 5 Minuten = Alert;BurstBalance < 30%= Warning -
Azure/GCP äquivalent: Premium_LRS für Azure Datenbank-Disks; pd-ssd oder pd-balanced für GCP
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Default-Storage |
Alle Volumes gp2 oder Default; keine I/O-Überwachung; Storage-I/O-Probleme unbekannt. |
2 |
Storage-Typ selektiert |
SSD für Datenbanken, HDD für Archive; keine expliziten IOPS; kein I/O-Monitoring. |
3 |
gp3 + I/O-Monitoring |
Alle neuen Volumes gp3; Migration-Plan für gp2; I/O-Alerts konfiguriert. |
4 |
Vollständig optimiert |
gp2-Migration abgeschlossen; IOPS explizit dimensioniert; Snapshot-Scheduling optimiert. |
5 |
Intelligent Tiering |
Automatische Storage-Tier-Empfehlungen; I/O als SLI in SLO-Definitionen. |
Terraform Checks
waf-perf-090.tf.aws.ebs-gp3-volume-type
Prüft: EBS-Volumes dürfen kein gp2 verwenden; gp3 oder spezifische io-Typen sind Pflicht.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: type = "gp3" setzen. Migration ist online und nicht-disruptiv.
gp3 bietet gleiche oder bessere Performance bei 20% niedrigerem Preis als gp2.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
IaC |
✅ Pflicht |
Terraform-Konfiguration mit explizitem Storage-Typ, IOPS und Throughput. |
Config |
✅ Pflicht |
Monitoring-Konfiguration für I/O-Alerts (Queue-Depth, Throughput, Burst-Balance). |
Process |
Optional |
Storage-I/O-Baseline (P95/P99 Queue-Depth und Throughput-Auslastung). |
Governance |
Optional |
Storage-Tier-Richtlinien nach Workload-Typ. |
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 |