Multi-Region Disaster Recovery

Dein CEO liest einen AWS-Blogpost und fragt: “Können wir Multi-Region machen?” Du sagst ja, weil du kannst. Sechs Monate und 120.000$ später habt ihr ein Multi-Region Setup das ihr nie getestet habt, das niemand im Team vollständig versteht, und das bei einem echten Ausfall wahrscheinlich nicht funktioniert.

Das ist nicht übertrieben. Das passiert häufiger als man denkt.

Das Whitepaper verspricht viel

AWS hat ein Whitepaper: “Disaster Recovery of Workloads on AWS: Recovery in the Cloud.” Es beschreibt vier Strategien: Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active-Active. Jede mit schönen Architekturdiagrammen und Pfeilchen.

Was das Whitepaper nicht beschreibt: die realen Kosten, die Team-Komplexität und die Failure Modes die du dir einhandelst.

Klick durch die Strategien und schau dir an, was jede kostet und was du dafür bekommst:

Siehst du den Sprung von Warm Standby auf Active-Active? 1.6x auf 2.3x Kosten. Und der RTO-Unterschied? 15 Minuten vs unter 1 Minute. Für die meisten Services sind 15 Minuten Downtime pro Jahr akzeptabel. Active-Active löst ein Problem das du wahrscheinlich nicht hast.

Die versteckten Kosten

Das Whitepaper listet AWS-Services auf: Aurora Global Database, Route53 Health Checks, Global Accelerator. Was es nicht listet:

Team-Komplexität. Multi-Region Deployments bedeuten zwei CI/CD Pipelines, zwei Sets von Umgebungsvariablen, Region-spezifische Configs, Cross-Region IAM Roles. Jedes Deployment wird doppelt so komplex. Bei jedem Debugging fragt man sich: “Welche Region?”

Data Consistency. Aurora Global Database hat bis zu 1 Sekunde Replication Lag. Eine Sekunde. Wenn ein User in eu-west-1 schreibt und sofort in eu-central-1 liest, sieht er den alten Wert. Eventual Consistency über Regions ist kein theoretisches Problem, es ist ein konkretes: der Kunde sieht seine Bestellung nicht.

Failover-Testing. Dein Multi-Region Setup ist nur so gut wie dein letzter Failover-Test. Wann hast du den zuletzt gemacht? AWS empfiehlt monatlich. Die meisten Teams machen es nie. Und wenn sie es machen, bricht es. Weil sich in den letzten 6 Monaten die Datenbank-Config geändert hat, oder ein neuer Service nicht in der zweiten Region deployed wurde, oder die DNS-Propagation 10 Minuten statt 30 Sekunden dauert.

async function isRegionHealthy(region: string): Promise<boolean> {
  try {
    // Nicht nur ping  echte Transaktionen testen
    const start = Date.now();

    // DB write + read
    await db.query("INSERT INTO health_check (ts) VALUES (NOW())");
    const result = await db.query(
      "SELECT ts FROM health_check ORDER BY ts DESC LIMIT 1",
    );

    // Cache read + write
    await redis.set("health:check", Date.now().toString());
    await redis.get("health:check");

    // External dependency
    await fetch(`https://api.payment-provider.com/health`);

    const latency = Date.now() - start;
    return latency < 5000; // 5s Threshold
  } catch {
    return false;
  }
}

Und selbst dieser Check testet nicht alles. Er testet nicht ob dein Kafka Consumer in der zweiten Region die richtige Offset-Position hat. Er testet nicht ob deine Feature Flags in beiden Regions synchron sind. Er testet nicht ob dein CDN-Invalidation Cross-Region funktioniert.

Mein Vorschlag: Multi-AZ first

Für 95% der Workloads reicht Multi-AZ in einer Region:

• RDS Multi-AZ: automatisches Failover in < 60 Sekunden
• ECS/EKS über 3 AZs: ein AZ stirbt, Traffic geht an die anderen
• S3: automatisch über AZs repliziert
• ElastiCache Multi-AZ: automatisches Failover

Das kostet 10-30% mehr als Single-AZ. Nicht 130% wie Active-Active Multi-Region. Und es deckt den häufigsten Failure-Mode ab: ein einzelner AZ-Ausfall.

Multi-Region kommt in Frage wenn:

1. Du regulatorische Anforderungen hast (Daten müssen in bestimmter Region bleiben UND das System muss trotzdem verfügbar sein)
2. Dein Business 5 Minuten Downtime pro Jahr nicht toleriert (und du das Budget für 2.3x Kosten hast)
3. Du ein Team hast das Failover-Tests monatlich durchführen kann

Wenn keins davon zutrifft: spar dir das Geld. Multi-AZ, gute Backups, ein getesteter Recovery-Plan. Das bringt dich von 99.9% auf 99.95%. Für 99.99% zahlst du exponentiell mehr, und brauchst ein Team das exponentiell mehr kann.