AWS Disaster Recovery: RTO, RPO und die 4 Strategien im Vergleich
„Die Cloud ist zuverlässig“ und „unsere Daten sind sicher“ sind zwei verschiedene Sätze. AWS gibt Ihnen außergewöhnliche Bausteine für Resilienz — und keiner davon ist standardmäßig eingeschaltet. Wir entwerfen und betreiben DR-Setups für Kunden, darunter unveränderliche Cross-Account-Backup-Vaults, die gezielt wegen Incidents gebaut wurden, auf die wir reagiert haben; dieser Leitfaden verdichtet diese Felderfahrung auf die Entscheidungen, die wirklich zählen: zwei Zahlen, vier Strategien und die Fehler, die wir immer wieder sehen.
Die zwei Zahlen, die alles bestimmen: RTO und RPO
- RTO (Recovery Time Objective): Wie lange dürfen Sie ausfallen? „Das System muss innerhalb von 4 Stunden wieder da sein“ ist ein RTO von 4 Stunden.
- RPO (Recovery Point Objective): Wie viele Daten können Sie sich zu verlieren leisten? „Höchstens die letzten 15 Minuten“ ist ein RPO von 15 Minuten.
Jede DR-Entscheidung ist ein Preisschild an diesen zwei Zahlen — niedrigere Zahlen kosten mehr, ungefähr exponentiell. Der teuerste Fehler ist nicht, eine langsame Strategie zu wählen; es ist, das Business nie gefragt zu haben, wie die Zahlen tatsächlich lauten. Fragen Sie pro System: Ihre Marketing-Website und Ihre Payment-Pipeline teilen sich kein RTO.
Die 4 AWS-DR-Strategien
| Strategie | Funktionsweise | Typisches RTO | Typisches RPO | Relative Kosten |
|---|---|---|---|---|
| Backup & Restore | Regelmäßige Backups in eine andere Region/einen anderen Account; Neuaufbau im Katastrophenfall | Stunden | Stunden (letztes Backup) | $ — nur Storage |
| Pilot Light | Kerndaten werden kontinuierlich repliziert; minimale Infrastruktur läuft im Leerlauf und wird im Katastrophenfall hochskaliert | Einige zehn Minuten bis Stunden | Minuten | $$ |
| Warm Standby | Eine verkleinerte, aber voll funktionsfähige Kopie läuft dauerhaft; hochskalieren + Traffic umschalten | Minuten | Sekunden bis Minuten | $$$ |
| Multi-Site Active/Active | Volle Kapazität in mehreren Regionen bedient Live-Traffic; ein Ausfall verschiebt nur den Traffic | Nahe null | Nahe null | $$$$ |
Ehrliche Empfehlung: Die meisten Unternehmen brauchen sauber umgesetztes Backup & Restore für die meisten Systeme und Pilot Light oder Warm Standby für das eine oder die zwei Systeme, die wirklich nicht warten können. Multi-Site Active/Active ist für Geschäfte mit Umsatz pro Minute; es für alles einzukaufen, ist der Weg, auf dem DR-Budgets sterben. Infrastructure as Code (siehe unseren Leitfaden zu IaC und GitOps) macht die günstigeren Strategien erst glaubwürdig — „von Grund auf neu aufbauen“ ist nur dann schnell, wenn der Neuaufbau eine Pipeline ist und nicht das Gedächtnis einer Person.
Backups, die den schlechten Tag überleben
Die Strategien oben setzen voraus, dass Ihre Backups existieren, wenn Sie sie brauchen. Drei Regeln aus Incidents, die wir tatsächlich bearbeitet haben:
- Cross-Account, nicht nur Cross-Region. Liegen Backups im selben Account wie die Produktion, löscht ein Angreifer mit Account-Zugriff beides — genau diesen Versuch haben wir gesehen. Ein separater, abgeriegelter Backup-Account mit eigenen Credentials und minimalem Trust ist das einzelne DR-Upgrade mit dem höchsten Wert. Unser Playbook für kompromittierte AWS-Accounts zeigt die Angriffsseite dieses Arguments.
- Unveränderlich, nicht nur kopiert. S3 Object Lock im Compliance-Modus macht Backups für eine festgelegte Aufbewahrungsdauer unlöschbar — für jeden, auch für Root, auch für Ransomware mit Admin-Credentials. Wir betreiben dieses Muster für Kunden in Produktion, gerade weil „der Angreifer hat auch die Backups gelöscht“ ein reales Fehlermuster ist, kein Gedankenexperiment.
- 3-2-1 gilt weiterhin: drei Kopien, zwei verschiedene Systeme, eine außer Haus (in Cloud-Begriffen: ein anderer Account und eine andere Region). Automatisierte RDS-Backups allein sind eine Kopie an einem Ort.
Ein ungetesteter DR-Plan ist eine Hoffnung, kein Plan
Der Restore-Test ist der Plan. Terminieren Sie ihn: vierteljährlich ein Datenbank-Backup auf eine frische Instanz zurückspielen und die Zeit messen; jährlich einen Game Day fahren, der den Verlust der primären Region simuliert. Jedes DR-Dokument, das man uns je in die Hand gedrückt hat, enthielt mindestens einen Schritt, der nicht mehr funktionierte — ein abgelaufenes Credential, eine umbenannte Ressource, ein Runbook, das auf eine Person verweist, die das Unternehmen verlassen hat. Die finden Sie an einem ruhigen Dienstag oder während der Katastrophe; eine dritte Option gibt es nicht.
Die Fehler, die aus Incidents Katastrophen machen
- Backups im Blast Radius — gleicher Account, gleiche Credentials, löschbar durch denselben Angreifer oder dasselbe vertippte Skript.
- RDS-Snapshots, die für einen DR-Plan gehalten werden — sie decken Daten ab, nicht VPC, IAM, DNS, Secrets und Konfiguration, die nötig sind, um tatsächlich Traffic zu bedienen.
- DNS als Nebensache — ein Failover, das unter Druck manuelles Bearbeiten von Records verlangt, addiert eine Stunde auf jedes RTO. Route-53-Failover-Routing mit Health Checks ist günstig.
- Secrets ohne Failover — die Standby-Region ist nutzlos, wenn sich die Anwendung dort nicht authentifizieren kann. Replizieren Sie Secrets bewusst.
- Eine Person besitzt den Plan — lebt das Runbook im Kopf von jemandem, enthält Ihr echtes RTO dessen Urlaubsplan.
Häufige Fragen
Was ist der Unterschied zwischen RTO und RPO?
RTO ist, wie lange die Wiederherstellung dauern darf (Ausfalltoleranz); RPO ist, wie viele aktuelle Daten Sie verlieren dürfen (Backup-/Replikationsfrequenz). Beide werden pro System vom Business festgelegt, und jede DR-Architekturentscheidung bepreist sich gegen sie.
Welche AWS-DR-Strategie sollten wir wählen?
Sauber umgesetztes Backup & Restore für die meisten Systeme, Pilot Light oder Warm Standby für die wenigen, die wirklich nicht Stunden warten können. Wählen Sie pro System anhand realer RTO/RPO, nicht eine Strategie für alles.
Schützen Backups vor Ransomware?
Nur, wenn der Angreifer sie nicht löschen kann: Cross-Account-Isolation plus Unveränderlichkeit per S3 Object Lock ist das Muster, das hält. Löschbare Backups im selben Account versagen genau dann, wenn Sie sie am dringendsten brauchen.
Wie oft sollte DR getestet werden?
Restore-Tests vierteljährlich mit gemessenen Zeiten; ein vollständiger Failover-Game-Day mindestens jährlich. Ein ungetesteter Plan enthält zuverlässig Schritte, die nicht mehr funktionieren.
Fazit
DR ist kein Produkt, das Sie kaufen; es sind zwei Zahlen, die Sie wählen und gegen die Sie dann ehrlich bauen: unveränderliche Cross-Account-Backups als Fundament, die richtige Strategiestufe pro System, DNS und Secrets inklusive, und ein Restore-Test im Kalender. Tun Sie das, und die meisten „Katastrophen“ werden zu Incidents mit Runbook.
Sie möchten Ihre DR-Aufstellung von Leuten prüfen lassen, die das in Produktion betreiben? Backup- und DR-Design ist Teil unserer AWS Managed Services, und das Security Audit (Festpreis €8.000) deckt Backup-Isolation und Unveränderlichkeit unter seinen 98 Prüfpunkten ab. Ein kostenloser Health Scan sagt Ihnen schnell, ob Ihre Backups Ihren schlimmsten Tag überstehen würden.