# REL 13. Was ist bei der Planung der Notfallwiederherstellung zu beachten?
Backups und redundante Workload-Komponenten sind der Ausgangspunkt Ihrer Strategie für die Notfallwiederherstellung. [RTO und RPO sind Ihre Ziele](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) für die Wiederherstellung Ihres Workloads. Legen Sie diese entsprechend den geschäftlichen Anforderungen fest. Implementieren Sie eine Strategie, um diese Ziele zu erreichen. Berücksichtigen Sie dabei Standorte und Funktionen von Workload-Ressourcen und -Daten. Die Wahrscheinlichkeit von Disruptionen und die Kosten von Wiederherstellungen sind ebenfalls wichtige Faktoren bei der Ermittlung des Unternehmenswerts, den Notfallwiederherstellungen von Workloads bieten.
**Topics**
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Verwalten der Konfigurationsabweichungen am Standort oder in der Region der Notfallwiederherstellung:](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05: Automatisieren der Wiederherstellung](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:
Für die Workload gelten ein Recovery Time Objective (RTO, Wiederherstellungsdauer) und ein Recovery Point Objective (RPO, Wiederherstellungszeitpunkt).
*Die Wiederherstellungsdauer* ist die maximal akzeptable Verzögerung zwischen der Unterbrechung und der Wiederherstellung des Service. Damit wird festgelegt, was als akzeptables Zeitfenster gilt, wenn der Service nicht verfügbar ist.
*Der Wiederherstellungszeitpunkt* ist die maximal zulässige Zeitspanne seit dem letzten Wiederherstellungspunkt. Damit wird festgelegt, was als akzeptabler Datenverlust zwischen dem letzten Wiederherstellungspunkt und der Service-Unterbrechung gilt.
RTO- und RPO-Werte sind wichtige Überlegungen bei der Auswahl einer geeigneten Notfallwiederherstellungsstrategie (Disaster Recovery, DR) für Ihre Workload. Diese Ziele werden vom Unternehmen festgelegt und dann von den technischen Teams zur Auswahl und Umsetzung einer DR-Strategie verwendet.
**Gewünschtes Ergebnis:**
Jeder Workload sind ein RTO und ein RPO zugewiesen, die auf der Grundlage der geschäftlichen Auswirkungen definiert werden. Die Workload wird einer vordefinierten Stufe zugewiesen, die die Serviceverfügbarkeit und den akzeptablen Datenverlust mit einem entsprechenden RTO und RPO definiert. Wenn eine solche Einstufung nicht möglich ist, kann die Zuweisung individuell pro Workload erfolgen, mit der Absicht, zu einem späteren Zeitpunkt Stufen zu erstellen. RTO und RPO werden als eine der Hauptüberlegungen für die Auswahl einer Notfallwiederherstellungsstrategie für die Workload verwendet. Weitere Überlegungen bei der Auswahl einer DR-Strategie sind Kostenbeschränkungen, Abhängigkeiten von der Workload und betriebliche Anforderungen.
Bei der RTO sind die Auswirkungen anhand der Dauer eines Ausfalls zu verstehen. Ist sie linear oder gibt es nichtlineare Auswirkungen? (Beispiel: Nach vier Stunden wird eine Fertigungsstraße bis zum Beginn der nächsten Schicht stillgelegt.)
Eine Matrix der Notfallwiederherstellung wie die folgende kann Ihnen helfen zu verstehen, wie die Kritikalität der Workload mit den Wiederherstellungszielen zusammenhängt. (Beachten Sie, dass die tatsächlichen Werte für die X- und Y-Achsen an die Bedürfnisse Ihres Unternehmens angepasst werden sollten.)
![\[Diagramm, das die Matrix der Notfallwiederherstellung zeigt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/disaster-recovery-matrix.png)
**Gängige Antimuster:**
+ Keine definierten Wiederherstellungsziele.
+ Auswählen beliebiger Wiederherstellungsziele.
+ Auswählen von Wiederherstellungszielen, die zu lasch sind und die Geschäftsziele nicht erfüllen.
+ Kein Verständnis des Auswirkung von Ausfallzeiten und Datenverlust.
+ Auswahl unrealistischer Wiederherstellungsziele, wie z. B. Null-Zeit bis zur Wiederherstellung und Null-Datenverlust, die für Ihre Workload-Konfiguration möglicherweise nicht erreicht werden können.
+ Auswählen von Wiederherstellungszielen, die strikter sind als die tatsächlichen Geschäftsziele. Dies erzwingt Implementierungen für die Notfallwiederherstellung, die kostspieliger und komplizierter sind als die Anforderungen der Workload.
+ Auswahl von Wiederherstellungszielen, die mit denen einer abhängigen Workloads unvereinbar sind.
+ Ihre Wiederherstellungsziele berücksichtigen nicht die Einhaltung gesetzlicher Vorschriften.
+ RTO und RPO sind für eine Workload definiert, aber nie getestet.
**Vorteile der Einführung dieser bewährten Methode:** Die Wiederherstellungsziele für Dauer und Datenverlust sind als Orientierungshilfe für die Implementierung der Notfallwiederherstellung erforderlich.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Bei der gegebenen Workload müssen Sie die Auswirkungen von Ausfallzeiten und Datenverlusten auf Ihr Unternehmen verstehen. Die Auswirkungen werden in der Regel mit zunehmender Ausfallzeit oder Datenverlust größer, aber die Form dieses Anstiegs kann je nach Art der Workload unterschiedlich sein. So können Sie z. B. Ausfallzeiten bis zu einer Stunde ohne größere Beeinträchtigung tolerieren, danach steigen die Auswirkungen jedoch schnell an. Die Auswirkungen auf das Unternehmen zeigen sich in vielen Formen, darunter monetäre Kosten (z. B. entgangene Einnahmen), Kundenvertrauen (und Auswirkungen auf den Ruf), betriebliche Probleme (z. B. fehlende Gehaltsabrechnungen oder verringerte Produktivität) und gesetzliche Risiken. Führen Sie die folgenden Schritte aus, um diese Auswirkungen zu verstehen und RTO und RPO für Ihre Workload festzulegen.
**Implementierungsschritte**
1. Bestimmen Sie die Interessengruppen Ihres Unternehmens für diese Workload und arbeiten Sie mit ihnen zusammen, um diese Schritte umzusetzen. Die Wiederherstellungsziele für eine Workload sind eine geschäftliche Entscheidung. Die technischen Teams arbeiten dann mit den Business-Stakeholdern zusammen, um anhand dieser Ziele eine DR-Strategie auszuwählen.
**Anmerkung**
Für die Schritte 2 und 3 können Sie Folgendes verwenden: [Implementierungsarbeitsblatt](#implementation-worksheet).
1. Sammeln Sie die notwendigen Informationen, um eine Entscheidung zu treffen, indem Sie die folgenden Fragen beantworten.
1. Gibt es in Ihrem Unternehmen Kategorien oder Stufen der Kritikalität für die Auswirkungen von Workloads?
1. Falls zutreffend, ordnen Sie diese Workload einer Kategorie zu.
1. Falls nicht zutreffend, richten Sie diese Kategorien ein. Legen Sie fünf oder weniger Kategorien fest und verfeinern Sie die Spanne der angestrebten Wiederherstellungszeit für jede Kategorie. Zu den Beispielkategorien gehören: kritisch, hoch, mittel, niedrig. Um zu verstehen, wie sich Workloads den Kategorien zuordnen lassen, sollten Sie prüfen, ob die Workload unternehmenskritisch, geschäftswichtig oder nicht geschäftsrelevant ist.
1. Legen Sie RTO und RPO für die Workload je nach Kategorie fest. Wählen Sie immer eine Kategorie, die strikter ist (niedrigere RTO- und RPO-Werte) als die bei der Eingabe dieses Schritts berechneten Rohwerte. Wenn dies zu einer unangemessen großen Veränderung des Wertes führt, sollten Sie eine neue Kategorie anlegen.
1. Weisen Sie auf der Grundlage dieser Antworten der Workload RTO- und RPO-Werte zu. Dies kann direkt geschehen oder durch Zuweisung der Workload zu einer vordefinierten Serviceebene.
1. Dokumentieren Sie den Notfallwiederherstellungsplan (Disaster Recovery Plan, DRP) für diese Workload, der Teil der Unternehmensstrategie ist. [Betriebskontinuitätsplan (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)an einem Ort, der für das Workload-Team und die Stakeholder zugänglich ist
1. Halten Sie die RTO- und RPO-Werte sowie die zur Ermittlung dieser Werte verwendeten Informationen fest. Geben Sie eine Strategie zur Bewertung der Auswirkungen der Workload auf das Unternehmen an.
1. Erfassen Sie neben RTO und RPO auch andere Metriken, die Sie für Notfallwiederherstellungsziele verfolgen oder zu verfolgen planen
1. Sie fügen diesem Plan Details zu Ihrer DR-Strategie und Ihrem Runbook hinzu, wenn Sie diese erstellen.
1. Indem Sie die Kritikalität der Workload in einer Matrix wie der in Abbildung 15 nachschlagen, können Sie damit beginnen, vordefinierte Serviceebenen für Ihr Unternehmen festzulegen.
1. Nachdem Sie eine DR-Strategie (oder einen Machbarkeitsnachweis für eine DR-Strategie) gemäß implementiert haben,[REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)testen Sie diese Strategie, um die tatsächliche RTC (Recovery Time Capability) und RPC (Recovery Point Capability) der Workload zu bestimmen. Wenn diese nicht den angestrebten Wiederherstellungszielen entsprechen, arbeiten Sie entweder mit Ihren Stakeholdern zusammen, um diese Ziele anzupassen, oder nehmen Sie Änderungen an der DR-Strategie vor, um die Zielvorgaben zu erreichen.
**Primäre Fragen**
1. Wie lange kann die Workload maximal ausfallen, bevor es zu schwerwiegenden Auswirkungen auf das Unternehmen kommt?
1. Bestimmen Sie die monetären Kosten (direkte finanzielle Auswirkungen) für das Unternehmen pro Minute, wenn die Workload unterbrochen wird.
1. Bedenken Sie, dass die Auswirkungen nicht immer linear sind. Die Auswirkungen können zunächst begrenzt sein und dann ab einem kritischen Zeitpunkt rasch zunehmen.
1. Wie groß ist die maximale Datenmenge, die verloren gehen kann, bevor es zu schwerwiegenden Auswirkungen auf das Unternehmen kommt?
1. Berücksichtigen Sie diesen Wert für Ihren wichtigsten Datenspeicher. Identifizieren Sie die jeweilige Kritikalität für andere Datenspeicher.
1. Können Workload-Daten bei Verlust wiederhergestellt werden? Wenn dies aus betrieblicher Sicht einfacher ist als Backup und Wiederherstellung, dann wählen Sie das RPO auf der Grundlage der Kritikalität der Ursprungsdaten, die zur Wiederherstellung der Workload-Daten verwendet werden.
1. Wie lauten die Wiederherstellungsziele und Verfügbarkeitserwartungen von Workloads, von denen dieser abhängt (Downstream), oder von Workloads, die von diesem abhängen (Upstream)?
1. Wählen Sie Wiederherstellungsziele, die es dieser Workload ermöglichen, die Anforderungen der vorgelagerten Abhängigkeiten zu erfüllen
1. Wählen Sie Wiederherstellungsziele, die angesichts der Wiederherstellungsmöglichkeiten der nachgelagerten Abhängigkeiten erreichbar sind. Unkritische nachgelagerte Abhängigkeiten (die Sie „umgehen“ können) können ausgeschlossen werden. Oder arbeiten Sie mit kritischen, nachgelagerten Abhängigkeiten zusammen, um deren Wiederherstellungsmöglichkeiten zu verbessern.
**Weitere Fragen**
Überlegen Sie sich, wie diese Fragen auf diese Workload zutreffen könnten:
1. Haben Sie unterschiedliche RTO und RPO je nach Art des Ausfalls (Region vs. Region)? AZ, etc.)?
1. Gibt es einen bestimmten Zeitpunkt (Saisonabhängigkeit, Verkaufsveranstaltungen, Produkteinführungen), zu dem sich Ihr RTO/RPO ändern kann? Wenn ja, was ist die unterschiedliche Messung und die zeitliche Begrenzung?
1. Wie viele Kunden sind von einer Unterbrechung der Workload betroffen?
1. Welche Auswirkungen hat es auf den Ruf, wenn die Workload unterbrochen wird?
1. Welche anderen betrieblichen Auswirkungen können auftreten, wenn die Workload unterbrochen wird? Zum Beispiel Auswirkungen auf die Produktivität der Mitarbeiter, wenn die E-Mail-Systeme nicht verfügbar sind oder wenn die Lohnbuchhaltungssysteme keine Transaktionen übermitteln können.
1. Wie stimmen RTO und RPO der Workload mit der DR-Strategie der Geschäftsbereiche und des Unternehmens überein?
1. Gibt es interne vertragliche Verpflichtungen für die Erbringung einer Dienstleistung? Gibt es Strafen für die Nichteinhaltung dieser Vorgaben?
1. Welche rechtlichen oder Compliance-Bedingungen gelten für die Daten?
## Implementierungsarbeitsblatt
Sie können dieses Arbeitsblatt für die Implementierungsschritte 2 und 3 verwenden. Sie können dieses Arbeitsblatt an Ihre speziellen Bedürfnisse anpassen, indem Sie beispielsweise zusätzliche Fragen hinzufügen.
![\[Arbeitsblatt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/worksheet.png)
**Grad des Aufwands für den Implementierungsplan: **Niedrig
## Ressourcen
**Ähnliche bewährte Methoden:**
+ [REL09-BP04 Verifizieren der Sicherungsintegrität und -verfahren durch regelmäßiges Wiederherstellen der Daten](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:](rel_planning_for_recovery_dr_tested.md)
**Zugehörige Dokumente:**
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Verwalten von Ausfallsicherheit mit AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Relevante Videos**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
+ [Notfallwiederherstellung von Workloads auf AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen
Definieren Sie eine Notfallwiederherstellungsstrategie (Disaster Recovery, DR), die den Wiederherstellungszielen Ihrer Workloads entspricht. Wählen Sie eine Strategie aus, z. B. Backup und Wiederherstellung, Standby (aktiv/passiv) oder Aktiv/Aktiv.
**Gewünschtes Ergebnis:** Für jeden Workload gibt es eine definierte und implementierte Notfallwiederherstellungsstrategie, die dem Workload das Erreichen der Notfallwiederherstellungsziele ermöglicht. DR-Strategien zwischen Workloads nutzen wiederverwendbare Muster (wie die zuvor beschriebenen Strategien),
**Typische Anti-Muster:**
+ Implementierung von inkonsistenten Wiederherstellungsprozeduren für Workloads mit ähnlichen DR-Zielen.
+ Die DR-Strategie muss im Notfall Ad-hoc umgesetzt werden.
+ Es gibt keinen Plan für die Notfallwiederherstellung.
+ Abhängigkeit von Vorgängen auf der Steuerebene während der Wiederherstellung.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Durch die Nutzung definierter Wiederherstellungsstrategien können Sie verbreitet verwendete Tools und Testverfahren verwenden.
+ Die Verwendung definierter Wiederherstellungsstrategien verbessert den Wissensaustausch zwischen den Teams und die Implementierung der Notfallwiederherstellung für ihre Workloads.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** hoch. Ohne eine geplante, implementierte und getestete DR-Strategie ist es unwahrscheinlich, dass Sie Ihre Wiederherstellungsziele im Falle eines Notfalls erreichen.
## Implementierungsleitfaden
Eine DR-Strategie beruht auf der Fähigkeit, Ihre Workload an einem Wiederherstellungsstandort bereitzustellen, wenn Ihr primärer Standort nicht mehr in der Lage ist, den Workload auszuführen. Die häufigsten Wiederherstellungsziele sind RTO und RPO, wie besprochen in [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md).
Eine DR-Strategie, die mehrere Availability Zones (AZs) innerhalb eines einzigen AWS-Region umfasst, kann Katastrophenereignisse wie Brände, Überschwemmungen und größere Stromausfälle abfedern. Wenn es erforderlich ist, einen Schutz gegen ein unwahrscheinliches Ereignis zu implementieren, das verhindert, dass Ihre Workload in einer bestimmten AWS-Region ausgeführt werden kann, können Sie eine DR-Strategie verwenden, die mehrere Regionen nutzt.
Wenn Sie eine DR-Strategie für mehrere Regionen entwickeln, sollten Sie eine der folgenden Strategien wählen. Sie werden nach zunehmenden Kosten und zunehmender Komplexität und abnehmender RTO und RPO aufgelistet. Die *Wiederherstellungsregion* verweist auf eine andere AWS-Region als die für Ihren Workload verwendete primäre Region.
![\[Diagramm der DR-Strategien\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/disaster-recovery-strategies.png)
+ **Backup und Wiederherstellung** (RPO im Stundenbereich, RTO innerhalb von 24 Stunden oder weniger): Sichern Sie Ihre Daten und Anwendungen in der Wiederherstellungsregion. Die Verwendung automatisierter oder kontinuierlicher Backups ermöglicht eine zeitpunktgenaue Wiederherstellung, wodurch das RPO in einigen Fällen auf bis zu 5 Minuten gesenkt werden kann. Im Falle eines Notfalls stellen Sie Ihre Infrastruktur bereit (wobei Sie Infrastruktur als Code verwenden, um die RTO zu verkürzen), stellen Ihren Code bereit und stellen die gesicherten Daten wieder her, um eine Wiederherstellung nach einem Notfall in der Wiederherstellungsregion zu erfahren.
+ **Pilot-Light** (RPO im Minutenbereich, RTO innerhalb von zehn Minuten): Bereitstellung einer Kopie Ihrer Core-Workload-Infrastruktur in der Wiederherstellungsregion. Replizieren Sie Ihre Daten in die Wiederherstellungsregion und erstellen Sie dort Sicherungskopien der Daten. Ressourcen, die zur Unterstützung der Datenreplikation und -sicherung erforderlich sind, wie Datenbanken und Objektspeicher, sind immer eingeschaltet. Andere Elemente wie Anwendungsserver oder Serverless Compute werden nicht bereitgestellt, sondern können bei Bedarf mit der erforderlichen Konfiguration und dem Anwendungscode erstellt werden.
+ **Warm-Standby** (RPO im Sekundenbereich, RTO im Minutenbereich): Aufrechterhaltung einer herunterskalierten, aber voll funktionsfähigen Version Ihres Workloads, die immer in der Wiederherstellungsregion ausgeführt wird. Geschäftskritische Systeme sind vollständig dupliziert und ständig aktiv, aber mit herunterskalierter Infrastruktur. Die Daten werden repliziert und sind in der Wiederherstellungsregion live. Wenn eine Wiederherstellung erforderlich ist, wird das System zur Bewältigung der Produktionslast schnell hochskaliert. Je höher die Skalierung des Warm-Standby, desto geringer ist die Abhängigkeit von RTO und Steuerebene. Bei einer vollständigen Abdeckung spricht man von *Hot-Standby*.
+ **Multi-Region (Multi-Site) Aktiv/Aktiv** (RPO nahe Null, RTO potenziell Null): Ihr Workload wird an mehreren AWS-Regionen-Standorten bereitgestellt und bedient aktiv den Datenverkehr von diesen. Bei dieser Strategie müssen Sie die Daten zwischen den Regionen synchronisieren. Mögliche Konflikte, die durch Schreibvorgänge auf denselben Datensatz in zwei verschiedenen regionalen Repliken verursacht werden, müssen vermieden oder behandelt werden, was sehr komplex sein kann. Die Datenreplikation ist nützlich für die Datensynchronisation und schützt Sie vor einigen Arten von Notfällen, aber sie schützt Sie nicht vor Datenbeschädigung oder -zerstörung, es sei denn, Ihre Lösung umfasst auch Optionen für eine zeitpunktgenaue Wiederherstellung.
**Anmerkung**
Der Unterschied zwischen Pilot-Light und Warm-Standby kann schwer zu überblicken sein. Beide beinhalten eine Umgebung in Ihrer Wiederherstellungsregion mit Kopien der Assets Ihrer Primärregion. Der Unterschied besteht darin, dass Pilot-Light keine Anfragen bearbeiten kann, ohne dass zuvor zusätzliche Maßnahmen ergriffen werden, während Warm-Standby den Datenverkehr (mit reduzierter Kapazität) sofort bearbeiten kann. Bei Pilot-Light müssen Sie die Server einschalten, möglicherweise zusätzliche (nicht zum Kerngeschäft gehörende) Infrastruktur bereitstellen und die Leistung hochskalieren, während Sie bei Warm-Standby nur die Leistung hochskalieren müssen (alles ist bereits bereitgestellt und läuft). Wählen Sie je nach RTO- und RPO-Anforderungen zwischen diesen Varianten.
Wenn die Kosten eine Rolle spielen und Sie ähnliche RPO- und RTO-Ziele wie bei der Warm-Standby-Strategie erreichen möchten, könnten Sie cloud-native Lösungen wie AWS Elastic Disaster Recovery in Betracht ziehen, die den Pilot-Light-Ansatz verfolgen und bessere RPO- und RTO-Ziele bieten.
**Implementierungsschritte**
1. **Bestimmen Sie eine DR-Strategie, die die Wiederherstellungsanforderungen für diese Workload erfüllt.**
Die Wahl einer DR-Strategie ist eine Abwägung zwischen der Reduzierung von Ausfallzeiten und Datenverlusten (RTO und RPO) und den Kosten und der Komplexität der Implementierung der Strategie. Sie sollten vermeiden, eine Strategie zu verfolgen, die strikter ist als nötig, da dies unnötige Kosten verursacht.
Im folgenden Diagramm hat das Unternehmen beispielsweise seine maximal zulässige RTO sowie die Grenze der Ausgaben für seine Strategie zur Wiederherstellung von Diensten festgelegt. In Anbetracht der Ziele des Unternehmens erfüllen die DR-Strategien Pilot-Light oder Warm-Standby sowohl die RTO- als auch die Kostenkriterien.
![\[Grafik zur Auswahl einer DR-Strategie auf der Grundlage von RTO und Kosten\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/choosing-a-dr-strategy.png)
Weitere Informationen finden Sie unter [Business Continuity Plan (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Überprüfen Sie die Muster, wie die ausgewählte DR-Strategie umgesetzt werden kann.**
In diesem Schritt geht es darum, zu verstehen, wie Sie die gewählte Strategie umsetzen wollen. Die Strategien werden durch die Verwendung von AWS-Regionen als primäre und Wiederherstellungsstandort erläutert. Sie können jedoch auch Verfügbarkeitszonen innerhalb einer einzigen Region als DR-Strategie verwenden, die Elemente mehrerer dieser Strategien nutzt.
In den folgenden Schritten können Sie die Strategie auf Ihren spezifischen Workload anwenden.
**Sicherung und Wiederherstellung**
*Backup und Wiederherstellung* ist die am einfachsten zu implementierende Strategie, erfordert jedoch mehr Zeit und Aufwand für die Wiederherstellung des Workloads, was zu einem höheren RTO und RPO führt. Es ist eine gute Vorgehensweise, immer Sicherungskopien Ihrer Daten zu erstellen und diese auf einen anderen Standort (z. B. einen anderen AWS-Region) zu kopieren.
![\[Diagramm einer Sicherungs- und Wiederherstellungsarchitektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/backup-restore-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/) (Architektur zur Notfallwiederherstellung (DR) auf AWS, Teil II: Backup und Wiederherstellung mit schneller Wiederherstellung).
**Pilot Light**
Mit dem *Pilot-Light*-Ansatz replizieren Sie Ihre Daten von Ihrer primären Region auf Ihre Recovery Region. Die Kernressourcen, die für die Workload-Infrastruktur verwendet werden, werden in der Wiederherstellungsregion bereitgestellt, jedoch werden noch zusätzliche Ressourcen und Abhängigkeiten benötigt, um diesen Stack funktionsfähig zu machen. In Abbildung 20 werden zum Beispiel keine Compute-Instances bereitgestellt.
![\[Diagramm einer Pilot-Light-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/pilot-light-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (Architektur zur Notfallwiederherstellung (DR) auf AWS, Teil III: Pilot-Light und Warm-Standby).
**Warm Standby**
Der *Warm-Standby*-Ansatz besteht darin, dass eine herunterskalierte, aber voll funktionsfähige Kopie Ihrer Produktionsumgebung in einer anderen Region vorhanden ist. Dieser Ansatz erweitert das Konzept des Pilot-Light und verkürzt die Zeit bis zur Wiederherstellung, da die Workload in einer anderen Region ständig präsent ist. Wenn die Wiederherstellungsregion mit voller Kapazität bereitgestellt wird, wird dies als *Hot-Standby* bezeichnet.
![\[Abbildung 21 mit Diagramm: Warm-Standby-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/warm-standby-architecture.png)
Der Einsatz von Warm-Standby oder Pilot-Light erfordert ein Hochskalieren der Ressourcen in der Wiederherstellungsregion. Um sicherzustellen, dass Kapazität bei Bedarf verfügbar ist, sollten Sie die Verwendung von [Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) für EC2-Instances in Betracht ziehen. Wenn Sie AWS Lambda verwenden, können Sie mit [provisioned concurrency](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) Ausführungsumgebungen bereitstellen, damit diese sofort auf die Aufrufe Ihrer Funktion reagieren können.
Weitere Details zu dieser Strategie finden Sie unter [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (Architektur zur Notfallwiederherstellung (DR) auf AWS, Teil III: Pilot-Light und Warm-Standby).
**Mehrere Standorte aktiv/aktiv**
Sie können Ihren Workload gleichzeitig in mehreren Regionen als Teil einer *Multi-Site Aktiv/Aktiv*-Strategie ausführen. Multi-Site Aktiv/Aktiv bedient den Datenverkehr aus allen Regionen, in denen es eingesetzt wird. Kunden können diese Strategie aus anderen Gründen als DR wählen. Sie kann zur Erhöhung der Verfügbarkeit oder bei der Bereitstellung einer Workload für eine globale Zielgruppe verwendet werden (um den Endpunkt näher an die Benutzer zu bringen und/oder um Stacks bereitzustellen, die für die Zielgruppe in dieser Region lokalisiert sind). Wenn der Workload in einer der AWS-Regionen, in denen er bereitgestellt wird, nicht unterstützt werden kann, wird diese Region evakuiert und die verbleibenden Regionen werden zur Aufrechterhaltung der Verfügbarkeit genutzt. Multi-Site Aktiv/Aktiv ist die betrieblich komplexeste der DR-Strategien und sollte nur dann gewählt werden, wenn die Geschäftsanforderungen dies erfordern.
![\[Diagramm mit einer Multi-Site Aktiv/Aktiv Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/multi-site-active-active-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/) (Architektur zur Notfallwiederherstellung (DR) auf AWS, Teil IV: Multi-Site Aktiv/Aktiv).
**AWS Elastic Disaster Recovery**
Wenn Sie für die Notfallwiederherstellung die Pilot-Light- oder die Warm-Standby-Strategie in Betracht ziehen, könnte AWS Elastic Disaster Recovery einen alternativen Ansatz mit verbesserten Vorteilen bieten. Elastic Disaster Recovery kann ein ähnliches RPO- und RTO-Ziel wie Warm-Standby bieten, behält aber den kostengünstigen Ansatz von Pilot-Light bei. Elastic Disaster Recovery repliziert Ihre Daten von Ihrer primären Region auf Ihre Wiederherstellungsregion und nutzt dabei die kontinuierliche Datensicherung, um ein RPO im Sekundenbereich und ein RTO im Minutenbereich zu erreichen. In der Wiederherstellungsregion werden nur die für die Replikation der Daten erforderlichen Ressourcen bereitgestellt, was die Kosten ähnlich wie bei der Pilot-Light-Strategie niedrig hält. Bei Verwendung von Elastic Disaster Recovery koordiniert und orchestriert der Service die Wiederherstellung von Computing-Ressourcen, wenn diese als Teil eines Failover oder Drills initiiert wird.
![\[Architekturdiagramm zur Beschreibung der Arbeitsweise von AWS Elastic Disaster Recovery.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/drs-architecture.png)
**Zusätzliche Praktiken zum Schutz von Daten**
Bei allen Strategien müssen Sie sich auch gegen einen Datennotfall wappnen. Kontinuierliche Datenreplikation schützt Sie vor einigen Arten von Notfällen, aber sie schützt Sie möglicherweise nicht vor Datenbeschädigung oder -zerstörung, es sei denn, Ihre Strategie umfasst auch die Versionsverwaltung gespeicherter Daten oder Optionen für eine zeitpunktgenaue Wiederherstellung. Sie müssen auch die replizierten Daten in der Wiederherstellungssite sichern, um zusätzlich zu den Replikaten zeitpunktgenaue Sicherungen zu erstellen.
**Verwendung von mehreren Availability Zones (AZs) innerhalb einer einzigen AWS-Region**
Wenn Sie mehrere AZs in einer einzigen Region verwenden, nutzt Ihre DR-Implementierung mehrere Elemente der oben genannten Strategien. Zunächst müssen Sie eine Hochverfügbarkeitsarchitektur (High Availability, HA) mit mehreren AZs erstellen, wie in Abbildung 23 dargestellt. Diese Architektur nutzt einen Aktiv/Aktiv-Ansatz für mehrere Standorte, da die [Amazon EC2-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) und der [Elastic-Load-Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) über Ressourcen verfügen, die in mehreren AZs bereitgestellt werden und aktiv Anfragen weiterleiten. Die Architektur demonstriert auch Hot-Standby, d. h. wenn die primäre [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)-Instance ausfällt (oder die AZ selbst), wird die Standby-Instance zur primären Instance befördert.
![\[Diagramm mit Abbildung 24: Multi-AZ-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/multi-az-architecture2.png)
Zusätzlich zu dieser HA-Architektur müssen Sie Backups aller Daten hinzufügen, die für die Ausführung Ihrer Workloads erforderlich sind. Dies ist besonders bei Daten wichtig, die auf eine einzige Zone beschränkt sind – wie [Amazon EBS-Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) oder [Amazon Redshift-Cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Wenn eine AZ ausfällt, müssen Sie diese Daten in einer anderen AZ wiederherstellen. Wenn möglich, sollten Sie auch Datensicherungen auf einen anderen AWS-Region kopieren, um eine zusätzliche Sicherheit zu gewährleisten.
Ein weniger verbreiteter alternativer Ansatz für eine Single-Region, Multi-AZ-Notfallwiederherstellung wird im Blogbeitrag [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) (Erstellen hoch belastbarer Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 1: Single-Region-Stack) beschrieben. Hier besteht die Strategie darin, so viel Isolation wie möglich zwischen den AZs aufrechtzuerhalten, ähnlich wie bei den Regionen. Bei dieser alternativen Strategie können Sie sich für einen Aktiv/Aktiv- oder Aktiv/Passiv-Ansatz entscheiden.
**Anmerkung**
Für einige Workloads gibt es gesetzliche Vorschriften zur Aufbewahrung von Daten. Wenn dies auf Ihre Workload in einer Region zutrifft, in der es derzeit nur eine AWS-Region gibt, dann ist die Multi-Region für Ihre geschäftlichen Anforderungen nicht geeignet. Multi-AZ-Strategien bieten einen guten Schutz gegen die meisten Notfälle.
1. **Beurteilen Sie die Ressourcen Ihrer Workloads und deren Konfiguration in der Wiederherstellungsregion vor dem Failover (während des normalen Betriebs).**
Für die Infrastruktur und AWS-Ressourcen verwenden Sie Infrastructure-as-Code-Angebote wie [AWS CloudFormation](https://aws.amazon.com/cloudformation) oder Drittanbieter-Tools wie Hashicorp Terraform. Um mehrere Konten und Regionen über einen einzelnen Vorgang bereitzustellen, können Sie [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) nutzen. Bei Multi-Site-Aktiv/Aktiv- und Hot Standby-Strategien verfügt die in Ihrer Wiederherstellungsregion bereitgestellte Infrastruktur über dieselben Ressourcen wie Ihre Primärregion. Bei den Strategien Pilot-Light und Warm-Standby sind zusätzliche Maßnahmen erforderlich, um die Infrastruktur produktionsreif zu machen. Mit CloudFormation-[Parametern](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) und [bedingter Logik](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) können Sie mit [einer einzigen Vorlage](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) steuern, ob ein bereitgestellter Stack aktiv oder standby ist. Wenn Sie Elastic Disaster Recovery verwenden, repliziert und orchestriert der Service die Wiederherstellung von Anwendungskonfigurationen und Computing-Ressourcen.
Alle Notfallwiederherstellungsstrategien setzen voraus, dass die Datenquellen innerhalb der AWS-Region gesichert werden und diese Backups dann in die Wiederherstellungsregion kopiert werden. [AWS Backup](https://aws.amazon.com/backup/) bietet eine zentrale Anzeige, in der Sie Backups für diese Ressourcen konfigurieren, planen und überwachen können. Bei Pilot-Light, Warm-Standby und Multi-Site Aktiv/Aktiv sollten Sie außerdem Daten aus der primären Region auf Datenressourcen in der Wiederherstellungsregion replizieren (z. B. [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds)-DB-Instances oder [Amazon DynamoDB](https://aws.amazon.com/dynamodb)-Tabellen. Diese Datenressourcen sind daher aktiv und bereit, Anfragen in der Wiederherstellungsregion zu bedienen.
Weitere Informationen darüber, wie AWS-Services über Regionen hinweg arbeiten, finden Sie in der Blogserie über die [Erstellung einer multiregionalen Anwendung mit AWS-Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Legen Sie fest, wie Sie Ihre Wiederherstellungsregion bei Bedarf (während eines Notfallereignisses) für einen Failover bereit machen wollen, und setzen Sie diese um.**
Bei Multi-Site Aktiv/Aktiv bedeutet Failover, dass eine Region evakuiert wird und die verbleibenden aktiven Regionen genutzt werden. Im Allgemeinen sind diese Regionen bereit, Datenverkehr aufzunehmen. Bei den Strategien Pilot-Light und Warm-Standby müssen Ihre Wiederherstellungsmaßnahmen die fehlenden Ressourcen bereitstellen, z. B. die EC2-Instances in Abbildung 20, sowie alle anderen fehlenden Ressourcen.
Bei allen oben genannten Strategien müssen Sie möglicherweise schreibgeschützte Instances von Datenbanken zur primären Lese-/Schreib-Instance machen.
Bei der Sicherung und Wiederherstellung werden durch die Wiederherstellung von Daten aus der Sicherung Ressourcen für diese Daten wie EBS-Volumes, RDS-DB-Instances und DynamoDB-Tabellen erstellt. Außerdem müssen Sie die Infrastruktur wiederherstellen und Code bereitstellen. Sie können AWS Backup nutzen, um Daten in der Wiederherstellungsregion wiederherzustellen. Unter [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md) finden Sie weitere Informationen. Zum Wiederaufbau der Infrastruktur gehört auch die Erstellung von Ressourcen wie EC2-Instances, zusätzlich zu den [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), Subnetzen und Sicherheitsgruppen. Sie können einen Großteil des Wiederherstellungsprozesses automatisieren. Wie das geht, erfahren Sie in [diesem Blogbeitrag](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Legen Sie fest und implementieren Sie, wie Sie den Datenverkehr bei Bedarf (im Notfall) zum Failover umleiten werden.**
Dieser Failover-Vorgang kann entweder automatisch oder manuell eingeleitet werden. Ein automatisch eingeleiteter Failover auf der Grundlage von Zustandsprüfungen oder Alarmen ist mit Vorsicht zu genießen, da ein unnötiger Failover (Fehlalarm) Kosten wie Nichtverfügbarkeit und Datenverlust verursacht. Daher wird häufig ein manuell initiierter Failover verwendet. In diesem Fall sollten Sie die Schritte für den Failover dennoch automatisieren, sodass die manuelle Auslösung wie ein Knopfdruck wirkt.
Bei der Inanspruchnahme von AWS-Services gibt es mehrere Optionen für die Verwaltung des Datenverkehrs zu berücksichtigen. Eine Möglichkeit ist die Verwendung von [Amazon Route 53](https://aws.amazon.com/route53). Mit Amazon Route 53 können Sie mehrere IP-Endpunkte in einem oder mehreren AWS-Regionen mit einem Route-53-Domänennamen verknüpfen. Um einen manuell initiierten Failover zu implementieren, können Sie [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/) verwenden. Dieser Service bietet eine hochverfügbare API für die Datenebene, um den Datenverkehr in die Wiederherstellungsregion umzuleiten. Verwenden Sie bei der Implementierung von Failover Vorgänge auf der Datenebene und vermeiden Sie solche auf der Steuerebene, wie beschrieben in [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md).
Weitere Informationen zu dieser und anderen Optionen finden Sie in [diesem Abschnitt des Whitepapers zur Notfallwiederherstellung](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Entwerfen Sie einen Plan für den Failback Ihres Workloads.**
Failback bedeutet, dass Sie den Workload-Betrieb in der primären Region wieder aufnehmen, nachdem ein Notfallereignis abgeklungen ist. Die Bereitstellung von Infrastruktur und Code für die primäre Region erfolgt im Allgemeinen in denselben Schritten wie ursprünglich, wobei Infrastruktur als Code und Code-Bereitstellungspipelines verwendet werden. Die Herausforderung beim Failback ist die Wiederherstellung von Datenspeichern und die Sicherstellung ihrer Konsistenz mit der in Betrieb befindlichen Wiederherstellungsregion.
Im ausgefallenen Zustand sind die Datenbanken in der Wiederherstellungsregion aktiv und verfügen über die aktuellen Daten. Ziel ist es dann, eine erneute Synchronisierung von der Wiederherstellungsregion mit der primären Region vorzunehmen, um sicherzustellen, dass diese auf dem neuesten Stand ist.
Einige AWS-Services werden das automatisch tun. Wenn Sie [globale Amazon DynamoDB-Tabellen](https://aws.amazon.com/dynamodb/global-tables/) verwenden, führt DynamoDB die Weiterleitung aller ausstehenden Schreibvorgänge durch, sobald sie wieder online ist (selbst wenn die Tabelle in der primären Region nicht mehr verfügbar ist). Wenn Sie [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) und einen [verwalteten, geplanten Failover](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover) verwenden, dann wird Aurora die bestehende Replikationstopologie der globalen Datenbank beibehalten. Daher wird die ehemalige Lese-/Schreib-Instance in der primären Region zu einem Replikat und erhält Aktualisierungen von der Wiederherstellungsregion.
In Fällen, in denen dies nicht automatisch geschieht, müssen Sie die Datenbank in der primären Region als Replikat der Datenbank in der Wiederherstellungsregion neu einrichten. In vielen Fällen bedeutet dies, dass die alte primäre Datenbank gelöscht und neue Replikate erstellt werden müssen. Ein Beispiel für eine Anleitung, wie Sie dies mit Amazon Aurora Global Database unter der Annahme eines *ungeplanten* Failovers umsetzen, finden Sie in dieser Übung: [Fail Back a Global Database](https://awsauroralabsmy.com/global/failback/) (Failback einer globalen Datenbank).
Wenn Sie nach einem Failover in Ihrer Wiederherstellungsregion weiterarbeiten können, sollten Sie diese zur neuen Primärregion machen. Sie würden trotzdem alle oben genannten Schritte durchführen, um die ehemalige Primärregion in eine Wiederherstellungsregion zu verwandeln. Einige Unternehmen führen eine planmäßige Rotation durch und tauschen ihre Primär- und Wiederherstellungsregionen in regelmäßigen Abständen aus (z. B. alle drei Monate).
Alle für Failover und Failback erforderlichen Schritte sollten in einem Playbook festgehalten werden, das allen Teammitgliedern zur Verfügung steht und regelmäßig überprüft wird.
Wenn Sie Elastic Disaster Recovery verwenden, hilft der Service bei der Orchestrierung und Automatisierung des Failback-Prozesses. Weitere Details finden Sie unter [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html) (Durchführen eines Failbacks).
**Grad des Aufwands für den Implementierungsplan:** hoch
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md)
**Zugehörige Dokumente:**
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Optionen für die Notfallwiederherstellung in der Cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Entwickeln Sie eine Multi-Region-Serverless-Backend-Lösung, die aktiv/aktiv ist.](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-Region-Serverless-Backend – neu aufgelegt](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: Regionsübergreifendes Replizieren von Lesereplikaten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: Konfigurieren von DNS-Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: Regionsübergreifende Replikation](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Was ist AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Was ist Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Get Started – AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started) (Erste Schritte)
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Zugehörige Videos:**
+ [Notfallwiederherstellung von Workloads auf AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4) (Architekturmuster für Aktiv/Aktiv-Anwendungen in mehreren Regionen)
+ [Erste Schritte mit AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Zugehörige Beispiele:**
+ [Well-Architected Lab – Disaster Recovery](https://wellarchitectedlabs.com/reliability/disaster-recovery/) (Well-Architected Lab – Notfallwiederherstellung) – Eine Reihe von Workshops zur Veranschaulichung von Notfallwiederherstellungsstrategien
# REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:
Testen Sie regelmäßig den Failover zu Ihrem Wiederherstellungsstandort, um zu überprüfen, ob er ordnungsgemäß funktioniert und ob das RTO und RPO eingehalten werden.
**Typische Anti-Muster:**
+ Failover sollten nie in der Produktion getestet werden.
**Vorteile der Nutzung dieser bewährten Methode:** Das regelmäßige Testen Ihres Plans zur Notfallwiederherstellung stellt sicher, dass er funktioniert, wenn er benötigt wird, und dass Ihr Team weiß, wie die Strategie auszuführen ist.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** hoch
## Implementierungsleitfaden
Vom Erstellen selten durchgeführter Wiederherstellungspfade wird abgeraten. So könnten Sie beispielsweise einen zweiten Datenspeicher unterhalten, der nur für Leseabfragen verwendet wird. Wenn Sie Daten in einen Datenspeicher schreiben und der primäre Datenspeicher einen Fehler ausgibt, können Sie einen Failover auf den zweiten Datenspeicher durchführen. Wenn Sie diesen Failover nicht regelmäßig testen, werden Sie möglicherweise feststellen, dass Ihre Annahmen zu den Möglichkeiten des sekundären Datenspeichers unzutreffend sind. Die Kapazität des zweiten Datenspeichers, die bei den letzten Tests möglicherweise noch ausreichend war, genügt möglicherweise nicht mehr den Anforderungen dieses Szenarios. Unsere Erfahrungen haben gezeigt, dass bei einer Wiederherstellung nach einem Fehler nur der Pfad funktioniert, den Sie regelmäßig testen. Daher ist es ratsam, mehrere Wiederherstellungspfade zu pflegen. Sie können Wiederherstellungsmuster erstellen und diese regelmäßig testen. Auch komplexe oder kritische Wiederherstellungspfade müssen regelmäßig mittels Fehlersimulationen in der Produktion durchgeführt werden, um sicherzustellen, dass sie funktionieren. In dem gerade besprochenen Beispiel sollten Sie regelmäßig und unabhängig von der Erfordernis einen Failover auf die Standby-Ressourcen durchführen.
**Implementierungsschritte**
1. Workloads für die Wiederherstellung auslegen. Regelmäßige Tests der Wiederherstellungspfade Das Recovery-orientierte Computing identifiziert die Merkmale von Systemen, die die Wiederherstellung verbessern: Isolierung und Redundanz, systemweite Fähigkeit zur Rücknahme von Änderungen, Fähigkeit zur Überwachung und Bestimmung des Zustands, Fähigkeit zur Diagnose, automatisierte Wiederherstellung, modularer Aufbau und Fähigkeit zum Neustart. Testen Sie den Wiederherstellungspfad, um zu überprüfen, ob Sie die Wiederherstellung in der angegebenen Zeit und in dem angegebenen Zustand durchführen können. Dokumentieren Sie während dieser Wiederherstellung auftretende Probleme in Ihren Runbooks und suchen Sie vor dem nächsten Test nach Lösungen.
1. Für Amazon EC2-basierte Workloads verwenden Sie [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html), um Drill-Instances für Ihre Notfallwiederherstellungsstrategie zu implementieren und zu starten. AWS Elastic Disaster Recovery bietet die Möglichkeit, Drills effizient auszuführen, was Ihnen bei der Vorbereitung auf ein Failover-Ereignis hilft. Sie können Ihre Instances mit Elastic Disaster Recovery außerdem regelmäßig zu Test- und Übungszwecken starten, ohne den Datenverkehr weiterleiten zu müssen.
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Elastic Disaster Recovery – Vorbereitungen auf einen Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project](http://roc.cs.berkeley.edu/)
+ [Was ist AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Zugehörige Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4) (AWS re:Invent 2018: Architekturmuster für Multi-Region Aktiv/Aktive-Anwendungen)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8) (AWS re:Invent 2019: Backup-and-Wiederherstellung und Notfallwiederherstellungs-Lösungen mit AWS)
**Zugehörige Beispiele:**
+ [Well-Architected Lab – Testing for Resiliency](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) (Well-Architected Lab – Testen auf Ausfallsicherheit)
# REL13-BP04 Verwalten der Konfigurationsabweichungen am Standort oder in der Region der Notfallwiederherstellung:
Stellen Sie sicher, dass die Infrastruktur, die Daten und die Konfiguration am Standort oder in der Region der Notfallwiederherstellung den Anforderungen entsprechen. Sie sollten beispielsweise prüfen, ob AMIs und Service Quotas auf dem neuesten Stand sind.
AWS Config überwacht und zeichnet Ihre AWS-Ressourcenkonfigurationen kontinuierlich auf. Es kann Abweichungen erkennen und als Auslöser für [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) dienen, um diese zu beheben und Warnmeldungen zu senden. AWS CloudFormation kann zusätzlich Abweichungen in bereitgestellten Stacks erkennen.
**Gängige Antimuster:**
+ Versäumnis, Aktualisierungen an Ihren Wiederherstellungsstandorten vorzunehmen, wenn Sie Konfigurations- oder Infrastrukturänderungen an Ihren Hauptstandorten vornehmen.
+ Mögliche Einschränkungen (z. B. Serviceunterschiede) an Ihren primären Standorten und den Standorten für die Notfallwiederherstellung werden nicht berücksichtigt.
**Vorteile der Einführung dieser bewährten Methode:** Wenn Ihre Umgebung für die Notfallwiederherstellung mit der vorhandenen Umgebung konsistent ist, gewährleisten dies eine vollständige Wiederherstellung.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Sicherstellen, dass die Bereitstellung an Haupt- und Sicherungsstandorte erfolgt Pipelines für die Bereitstellung von Anwendungen in der Produktion müssen die Anwendungen an alle Standorte verteilen, die in der Strategie für die Notfallwiederherstellung angegeben sind. Dazu gehören auch Entwicklungs- und Testumgebungen.
+ Aktivieren von AWS Config zum Verfolgen von Standorten mit möglichen Abweichungen. Erstellen Sie mithilfe von AWS Config Regeln Systeme, die Ihre Strategien für die Notfallwiederherstellung durchsetzen und bei Erkennung von Abweichungen Warnungen generieren.
+ [Korrigieren von nicht konformen AWS-Ressourcen mit AWS-Config-Regeln](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Verwenden Sie AWS CloudFormation zur Bereitstellung Ihrer Infrastruktur. AWS CloudFormation kann Abweichungen zwischen den Angaben in den CloudFormation-Vorlagen und der tatsächlichen Bereitstellung erkennen.
+ [AWS CloudFormation: Ermitteln von Abweichungen im gesamten CloudFormation-Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: Ermitteln von Abweichungen im gesamten CloudFormation-Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Wie implementiere ich eine Lösung für die Verwaltung der Infrastrukturkonfiguration in AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Korrigieren von nicht konformen AWS-Ressourcen mit AWS-Config-Regeln](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05: Automatisieren der Wiederherstellung
Automatisieren Sie mit Tools von AWS oder Drittanbietern die Systemwiederherstellung und leiten Sie Datenverkehr zum Standort oder zur Region der Notfallwiederherstellung weiter.
Basierend auf konfigurierten Zustandsprüfungen können AWS-Services wie Elastic Load Balancing und AWS Auto Scaling die Last auf fehlerfreie Availability Zones verteilen während Services wie z. B, Amazon Route 53 und AWS Global Accelerator, die Last an fehlerfreie AWS-Regionen leiten können. Amazon Route 53 Application Recovery Controller hilft Ihnen, mithilfe von Bereitschaftsprüfungen und Routing-Steuerungsfunktionen Failover-Vorgänge zu verwalten und zu koordinieren. Diese Funktionen überwachen kontinuierlich die Fähigkeit Ihrer Anwendung, eine Wiederherstellung nach Fehlern durchzuführen, so dass Sie die Wiederherstellung der Anwendung über mehrere AWS-Regionen, Availability Zones und On-Premises kontrollieren können.
Für Workloads in bestehenden physischen oder virtuellen Rechenzentren oder privaten Clouds, [AWS Elastic Disaster Recovery,](https://aws.amazon.com/cloudendure-disaster-recovery/)verfügbar durch AWS Marketplace, ermöglicht es Unternehmen, eine automatisierte Notfallwiederherstellungsstrategie auf AWS einzurichten. CloudEndure unterstützt auch die regions- bzw. AZ-übergreifende Notfallwiederherstellung in AWS.
**Gängige Antimuster:**
+ Die Implementierung von identischem automatisiertem Failover und Failback kann bei einem Fehler zu Flapping führen.
**Vorteile der Einführung dieser bewährten Methode:** Die automatisierte Wiederherstellung verkürzt die Wiederherstellungszeit, da manuelle Fehler nicht mehr möglich sind.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Automatisieren von Wiederherstellungspfaden. Wenn in Szenarien mit hoher Verfügbarkeit kurze Wiederherstellungszeiten erforderlich sind, sind menschliche Beurteilungen und Aktionen zu langsam. Das System sollte in jeder Situation in der Lage sein, eine Wiederherstellung durchzuführen.
+ Verwenden Sie CloudEndure Disaster Recovery für automatisiertes Failover und Failback. CloudEndure Disaster Recovery repliziert Ihre Computer (einschließlich Betriebssystem, Systemstatuskonfiguration, Datenbanken, Anwendungen und Dateien) kontinuierlich in einen kostengünstigen Staging-Bereich in Ihrem AWS-Konto-Zielkonto und in Ihrer bevorzugten Region. Bei einem Notfall können Sie CloudEndure Disaster Recovery anweisen, innerhalb weniger Minuten automatisch Tausende Ihrer virtuellen Maschinen vollständig bereitgestellt zu starten.
+ [Ausführen von Failover und Failback bei Notfallwiederherstellungen](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [CloudEndure Disaster Recovery auf AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)