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

WAF-REL-030 – Multi-AZ High Availability Deployment

Pillar: Reliability | Severity: High | Kategorie: High Availability | Automatisierbar: Hoch

Beschreibung

Alle Produktions-Workloads MÜSSEN über mindestens 2 Availability Zones verteilt sein. Single-AZ-Deployments in Produktion sind ohne schriftliche Risk Acceptance nicht zulässig. Datenbanken MÜSSEN Multi-AZ mit automatischem Failover konfigurieren. Kubernetes MUSS Topology Spread Constraints zur AZ-Verteilung verwenden.

Rationale

AZ-Ausfälle sind der häufigste cloud-infrastrukturelle Störungstyp. Ein System in einer einzigen AZ erleidet bei einem AZ-Ereignis 100% Ausfall. Der Kostenzuwachs für Multi-AZ ist im Vergleich zu einem einzelnen Produktionsausfall vernachlässigbar. Multi-AZ ist der absolute Mindeststandard für produktive High-Availability-Systeme.

Bedrohungskontext

Risiko Beschreibung

AZ-Ausfall = Totalausfall

Single-AZ Deployment: Jede AZ-Störung führt zu vollständigem Service-Ausfall.

Datenbank Single Point of Failure

Single-AZ RDS: Bei AZ-Ausfall ist Datenbank stundenlang nicht erreichbar.

Kubernetes Pod-Konzentration

Ohne Topology Spread landen alle Pods in einer AZ: Single-Pod-Klasse als SPOF.

Automatisches Failover fehlt

Multi-AZ konfiguriert, aber Failover nicht automatisch → manuelle Intervention bei AZ-Ausfall.

Anforderung

  • Alle Produktions-Compute-Ressourcen: mindestens 2 AZs

  • Auto Scaling Groups: min_size >= 2, Subnets in min. 2 AZs

  • Alle Produktionsdatenbanken: Multi-AZ mit automatischem Failover

  • Kubernetes: topologySpreadConstraints mit Zone-Key konfiguriert

  • Load Balancer: Subnets in min. 2 AZs

Implementierungsanleitung

  1. ASG Subnets: vpc_zone_identifier mit Subnets aus min. 2 AZs

  2. ASG Min Size: min_size = 2 – eine Instanz kann AZ-Ausfall nicht überstehen

  3. RDS Multi-AZ: multi_az = true – synchrone Replikation, Auto Failover < 2 Minuten

  4. ElastiCache: Multi-AZ Replication Group mit automatic_failover_enabled = true

  5. Kubernetes: topologySpreadConstraints.topologyKey = topology.kubernetes.io/zone

  6. AZ-Failover testen: Instanzen in einer AZ terminieren und Recovery beobachten

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Single-AZ

Alle Ressourcen in einer AZ; keine Redundanz.

2

DB Multi-AZ

Datenbanken Multi-AZ; Compute noch Single-AZ.

3

Vollständig Multi-AZ

Alles in min. 2 AZs; LB und ASG multi-AZ konfiguriert; AZ-Test quartalsweise.

4

Auto-Failover getestet

Automatischer Failover dokumentiert und gemessen; Kubernetes Topology Spread erzwungen.

5

Multi-Region

Kritische Workloads multi-regional; Global Load Balancing mit Auto-Region-Failover.

Terraform Checks

waf-rel-030.tf.aws.rds-multi-az

Prüft: RDS Instance hat multi_az = true und deletion_protection = true.

Compliant Non-Compliant 
resource "aws_db_instance" "main" {
  identifier        = "payment-db-prod"
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  allocated_storage = 100
  multi_az          = true
  deletion_protection = true
  db_subnet_group_name =
    aws_db_subnet_group.main.name
}
 
resource "aws_db_instance" "main" {
  identifier        = "payment-db-prod"
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  allocated_storage = 100
  multi_az          = false
  # WAF-REL-030 Violation
}

Remediation: multi_az = true und deletion_protection = true auf der aws_db_instance Ressource setzen.

Evidenz

Typ Pflicht Beschreibung

IaC

✅ Pflicht

Terraform mit Multi-AZ-Konfiguration für Compute, DB und Load Balancer.

Config

✅ Pflicht

Cloud Console oder IaC zeigt min. 2 AZs je Produktionsressource.

Process

Optional

AZ-Failover-Testbericht mit gemessener Recovery-Zeit.

Verwandte Controls

Best Practice