WAF-PERF-070 – Network Latency & Topology Optimization
Beschreibung
Alle Produktions-Workloads MÜSSEN mit latenzoptimierter Netzwerktopologie deployed werden. CDN MUSS für alle öffentlichen statischen und cachefähigen Inhalte konfiguriert sein. VPC Endpoints MÜSSEN für alle Cloud-Service-API-Zugriffe aus privaten Subnetzen verwendet werden. Cross-AZ-Traffic in latenz-sensitiven Pfaden MUSS minimiert werden. Netzwerklatenz-Baselines MÜSSEN für Service-Kommunikationspfade dokumentiert sein.
Rationale
Netzwerklatenz addiert sich kumulativ über Service-Hops. In einer Microservices-Architektur können 10 interne Service-Calls mit je 1–2ms Cross-AZ-Overhead bereits 20ms unnötige Latenz erzeugen. Fehlende VPC Endpoints bedeuten, dass Cloud-Service-Traffic (S3, DynamoDB, SSM) das öffentliche Internet passiert – unnötige Latenz und Egress-Kosten. CDN-Fehlen bedeutet, dass statische Assets von Origin geliefert werden – 100–500ms zusätzliche Latenz für internationale Nutzer.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Cross-AZ-Latenz-Akkumulation |
Häufige Service-Calls zwischen AZs akkumulieren Latenz in der Request-Chain. |
Kein VPC Endpoint |
S3/DynamoDB/SSM-Traffic über Internet → erhöhte Latenz + Egress-Kosten. |
Fehlendes CDN |
Statische Assets von Origin geladen → hohe Latenz für internationale Nutzer. |
DNS-Resolution-Overhead |
Fehlende DNS-Caching-Konfiguration → 10–50ms pro DNS-Lookup in hot paths. |
Anforderung
-
CDN MUSS für alle öffentlichen statischen und cachefähigen Inhalte konfiguriert sein
-
VPC Endpoints MÜSSEN für S3, DynamoDB und weitere frequently-accessed Cloud Services existieren
-
Netzwerktopologie MUSS dokumentiert sein (Diagramm mit Service-Placement und Traffic-Routing)
-
CDN-Cache-Hit-Rate MUSS gemessen werden (Ziel: >= 95% für statische Assets)
Implementierungsanleitung
-
Service-Kommunikationsmuster kartieren: Welche Services kommunizieren häufig? Mit welcher Latenz-Anforderung?
-
VPC Endpoints anlegen: Gateway-Endpoints für S3 und DynamoDB; Interface-Endpoints für ECR, SSM, Secrets Manager
-
CDN konfigurieren: CloudFront/Azure CDN/Cloud CDN mit Cache-Policies für statische und dynamische Inhalte
-
AZ-Affinität planen: Häufig kommunizierende Services bevorzugt in derselben AZ
-
Connection Reuse: HTTP/2 und Connection Keepalive für alle Service-zu-Service-Verbindungen
-
Latenz-Baseline messen: RTT zwischen Service-Paaren messen; in Dokument erfassen
-
CDN-Hit-Rate monitoren: CloudFront-Cache-Hit-Rate in CloudWatch; Alert bei < 90% für static
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Kein Topology-Design |
Services ohne Topologie-Überlegungen deployed; kein CDN; keine VPC Endpoints. |
2 |
Basisabsicherung |
CDN für statische Assets; VPC teilweise konfiguriert; keine Latenz-Baseline. |
3 |
Optimierte Topologie |
Vollständige VPC Endpoints; CDN für static + dynamic; AZ-Affinität dokumentiert. |
4 |
Gemessene und verbesserte Topologie |
Latenz-Baseline pro Service-Pair; CDN-Hit-Rate >= 95%; Connection Reuse überall. |
5 |
Intelligentes Routing |
Anycast; Edge-Computing; automatische Topologie-Empfehlungen. |
Terraform Checks
waf-perf-070.tf.aws.vpc-endpoint-s3
Prüft: VPCs mit privaten Subnetzen sollten S3 Gateway VPC Endpoints haben.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: Gateway-Endpoints für S3 und DynamoDB anlegen (kostenlos). Interface-Endpoints für ECR, SSM, Secrets Manager hinzufügen (kostenpflichtig, aber Latenz-Vorteil).
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
IaC |
✅ Pflicht |
Terraform-Konfiguration mit CDN und VPC Endpoints für Cloud-Service-Zugriffe. |
Governance |
✅ Pflicht |
Netzwerktopologie-Diagramm mit Service-Placement, AZ-Verteilung, Traffic-Routing. |
Config |
Optional |
Netzwerk-Latenz-Baseline (Service-zu-Service RTT nach AZ-Kombination). |
Process |
Optional |
CDN-Cache-Hit-Rate-Bericht. |
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 |