RTO, RPO und DR-Stufen

Das Recovery Time Objective (RTO) ist die maximal akzeptable Zeitspanne vom Eintritt einer Katastrophe bis zur Wiederherstellung des Systembetriebs. Beträgt Ihr RTO 4 Stunden, kann Ihr Unternehmen 4 Stunden Ausfallzeit tolerieren. Das Recovery Point Objective (RPO) ist der maximal akzeptable Datenverlust, gemessen als Zeitspanne. Bei einem RPO von 1 Stunde müssen Sie einen Wiederherstellungspunkt erreichen können, der höchstens 1 Stunde vor der Katastrophe liegt. Beide Kennzahlen werden durch Geschäftsanforderungen und nicht durch technische Präferenzen festgelegt.

AWS definiert vier grundlegende Disaster-Recovery-Strategien, geordnet von den niedrigsten Kosten und dem höchsten RTO bis zu den höchsten Kosten und dem niedrigsten RTO: 1) Backup and Restore – am günstigsten, RTO von mehreren Stunden. 2) Pilot Light – ein minimaler Kern läuft ständig, RTO von Minuten bis Stunden. 3) Warm Standby – verkleinert, aber funktionsfähig, RTO von wenigen Minuten. 4) Multi-Site Active-Active – am teuersten, nahezu kein RTO. Ihre Wahl hängt vom geschäftlichen Ausfallkostenrisiko im Verhältnis zu den Kosten der DR-Infrastruktur ab.

Bei Backup and Restore erstellen Sie regelmäßig Snapshots Ihrer Daten und speichern sie an einem anderen Ort (z. B. in S3 mit regionsübergreifender Replikation). Im Katastrophenfall stellen Sie die Daten aus dem aktuellsten Backup wieder her. Dies ist die günstigste Strategie, da keine Standby-Infrastruktur betrieben wird. Der Nachteil sind das längste RTO (mehrere Stunden zur Wiederherstellung großer Datenbanken aus Snapshots) und das höchste RPO (Daten seit dem letzten Backup gehen verloren). AWS Backup automatisiert Snapshot-Zeitpläne für EC2, RDS, EFS, DynamoDB und weitere Services.

Die Pilot-Light-Strategie hält die Kernkomponenten Ihres Systems in einer DR-Region mit minimaler Kapazität am Laufen – wie eine Zündflamme, die schnell zu einer vollständigen Flamme entfacht werden kann. Typischerweise bedeutet dies, dass Ihre Datenbank kontinuierlich in die DR-Region repliziert wird und eine grundlegende Netzwerkinfrastruktur (VPC, Subnetze, Sicherheitsgruppen) vorhanden ist. Anwendungsserver laufen NICHT, können aber schnell aus vorbereiteten AMIs oder Startvorlagen gestartet werden. Das RTO beträgt je nach erforderlichem manuellen Aufwand typischerweise 30 Minuten bis mehrere Stunden.

Bei der Warm-Standby-Strategie läuft in der DR-Region eine vollständig funktionsfähige, verkleinerte Kopie Ihrer Produktionsumgebung. Anders als bei Pilot Light läuft die Anwendungsebene bereits (beispielsweise mit 1–2 statt 20 Instanzen), und die Datenbank ist eine sekundäre Aurora Global Database oder ein RDS Read Replica. Während des Failovers skalieren Sie die DR-Umgebung auf die Kapazität der Produktionsumgebung hoch. Das RTO beträgt typischerweise weniger als 15 Minuten. Dies ist die häufigste DR-Strategie für Workloads mit mittlerer bis hoher Kritikalität.

Multi-Site Active-Active betreibt die vollständige Produktionskapazität gleichzeitig in zwei oder mehr Regionen. Alle Regionen bedienen Live-Datenverkehr, und Daten werden nahezu in Echtzeit (oder im Multi-Master-Verfahren) repliziert. Es gibt keine Verzögerung durch ein Failover: Wenn eine Region ausfällt, leiten Route 53 oder Global Accelerator den gesamten Datenverkehr sofort an die verbleibenden fehlerfreien Regionen weiter. Dies bietet das niedrigste RTO und RPO, verursacht aber auch die höchsten Kosten, da Sie jederzeit in allen Regionen die vollständige Produktionskapazität bezahlen.

Ihr RPO bestimmt direkt, welche Replikationstechnologie Sie benötigen. RPO = 0 erfordert synchrone Replikation – es geht nichts verloren. Für ein RPO im Sekundenbereich benötigen Sie eine asynchrone Replikation nahezu in Echtzeit, beispielsweise Aurora Global Database (<1 s Verzögerung). Ein RPO im Minutenbereich ermöglicht asynchrone Replikation mit geringer Verzögerung (DynamoDB Streams, RDS Read Replicas). Ein RPO im Stundenbereich lässt sich mit regelmäßigen Snapshots erreichen (stündlicher Zeitplan von AWS Backup). Legen Sie Ihre geschäftliche RPO-Anforderung eindeutig fest, bevor Sie eine Technologie auswählen.

Serverlose Architekturen (Lambda, DynamoDB, API Gateway) sind von Natur aus ausfallsicherer, benötigen aber dennoch eine DR-Planung. DynamoDB Global Tables ermöglicht Active-Active über mehrere Regionen für die Datenbankebene. Lambda kann aus derselben CI/CD-Pipeline in einer zweiten Region bereitgestellt werden. API Gateway sollte in der DR-Region bereitgestellt werden. Das größte Risiko ist eine Konfigurationsabweichung zwischen den Regionen. Verwenden Sie AWS CDK oder Terraform, um aus derselben Codebasis in beiden Regionen eine identische Infrastruktur bereitzustellen.

Betrachten Sie ein Unternehmen mit einem Jahresumsatz von 10 Mio. $. Wenn eine Ausfallminute 1.000 $ kostet, verursacht ein 8-stündiger Ausfall (RTO = 8 h) Kosten in Höhe von 480.000 $. Ein aktives passives Warm Standby mit einem RTO von 15 Minuten reduziert den potenziellen Verlust pro Vorfall auf 15.000 $. Kostet das Standby-System 5.000 $ pro Monat (60.000 $ pro Jahr), ist es wirtschaftlich nur dann sinnvoll, wenn mehr als ein erheblicher Ausfall pro Jahr auftritt. Eine solche Kosten-Nutzen-Analyse sollen Sie in der SAA-C03-Prüfung bei der Auswahl von DR-Strategien durchführen.

Ein DR-Plan, der noch nie getestet wurde, ist lediglich ein Dokument. AWS empfiehlt dringend regelmäßige DR-Übungen: Üben Sie Failover-Verfahren, messen Sie das tatsächliche RTO und RPO und identifizieren Sie Lücken. Verwenden Sie den AWS Fault Injection Simulator (FIS), um eine regionale Verschlechterung kontrolliert zu simulieren. Dokumentieren Sie Runbooks für die Failover-Schritte, damit das Bereitschaftsteam unter dem Stress eines echten Vorfalls einem klaren, getesteten Verfahren folgt, statt zu improvisieren.

Viele Branchen haben regulatorische Anforderungen an DR. PCI DSS verlangt dokumentierte DR-Pläne und deren Erprobung. HIPAA verlangt Verfahren für Datensicherung und Disaster Recovery. SOC 2 bewertet Verfügbarkeitskontrollen einschließlich DR. Verwenden Sie AWS Config und AWS Audit Manager, um kontinuierlich zu prüfen und zu dokumentieren, dass Ihre DR-Ressourcen (Backups, Replikate, Zustandsprüfungen) korrekt konfiguriert sind. Dadurch erhalten Sie Nachweise für Compliance-Audits, ohne diese manuell zusammentragen zu müssen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: RTO ist die maximal akzeptable Ausfallzeit und RPO ist der maximal akzeptable Datenverlust, die vier DR-Stufen stellen ein Gleichgewicht zwischen Kosten und Wiederherstellungsgeschwindigkeit her und Ihre RPO-Anforderung bestimmt, welche Replikationstechnologie Sie verwenden. Testen Sie Ihren DR-Plan immer, um das tatsächliche RTO und RPO zu überprüfen. Als Nächstes sehen wir uns die Strategie „Backup und Wiederherstellung“ im Detail an.