# Planung der Notfallwiederherstellung
Sicherungen und redundante Workload-Komponenten sind der Ausgangspunkt Ihrer Strategie für die Notfallwiederherstellung. [RTO und RPO sind Ihre Ziele](disaster-recovery-dr-objectives.md) für die Wiederherstellung Ihrer Workload. 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 Unterbrechungen und die Kosten von Wiederherstellungen sind ebenfalls wichtige Faktoren bei der Ermittlung des Unternehmenswerts, den Notfallwiederherstellungen von Workloads bieten.
Sowohl Verfügbarkeit als auch Notfallwiederherstellung basieren auf denselben bewährten Methoden wie der Überwachung auf Ausfälle, der Bereitstellung an mehreren Standorten und dem automatischen Failover. Verfügbarkeit konzentriert sich jedoch auf Komponenten der Workload, während Notfallwiederherstellung sich auf einzelne Kopien der gesamten Workload konzentriert. Notfallwiederherstellung verfolgt andere Ziele als Verfügbarkeit, wobei der Schwerpunkt auf der Zeit bis zur Wiederherstellung nach einem Notfall liegt.
**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
Ausfälle können sich auf verschiedene Weise auf Ihr Unternehmen auswirken. Erstens können Ausfälle zu Betriebsunterbrechungen (Ausfallzeiten) führen. Zweitens können Ausfälle dazu führen, dass Daten verloren gehen, inkonsistent oder veraltet sind. Definieren Sie für jeden Workload ein Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Das *Recovery Time Objective (RTO)* ist die maximal zulässige Verzögerung zwischen der Unterbrechung und der Wiederherstellung des Services. Das *Recovery Point Objective (RPO)* ist die maximal zulässige Zeitspanne seit dem letzten Datenwiederherstellungspunkt.
**Gewünschtes Ergebnis:** Für jeden Workload gibt es ein bestimmtes RTO und RPO, basierend auf technischen Überlegungen und geschäftlichen Auswirkungen.
**Typische Anti-Muster:**
+ Sie verfügen nicht über festgelegte Wiederherstellungsziele.
+ Sie wählen willkürliche Wiederherstellungsziele aus.
+ Sie wählen Wiederherstellungsziele aus, die nicht strikt genug sind und die Geschäftsziele nicht erfüllen.
+ Sie haben die Auswirkungen von Ausfallzeiten und Datenverlusten nicht bewertet.
+ Sie wählen unrealistische Wiederherstellungsziele aus (beispielsweise sofortige Wiederherstellung oder kein Datenverlust), die für Ihre Workload-Konfiguration möglicherweise nicht erreichbar sind.
+ Sie wählen Wiederherstellungsziele aus, die strikter sind als die tatsächlichen Geschäftsziele. Dies erzwingt Wiederherstellungsimplementierungen, die kostspieliger und komplizierter sind als für den Workload erforderlich.
+ Sie wählen Wiederherstellungsziele aus, die nicht mit denen eines abhängigen Workloads vereinbar sind.
+ Sie berücksichtigen gesetzliche Vorschriften und Compliance-Anforderungen nicht.
**Vorteile der Einführung dieser bewährten Methode:** Durch die Festlegung von RTOs und RPOs für Ihre Workloads definieren Sie klare und messbare Ziele für die Wiederherstellung auf der Grundlage Ihrer Geschäftsanforderungen. Sobald Sie diese Ziele festgelegt haben, können Sie Pläne für die Notfallwiederherstellung erstellen, die auf die Erreichung dieser Ziele zugeschnitten sind.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Erstellen Sie eine Matrix oder ein Arbeitsblatt, um eine bessere Planung der Notfallwiederherstellung zu ermöglichen. Erstellen Sie in Ihrer Matrix verschiedene Workload-Kategorien oder -stufen basierend auf den Auswirkungen der Workloads auf das Unternehmen (z. B. kritisch, hoch, mittel und gering) und den zugehörigen RTOs und RPOs, die Sie für jeden einzelnen Workload anstreben. Die folgende Matrix enthält ein Beispiel, dem Sie folgen können (beachten Sie, dass Ihre RTO- und RPO-Werte hiervon abweichen können):
![\[Diagramm mit der Matrix der Notfallwiederherstellung\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/disaster-recovery-matrix.png)
Sie müssen für jeden Workload die Auswirkungen von Ausfallzeiten und Datenverlusten auf Ihr Unternehmen ermitteln und verstehen. Die Auswirkungen werden in der Regel umso größer, je länger die Ausfallzeiten sind und je größer der Datenverlust ist, die Form der Auswirkung kann jedoch je nach Art des Workloads unterschiedlich sein. So kann es beispielsweise sein, dass Ausfallzeiten von bis zu einer Stunde geringe Auswirkungen haben, die Auswirkungen danach aber schnell zunehmen. Die Auswirkungen können viele verschiedene Formen annehmen. So kann es etwa finanzielle Auswirkungen (z. B. Umsatzeinbußen), Auswirkungen auf den Ruf (einschließlich Verlust von Kundenvertrauen), betriebliche Auswirkungen (z. B. verspätete Auszahlung von Gehältern oder verringerte Produktivität) und regulatorische Risiken geben. Weisen Sie den Workload nach Abschluss des Vorgangs der entsprechenden Stufe zu.
Berücksichtigen Sie bei der Analyse der Auswirkungen eines Fehlers die folgenden Fragen:
1. Wie lange kann der Workload maximal nicht verfügbar sein, bevor dies inakzeptable Auswirkungen auf das Unternehmen hat?
1. Wie stark werden die Auswirkungen einer Unterbrechung des Workloads auf das Unternehmen sein und welche Art von Auswirkungen wird es geben? Berücksichtigen Sie alle Arten von Auswirkungen, einschließlich finanzieller, den Ruf betreffender, betrieblicher und regulatorischer Auswirkungen.
1. Wie viele Daten können maximal verlorengehen oder nicht wiederherstellbar sein, bevor dies inakzeptable Auswirkungen auf das Unternehmen hat?
1. Können verlorene Daten aus anderen Quellen wiederhergestellt werden (sogenannte *abgeleitete* Daten)? Wenn ja, sollten Sie auch die RPOs aller Quelldaten berücksichtigen, die zur Neuerstellung der Workload-Daten verwendet werden.
1. Was sind die Wiederherstellungsziele und Verfügbarkeitserwartungen für Workloads, von denen dieser Workload abhängt (Downstream)? Die Ziele Ihres Workloads müssen unter Berücksichtigung der Wiederherstellungsmöglichkeiten seiner nachgelagerten Abhängigkeiten erreichbar sein. Erwägen Sie mögliche Behelfslösungen oder Abhilfemaßnahmen für nachgelagerte Abhängigkeiten, die die Wiederherstellungsfähigkeit dieses Workloads verbessern können.
1. Was sind die Wiederherstellungsziele und Verfügbarkeitserwartungen für Workloads, die von diesem Workload abhängen (Upstream)? Angesichts der Ziele vorgelagerter Workloads muss dieser Workload möglicherweise über striktere Wiederherstellungsmöglichkeiten verfügen, als es zunächst den Anschein hat.
1. Gibt es je nach Art des Vorfalls unterschiedliche Wiederherstellungsziele? Sie könnten beispielsweise unterschiedliche RTOs und RPOs haben, je nachdem, ob sich der Vorfall auf eine Availability Zone oder eine gesamte Region auswirkt.
1. Ändern sich Ihre Wiederherstellungsziele während bestimmter Ereignisse oder zu bestimmten Zeiten des Jahres? Sie könnten beispielsweise unterschiedliche RTOs und RPOs für das Weihnachtsgeschäft, für Sportveranstaltungen, Sonderverkaufsaktionen und Produkteinführungen haben.
1. Wie stimmen die Wiederherstellungsziele mit den Strategien Ihrer Branche und Ihres Unternehmens für die Notfallwiederherstellung überein?
1. Gibt es rechtliche oder vertragliche Konsequenzen zu beachten? Sind Sie beispielsweise vertraglich verpflichtet, einen Service mit einem bestimmten RTO oder RPO bereitzustellen? Welche Strafen könnten Ihnen bei einer Nichteinhaltung drohen?
1. Müssen Sie die Datenintegrität wahren, um gesetzliche Vorschriften oder Compliance-Anforderungen zu erfüllen?
Das folgende Arbeitsblatt kann Ihnen bei der Bewertung der einzelnen Workloads helfen. Sie können dieses Arbeitsblatt Ihren spezifischen Bedürfnissen entsprechend ändern, indem Sie beispielsweise zusätzliche Fragen hinzufügen.
![\[Arbeitsblatt\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/worksheet.png)
### Implementierungsschritte
1. Ermitteln Sie die geschäftlichen Stakeholder und technischen Teams, die für die einzelnen Workloads verantwortlich sind, und setzen Sie sich mit ihnen in Verbindung.
1. Erstellen Sie Kategorien oder Stufen der Kritikalität für die Workload-Auswirkungen in Ihrem Unternehmen. Beispielkategorien sind u. a. „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“. Wählen Sie für jede Kategorie ein Ihren Geschäftszielen und Anforderungen entsprechendes RTO und RPO.
1. Weisen Sie jedem Workload eine der im vorherigen Schritt erstellten Auswirkungskategorien zu. Berücksichtigen Sie für die Zuordnung eines Workloads zu einer Kategorie die Bedeutung des Workloads für das Unternehmen sowie die Auswirkungen von Unterbrechungen oder Datenverlusten und orientieren Sie sich an den obigen Fragen. So erhalten Sie für jeden Workload ein RTO und ein RPO.
1. Sehen Sie sich das im vorherigen Schritt ermittelte RTO und RPO für jeden Workload an. Beziehen Sie die geschäftlichen und technischen Teams für den Workload mit ein, um zu entscheiden, ob die Ziele angepasst werden sollten. Geschäftliche Stakeholder könnten beispielsweise zu dem Schluss kommen, dass strengere Ziele erforderlich sind. Alternativ könnten technische Teams feststellen, dass die Ziele so geändert werden sollten, dass sie mit den verfügbaren Ressourcen und technologischen Einschränkungen erreichbar sind.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL09-BP04 Verifizieren der Sicherungsintegrität und -verfahren durch regelmäßiges Wiederherstellen der Daten](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Untersuchen von Fehlern mit Playbooks](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Zugehörige Dokumente:**
+ [AWS Architecture Blog: Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads in 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 Ausfallsicherheitsrichtlinien 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)
**Zugehörige Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [Notfallwiederherstellung von Workloads in 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 jede Workload gibt es eine definierte und implementierte DR-Strategie, mit der die Workload die DR-Ziele erreichen kann. 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, die Workload auszuführen. Die häufigsten Wiederherstellungsziele sind RTO und RPO, wie in [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten](rel_planning_for_recovery_objective_defined_recovery.md) besprochen.
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 sind in aufsteigender Reihenfolge nach Kosten und Komplexität und in absteigender Reihenfolge nach RTO und RPO aufgeführt. Die *Wiederherstellungsregion* bezieht sich auf eine andere AWS-Region als die primäre Region, die für Ihre Workload verwendet wird.
![\[Diagramm der DR-Strategien\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/disaster-recovery-strategies.png)
+ **Sicherung und Wiederherstellung** (RPO in Stunden, RTO in 24 Stunden oder weniger): Sichern Sie Ihre Daten und Anwendungen in der Wiederherstellungsregion. Die Verwendung automatisierter oder kontinuierlicher Backups ermöglicht eine zeitpunktbezogene Wiederherstellung (PITR), 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 das 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 in Minuten, RTO in 10-Minuten-Intervallen): Stellen Sie eine Kopie Ihrer Kern-Workload-Infrastruktur in der Wiederherstellungsregion bereit. 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-Datenverarbeitung werden nicht bereitgestellt, sondern können bei Bedarf mit der erforderlichen Konfiguration und dem Anwendungscode erstellt werden.
+ **Warm Standby** (RPO in Sekunden, RTO in Minuten): Eine herunterskalierte, aber voll funktionsfähige Version Ihrer Workload wird dauerhaft in der Wiederherstellungsregion ausgeführt. Geschäftskritische Systeme sind vollständig dupliziert und ständig aktiv, aber mit herunterskalierter Flotte. 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 vollständiger Skalierung wird dies als *Hot Standby* bezeichnet.
+ **Regionsübergreifend (Multi-Site) Aktiv/Aktiv** (RPO nahe Null, RTO potenziell Null): Ihre Workload wird auf mehrere AWS-Regionen verteilt und stellt aktiv Datenverkehr daraus aus. 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 zeitpunktbezogene 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 cloudnative 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 sein maximal zulässiges 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/latest/reliability-pillar/images/choosing-a-dr-strategy.png)
Weitere Informationen finden Sie unter [Geschäftsfortführungsplan](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Sehen Sie sich anhand der Muster an, wie die gewä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 Availability Zones innerhalb einer einzigen Region als DR-Strategie verwenden, die Elemente mehrerer dieser Strategien nutzt.
In den folgenden Schritten können Sie die Strategie auf Ihre spezifische Workload anwenden.
**Backup und Wiederherstellung**
*Backup und Wiederherstellung* ist die einfachste Strategie zur Implementierung, erfordert jedoch mehr Zeit- und Arbeitsaufwand bei der Wiederherstellung der Workload, 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/latest/reliability-pillar/images/backup-restore-architecture.png)
Weitere Informationen zu dieser Strategie finden Sie unter [Architektur für die Notfallwiederherstellung in AWS, Teil II: Sicherung und Wiederherstellung mit Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot light**
Beim *Pilot-Light-Ansatz* replizieren Sie die Daten von Ihrer primären Region in Ihre Wiederherstellungsregion. 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 Datenverarbeitungs-Instances bereitgestellt.
![\[Diagramm einer Pilot-Light-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/pilot-light-architecture.png)
Weitere Informationen zu dieser Strategie finden Sie unter [Architektur für die Notfallwiederherstellung in AWS, Teil III: Pilot Light und Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warmer Bereitschaftsmodus**
Beim *Warm-Standby-Ansatz* wird sichergestellt, 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/latest/reliability-pillar/images/warm-standby-architecture.png)
Der Einsatz von Warm Standby oder Pilot Light erfordert ein Hochskalieren der Ressourcen in der Wiederherstellungsregion. Um zu überprüfen, ob bei Bedarf Kapazität verfügbar ist, sollten Sie die Nutzung 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, kann die [bereitgestellte Parallelität](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) Laufzeitumgebungen bereitstellen, damit sie sofort auf die Aufrufe Ihrer Funktion reagieren können.
Weitere Informationen zu dieser Strategie finden Sie unter [Architektur für die Notfallwiederherstellung in AWS, Teil III: Pilot Light und Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multi-Site Aktiv/Aktiv**
Im Rahmen einer *Multi-Site Aktiv/Aktiv*-Strategie können Sie Ihre Workload in mehreren Regionen gleichzeitig ausführen. Multi-Site Aktiv/Aktiv bedient den Datenverkehr aus allen Regionen, in denen es eingesetzt wird. Diese Strategie 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 die Workload in einer der AWS-Regionen, in denen sie 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/latest/reliability-pillar/images/multi-site-active-active-architecture.png)
Weitere Informationen zu dieser Strategie finden Sie unter [Architektur für die Notfallwiederherstellung in AWS, Teil IV: Multi-Site Aktiv/Aktiv](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**AWS Elastic Disaster Recovery**
Wenn Sie für die Notfallwiederherstellung die Pilot-Light- oder 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 Datenverarbeitungs-Ressourcen, wenn die Initiierung als Teil eines Failover oder Drills erfolgt.
![\[Architekturdiagramm zur Beschreibung der Arbeitsweise von AWS Elastic Disaster Recovery.\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/drs-architecture.png)
**Zusätzliche Methoden 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 zeitpunktbezogene Wiederherstellung. Sie müssen auch die replizierten Daten in der Wiederherstellungssite sichern, um zusätzlich zu den Replikaten zeitpunktgenaue Sicherungen zu erstellen.
**Verwendung mehrerer 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 verwendet einen Multi-Site Aktiv/Aktiv-Ansatz, da die [Amazon EC2-Instances](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 Anfragen aktiv bearbeiten. Die Architektur demonstriert auch Hot Standby, d. h. bei einem Ausfall der primären [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)-Instance (oder der AZ selbst) wird die Standby-Instance zur primären Instance hochgestuft.
![\[Diagramm mit Abbildung 24: Multi-AZ-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/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 wichtig für Daten, die auf eine einzelne Zone beschränkt sind, etwa [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 einzelne Regionen, die Multi-AZ-Notfallwiederherstellung, wird im Blogbeitrag [Entwickeln hoch resilienter Anwendungen mit Amazon Application Recovery Controller, Teil 1: Stack für eine einzelne Region](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/) 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 im Hinblick auf die Datenresidenz. 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. **Bewerten Sie vor dem Failover (während des normalen Betriebs) die Ressourcen Ihrer Workloads und deren Konfiguration in der Wiederherstellungsregion.**
Verwenden Sie für Infrastruktur- und AWS-Ressourcen Infrastruktur als Code, etwa [AWS CloudFormation](https://aws.amazon.com/cloudformation) oder Tools von Drittanbietern wie Hashicorp Terraform. Um die Bereitstellung über mehrere Konten und Regionen hinweg mit einer einzigen Operation durchzuführen, können Sie [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) verwenden. 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. Mithilfe von 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 im Standby-Modus ist. Wenn Sie Elastic Disaster Recovery verwenden, repliziert und orchestriert der Service die Wiederherstellung von Anwendungskonfigurationen und Datenverarbeitungs-Ressourcen.
Alle DR-Strategien erfordern, dass Datenquellen innerhalb der AWS-Region gesichert werden und diese Backups anschließend in die Wiederherstellungsregion kopiert werden. [AWS Backup](https://aws.amazon.com/backup/) bietet eine zentrale Ansicht, in der Sie Backups für diese Ressourcen konfigurieren, planen und überwachen können. Für Pilot Light, Warm Standby und Multi-Site Aktiv/Aktiv sollten Sie auch Daten aus der primären Region auf Datenressourcen in der Wiederherstellungsregion replizieren, etwa [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 in verschiedenen Regionen funktionieren, finden Sie in der Blogserie [Erstellen einer regionsübergreifenden Anwendung mit AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Ermitteln und implementieren Sie, wie Sie Ihre Wiederherstellungsregion bei Bedarf (im Notfall) auf ein Failover vorbereiten.**
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. Weitere Details finden Sie unter [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md). Der Wiederaufbau der Infrastruktur umfasst die Erstellung von Ressourcen wie EC2-Instances zusätzlich zur [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), zu Subnetzen und zu benötigten 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. **Ermitteln und implementieren Sie, wie Sie den Datenverkehr bei Bedarf (im Notfall) zum Failover umleiten.**
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 Option 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-Domainnamen verknüpfen. Um ein manuell eingeleitetes Failover zu implementieren, können Sie [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) verwenden, das eine hochverfügbare Datenebenen-API zur Umleitung des Datenverkehrs in die Wiederherstellungsregion bereitstellt. Verwenden Sie bei der Implementierung von Failover Vorgänge auf der Datenebene und vermeiden Sie solche auf der Steuerebene, wie in [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md) beschrieben.
Weitere Informationen zu diesen 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 das Failback Ihrer Workload.**
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, setzt DynamoDB die Propagierung aller ausstehenden Schreibvorgänge fort, sobald die Tabelle wieder online ist, auch wenn sie in der primären Region nicht mehr verfügbar war. Wenn Sie [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) und ein [verwaltetes geplantes Failover](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover) verwenden, wird die vorhandene Replikationstopologie der globalen Aurora-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.
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 Informationen finden Sie unter [Durchführen eines Failbacks](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**Aufwand 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: Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads in 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 einer 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: Konfiguration des DNS-Failovers](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 Amazon 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: Erste Schritte – AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [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 in 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)
+ [Erste Schritte mit AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# 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:** Durch regelmäßige Tests des Notfallwiederherstellungsplans ist gewährleistet, dass er bei Bedarf funktioniert und von Ihrem Team umgesetzt werden kann.
**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 sekundären 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. Legen Sie die Workloads für die Wiederherstellung aus. Testen Sie regelmäßig Ihre Wiederherstellungspfade Die Recovery-orientierte Datenverarbeitung 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. Verwenden Sie für Amazon EC2-basierte Workloads [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html), um Drill-Instances für Ihre DR-Strategie zu implementieren und zu starten. AWS Elastic Disaster Recoverybietet die Möglichkeit, Drills effizient durchzuführen, sodass Sie sich auf ein Failover-Ereignis vorbereiten können. 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: Notfallwiederherstellung](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 in 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 – Vorbereitung auf das Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [The Berkeley/Stanford Recovery-Oriented Computing 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 2019: Backup-and-Restore and Disaster-Recovery Solutions with AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Verwalten der Konfigurationsabweichungen am Standort oder in der Region der Notfallwiederherstellung
Um ein erfolgreiches Verfahren für die Notfallwiederherstellung durchführen zu können, müssen Ihre Workloads in der Lage sein, den normalen Betrieb zeitnah wieder aufzunehmen, ohne dass es zu nennenswerten Funktions- oder Datenverlusten kommt, sobald die Umgebung für die Notfallwiederherstellung online gegangen ist. Um dieses Ziel zu erreichen, ist es unerlässlich, eine konsistente Infrastruktur sowie konsistente Daten und Konfigurationen zwischen Ihrer Umgebung für die Notfallwiederherstellung und der primären Umgebung aufrechtzuerhalten.
**Gewünschtes Ergebnis:** Die Konfiguration und die Daten Ihres Standorts für die Notfallwiederherstellung entsprechen denen des primären Standorts, wodurch bei Bedarf eine schnelle und vollständige Wiederherstellung möglich ist.
**Typische Anti-Muster:**
+ Sie versäumen es, die Wiederherstellungsstandorte zu aktualisieren, wenn Änderungen an den primären Standorten vorgenommen werden. Dadurch kommt es zu veralteten Konfigurationen, die die Wiederherstellungsbemühungen behindern könnten.
+ Sie lassen mögliche Einschränkungen wie Serviceunterschiede zwischen primärem Standort und Wiederherstellungsstandort, die zu unerwarteten Fehlern beim Failover führen können, außer Acht.
+ Sie verlassen sich bei der Aktualisierung und Synchronisierung der Umgebung für die Notfallwiederherstellung auf manuelle Prozesse, was das Risiko von menschlichen Fehlern und Inkonsistenzen erhöht.
+ Sie erkennen Konfigurationsabweichungen nicht und haben daher vor einem Vorfall fälschlicherweise das Gefühl, dass der Standort für die Notfallwiederherstellung bereit ist.
**Vorteile der Einführung dieser bewährten Methode:** Durch die Konsistenz zwischen der Umgebung für die Notfallwiederherstellung und der primären Umgebung erhöht sich die Wahrscheinlichkeit einer erfolgreichen Wiederherstellung nach einem Vorfall erheblich und das Risiko eines fehlgeschlagenen Wiederherstellungsvorgangs verringert sich.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Ein umfassender Ansatz für das Konfigurationsmanagement und die Failover-Bereitschaft kann Ihnen dabei helfen, sicherzustellen, dass der Standort für die Notfallwiederherstellung regelmäßig aktualisiert wird und bei einem Ausfall des primären Standorts zur Übernahme bereit ist.
Um Konsistenz zwischen Ihrer primären Umgebung und Ihrer Umgebung für die Notfallwiederherstellung zu erreichen, sollten Sie sicherstellen, dass Ihre Bereitstellungs-Pipelines Anwendungen sowohl an Ihren primären Standort als auch an Ihren Standort für die Notfallwiederherstellung verteilen. Führen Sie Änderungen an den Standorten für die Notfallwiederherstellung nach einem angemessenen Evaluierungszeitraum durch (sogenannte *gestaffelte Bereitstellungen*), um Probleme am primären Standort zu erkennen und die Bereitstellung zu stoppen, bevor sie sich ausbreiten. Implementieren Sie eine Überwachung, um Konfigurationsabweichungen zu erkennen und Änderungen sowie die Einhaltung von Vorschriften in Ihren Umgebungen nachzuverfolgen. Führen Sie automatisierte Problembehebungen am Standort für die Notfallwiederherstellung durch, um vollständige Konsistenz sicherzustellen und dafür zu sorgen, dass der Standort bei einem Vorfall übernahmebereit ist.
### Implementierungsschritte
1. Stellen Sie sicher, dass die Region für die Notfallwiederherstellung die AWS-Services und -Features enthält, die für eine erfolgreiche Ausführung Ihres Plans für die Notfallwiederherstellung erforderlich sind.
1. Verwenden Sie Infrastructure as Code (IaC). Sorgen Sie dafür, dass Ihre Konfigurationsvorlagen für die Produktionsinfrastruktur und die Anwendungen korrekt sind, und wenden Sie die Vorlagen regelmäßig auf Ihre Umgebung für die Notfallwiederherstellung an. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) kann Abweichungen zwischen den Vorgaben Ihrer CloudFormation-Vorlagen und der tatsächlichen Bereitstellung erkennen.
1. Konfigurieren Sie CI/CD-Pipelines, um Anwendungen und Infrastrukturupdates für alle Umgebungen bereitzustellen, einschließlich primärer Standorte und Standorte für die Notfallwiederherstellung. CI/CD-Lösungen wie [AWS CodePipeline](https://aws.amazon.com/codepipeline/) können den Bereitstellungsprozess automatisieren, wodurch das Risiko von Konfigurationsabweichungen verringert wird.
1. Staffeln Sie die Bereitstellungen zwischen der primären Umgebung und der Umgebung für die Notfallwiederherstellung. Auf diese Weise können Updates zunächst in der primären Umgebung bereitgestellt und getestet und so Probleme am primären Standort isoliert werden, bevor die Updates an den Standort für die Notfallwiederherstellung weitergegeben werden. Dieser Ansatz verhindert, dass Fehler gleichzeitig an die Produktion und den Standort für die Notfallwiederherstellung weitergegeben werden, und stellt die Integrität der Umgebung für die Notfallwiederherstellung sicher.
1. Überwachen Sie die Ressourcenkonfigurationen sowohl in der primären Umgebung als auch in der Umgebung für die Notfallwiederherstellung kontinuierlich. Lösungen wie [AWS Config](https://aws.amazon.com/config/) können helfen, die Einhaltung von Konfigurationen durchzusetzen und Abweichungen zu erkennen. Auf diese Weise können konsistente Konfigurationen in allen Umgebungen aufrechterhalten werden.
1. Implementieren Sie Warnmechanismen, damit jegliche Konfigurationsabweichungen oder Unterbrechungen oder Verzögerungen der Datenreplikation nachverfolgt werden und eine entsprechende Benachrichtigung erfolgt.
1. Automatisieren Sie die Behebung erkannter Konfigurationsabweichungen.
1. Planen Sie regelmäßige Überwachungen und Konformitätsprüfungen ein, um die fortlaufende Abstimmung zwischen der primären Konfiguration und der Konfiguration für die Notfallwiederherstellung zu überprüfen. Regelmäßige Überprüfungen helfen Ihnen dabei, die Einhaltung definierter Regeln sicherzustellen und etwaige Unstimmigkeiten zu identifizieren, die behoben werden müssen.
1. Prüfen Sie, ob es Diskrepanzen in Bezug auf die von AWS bereitgestellte Kapazität, die Service Quotas, die Drosselungsgrenzen, Konfigurationen und Versionen gibt.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL01-BP01 Kenntnis von Service Quotas und Einschränkungen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Verwalten von Service Quotas für mehrere Konten und Regionen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Überwachen und Verwalten von Kontingenten](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Zugehörige Dokumente:**
+ [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)
+ [AWS CloudFormation: Erkennen von nicht verwalteten Konfigurationsänderungen an Stacks und Ressourcen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation: Ermitteln von Abweichungen im gesamten CloudFormation-Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Notfallwiederherstellung von Workloads in 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)
**Zugehörige Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**Zugehörige Beispiele:**
+ [CloudFormation Registry](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Implementieren der automatischen Behebung von Abweichungen für AWS CloudFormation unter Verwendung von Amazon CloudWatch und AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Architecture Blog: Notfallwiederherstellung](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)
+ [Automatisierung sicherer, vollautomatischer Bereitstellungen](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Automatisieren der Wiederherstellung
Implementieren Sie getestete und automatisierte Wiederherstellungsmechanismen, die zuverlässig, beobachtbar und reproduzierbar sind, um das Risiko und die Auswirkungen von Ausfällen auf das Geschäft zu reduzieren.
**Gewünschtes Ergebnis:** Sie haben einen gut dokumentierten, standardisierten und gründlich getesteten Automatisierungs-Workflow für Wiederherstellungsprozesse implementiert. Ihre Wiederherstellungsautomatisierung behebt automatisch kleinere Probleme, bei denen das Risiko von Datenverlusten oder Nichtverfügbarkeit gering ist. Sie sind in der Lage, bei schwerwiegenden Vorfällen schnell Wiederherstellungsprozesse aufzurufen, das Problembehebungsverhalten während der Ausführung zu beobachten und die Prozesse zu beenden, wenn Sie gefährliche Situationen oder Fehler beobachten.
**Typische Anti-Muster:**
+ Für Ihren Wiederherstellungsplan sind Sie auf Komponenten oder Mechanismen angewiesen, die ausgefallen oder beeinträchtigt sind.
+ Ihre Wiederherstellungsprozesse erfordern manuelle Eingriffe, z. B. den Zugriff auf die Konsole (auch als *ClickOps* bezeichnet).
+ Sie leiten automatisch Wiederherstellungsverfahren in Situationen ein, in denen ein hohes Risiko von Datenverlusten oder Nichtverfügbarkeit besteht.
+ Sie beziehen keinen Mechanismus (wie z. B. ein *Andon-Cord* oder eine *große rote Stopptaste*) ein, mit dem Sie ein Wiederherstellungsverfahren abbrechen können, das nicht funktioniert oder zusätzliche Risiken birgt.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Höhere Zuverlässigkeit, Vorhersehbarkeit und Konsistenz der Wiederherstellungsvorgänge.
+ Fähigkeit, strengere Ziele für die Wiederherstellung, einschließlich Recovery Time Objective (RTO) und Recovery Point Objective (RPO), zu erfüllen.
+ Geringere Wahrscheinlichkeit, dass die Wiederherstellung während eines Vorfalls fehlschlägt.
+ Geringeres Risiko von Fehlern im Zusammenhang mit manuellen Wiederherstellungsprozessen, die anfällig für menschliche Fehler sind.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
Um die automatisierte Wiederherstellung zu implementieren, benötigen Sie einen umfassenden Ansatz, der AWS-Services und bewährte Methoden nutzt. Identifizieren Sie zunächst kritische Komponenten und potenzielle Fehlerquellen in Ihrem Workload. Entwickeln Sie automatisierte Prozesse, mit denen Sie Ihre Workloads und Daten nach Ausfällen ohne menschliches Eingreifen wiederherstellen können.
Entwickeln Sie Ihre Wiederherstellungsautomatisierung unter Berücksichtigung der Prinzipien von Infrastructure as Code (IaC). Auf diese Weise wird Ihre Wiederherstellungsumgebung mit der Quellumgebung konsistent und es ist eine Versionsverwaltung Ihrer Wiederherstellungsprozesse möglich. Um komplexe Wiederherstellungs-Workflows zu orchestrieren, sollten Sie Lösungen wie [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) oder [AWS Step Functions](https://aws.amazon.com/step-functions/) in Betracht ziehen.
Die Automatisierung von Wiederherstellungsprozessen bietet erhebliche Vorteile und kann Ihnen helfen, Ihr Recovery Time Objective (RTO) und Recovery Point Objective (RPO) leichter zu erreichen. Die Prozesse können jedoch auf unerwartete Situationen stoßen. Diese können zu einem Ausfall der Prozesse führen oder neue Risiken wie zusätzliche Ausfallzeiten und Datenverluste mit sich bringen. Um dieses Risiko zu minimieren, sollten Sie die Möglichkeit bieten, eine laufende Wiederherstellungsautomatisierung schnell zu unterbrechen. Nach der Unterbrechung des Prozesses können Sie Nachforschungen anstellen und Korrekturmaßnahmen ergreifen.
Für unterstützte Workloads sollten Sie Lösungen wie AWS Elastic Disaster Recovery (AWSDRS) in Betracht ziehen, um ein automatisiertes Failover zu ermöglichen. AWS DRS repliziert Ihre Computer (einschließlich Betriebssystem, Systemstatuskonfiguration, Datenbanken, Anwendungen und Dateien) kontinuierlich in einen Staging-Bereich in Ihrem Ziel-AWS-Konto und in Ihrer bevorzugten Region. Bei einem Vorfall automatisiert AWS DRS die Konvertierung Ihrer replizierten Server in vollständig bereitgestellte Workloads in Ihrer Wiederherstellungsregion in AWS.
Die Wartung und Verbesserung der automatisierten Wiederherstellung ist ein fortlaufender Prozess. Testen und verfeinern Sie Ihre Wiederherstellungsverfahren kontinuierlich auf der Grundlage der gewonnenen Erkenntnisse und halten Sie sich über neue AWS-Services und -Features auf dem Laufenden, die Ihre Wiederherstellungsmöglichkeiten verbessern können.
### Implementierungsschritte
1. **Planen der automatisierten Wiederherstellung**
1. Führen Sie eine gründliche Überprüfung Ihrer Workload-Architektur, Ihrer Komponenten und Abhängigkeiten durch, um automatisierte Wiederherstellungsmechanismen zu identifizieren und zu planen. Unterteilen Sie die Abhängigkeiten Ihres Workloads in *harte* und *weiche* Abhängigkeiten. Harte Abhängigkeiten sind Abhängigkeiten, ohne die der Workload nicht funktionieren kann und für die kein Ersatz bereitgestellt werden kann. Weiche Abhängigkeiten sind Abhängigkeiten, die der Workload normalerweise nutzt, die aber durch temporäre Ersatzsysteme oder -prozesse ersetzt werden können oder die durch eine [Graceful Degradation](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation) bewältigt werden können.
1. Richten Sie Prozesse ein, um fehlende oder beschädigte Daten zu identifizieren und wiederherzustellen.
1. Definieren Sie Schritte zur Bestätigung eines wiederhergestellten stabilen Zustands nach Abschluss der Wiederherstellungsmaßnahmen.
1. Berücksichtigen Sie alle Maßnahmen, die erforderlich sind, um das wiederhergestellte System vollständig einsatzbereit zu machen, z. B. das Vorwärmen und das Auffüllen von Caches.
1. Denken Sie an Probleme, die während des Wiederherstellungsprozesses auftreten könnten, und überlegen Sie, wie Sie diese erkennen und beheben können.
1. Stellen Sie sich Szenarien vor, in denen kein Zugriff auf den primären Standort und die zugehörige Steuerungsebene möglich ist. Stellen Sie sicher, dass Wiederherstellungsaktionen unabhängig durchgeführt werden können, ohne auf den primären Standort angewiesen zu sein. Ziehen Sie Lösungen wie [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) in Betracht, um den Datenverkehr umzuleiten, ohne dass DNS-Einträge manuell mutiert werden müssen.
1. **Entwicklung eines automatisierten Wiederherstellungsprozesses**
1. Implementieren Sie automatisierte Fehlererkennungs- und Failover-Mechanismen für eine Wiederherstellung ohne manuelle Eingriffe. Erstellen Sie Dashboards, beispielsweise mit [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), um den Fortschritt und den Zustand automatisierter Wiederherstellungsverfahren zu melden. Schließen Sie Verfahren zur Validierung einer erfolgreichen Wiederherstellung ein. Stellen Sie einen Mechanismus bereit, um eine laufende Wiederherstellung abzubrechen.
1. Erstellen Sie [Playbooks](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) als Ausweichlösung für Fehler, die nicht automatisch behoben werden können, und berücksichtigen Sie Ihren [Plan für die Notfallwiederherstellung](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts).
1. Testen Sie die Wiederherstellungsprozesse, wie in [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html) beschrieben.
1. **Vorbereitung auf die Wiederherstellung**
1. Evaluieren Sie den Zustand Ihres Wiederherstellungsstandorts und stellen Sie wichtige Komponenten im Voraus bereit. Weitere Informationen finden Sie unter [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).
1. Definieren Sie klare Rollen, Verantwortlichkeiten und Entscheidungsprozesse für Wiederherstellungsoperationen und beziehen Sie dabei die relevanten Stakeholder und Teams im gesamten Unternehmen ein.
1. Definieren Sie die Bedingungen für die Einleitung Ihrer Wiederherstellungsprozesse.
1. Erstellen Sie einen Plan, um den Wiederherstellungsprozess rückgängig zu machen und bei Bedarf, oder nachdem dies als sicher erachtet wird, auf Ihren primären Standort zurückzugreifen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL07-BP01 Automatisiertes Abrufen oder Skalieren von Ressourcen](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Verwalten der Konfigurationsabweichungen am Standort oder in der Region der Notfallwiederherstellung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Zugehörige Dokumente:**
+ [AWS Architecture Blog: Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads in 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)
+ [Orchestrieren der Automatisierung der Notfallwiederherstellung mit Amazon Route 53 ARC und AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Erstellen von AWS-Systems-Manager-Automation-Runbooks mithilfe von AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [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)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Verwenden von Elastic Disaster Recovery für Failover und Failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [AWS Elastic Disaster Recovery – Ressourcen](https://aws.amazon.com/disaster-recovery/resources/)
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Zugehörige Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)