# Fehlerverwaltung
**Topics**
+ [ZUV 9 Was ist bei der Sicherung von Daten zu beachten?](w2aac19b9c11b5.md)
+ [ZUV 10 Wie schützen Sie Ihren Workload mithilfe der Fehlerisolierung?](w2aac19b9c11b7.md)
+ [ZUV 11 Wie lassen sich Workloads so gestalten, dass sie Komponentenausfälle verkraften?](w2aac19b9c11b9.md)
+ [ZUV 12 Wie lässt sich die Zuverlässigkeit testen?](w2aac19b9c11c11.md)
+ [ZUV 13 Was ist bei der Planung der Notfallwiederherstellung zu beachten?](w2aac19b9c11c13.md)
# ZUV 9 Was ist bei der Sicherung von Daten zu beachten?
Sichern Sie Daten, Anwendungen und Konfigurationen, um die Anforderungen im Hinblick auf das Recovery Time Objective (RTO, Wiederherstellungsdauer) und das Recovery Point Objective (RPO, Wiederherstellungszeitpunkt) zu erfüllen.
**Topics**
+ [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Schützen und Verschlüsseln von Backups](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Automatische Daten-Backups](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Verifizieren der Sicherungsintegrität und -verfahren durch regelmäßiges Wiederherstellen der Daten](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen
Alle AWS-Datenspeicher bieten Backup-Möglichkeiten. Services wie Amazon RDS und Amazon DynamoDB unterstützen zusätzlich ein automatisiertes Backup, das eine zeitpunktbezogene Wiederherstellung (PITR) ermöglicht. So können Sie Backups zu einem beliebigen Zeitpunkt bis zu fünf Minuten oder weniger vor dem aktuellen Zeitpunkt wiederherstellen. Viele AWS-Services bieten die Möglichkeit, Backups in eine andere AWS-Region zu kopieren. AWS Backup ist ein Tool, mit dem Sie Datensicherungsprozesse über verschiedene AWS-Services hinweg zentralisieren und automatisieren können.
Amazon S3 kann als Backup-Ziel für selbstverwaltete und AWS-verwaltete Datenquellen verwendet werden. AWS-Services wie Amazon EBS, Amazon RDS und Amazon DynamoDB bieten integrierte Möglichkeiten zur Backup-Erstellung. Sicherungssoftware von Drittanbietern kann ebenfalls eingesetzt werden.
On-Premises-Daten können in AWS Cloud unter Verwendung von [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) oder [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)gesichert werden. Amazon S3-Buckets können genutzt werden, um diese Daten in AWS zu speichern. Amazon S3 bietet mehrere Speicherebenen wie [Amazon Glacier oder S3 Glacier Deep Archive,](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) um die Datenspeicherkosten zu senken.
Möglicherweise können Sie Ihre Datenwiederherstellungs-Anforderungen erfüllen, indem Sie Daten aus anderen Quellen reproduzieren. So könnten beispielsweise [Amazon ElastiCache-Replikatknoten](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) oder [RDS-Lesereplikate](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) für das Reproduzieren von Daten verwendet werden, wenn die primären Daten verloren gegangen sind. Wenn solche Quellen für das Erreichen Ihrer [Recovery Time Objective (RTO) und Recovery Point Objective (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)genutzt werden können, benötigen Sie möglicherweise kein Backup. Weiteres Beispiel: Wenn Sie mit Amazon EMR arbeiten, ist es möglicherweise nicht erforderlich, Ihren HDFS-Datenspeicher zu sichern, solange Sie [die Daten in EMR von S3 reproduzieren können](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Bei der Auswahl einer Backup-Strategie sollten Sie die für die Datenwiederherstellung benötigte Zeit berücksichtigen. Diese hängt von der Art des Backups (im Falle einer Backup-Strategie) oder von der Komplexität des Datenreproduktions-Mechanismus ab. Die benötigte Zeit sollte im RTO für die Workload enthalten sein.
**Gewünschtes Ergebnis:**
Datenquellen wurden basierend auf Kritikalität identifiziert und klassifiziert. Anschließend legen Sie eine auf dem RPO basierende Strategie für die Datenwiederherstellung fest. Diese Strategie involviert entweder die Sicherung dieser Datenquellen oder die Möglichkeit, Daten aus anderen Quellen zu reproduzieren. Im Falle eines Datenverlusts ermöglicht die implementierte Strategie die Wiederherstellung oder Reproduktion von Daten innerhalb der definierten RPO und RTO.
**„Cloud-Reife“-Phase:** Foundational
**Gängige Antimuster:**
+ Nicht alle Datenquellen für die Workload und deren Kritikalität sind bekannt.
+ Es erfolgen keine Backups kritischer Datenquellen.
+ Es erfolgen nur Backups von manchen Datenquellen ohne die Verwendung von Kritikalität als Kriterium.
+ Es wurde kein RPO definiert oder die Backup-Häufigkeit kann den RPO nicht erfüllen.
+ Es erfolgt keine Bewertung, ob ein Backup erforderlich ist oder ob Daten aus anderen Quellen reproduziert werden können.
**Vorteile der Einführung dieser bewährten Methode:** Durch das Identifizieren der Orte, wo Backups notwendig sind und das Implementieren eines Mechanismus zur Erstellung von Backups bzw. die Möglichkeit, die Daten aus externen Quellen zu reproduzieren, ist es einfacher, Daten während eines Ausfalls wiederherzustellen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Sie sollten die Backup-Funktionen der von der Workload genutzten AWS-Services und -Ressourcen verstehen und nutzen. Die meisten AWS-Services stellen Funktionen für Backups von Workloaddaten bereit.
**Implementierungsschritte:**
1. **Identifizieren Sie alle Datenquellen für die Workload.**. Daten können in einer Reihe von Ressourcen gespeichert werden, wie z. B. [Datenbanken](https://aws.amazon.com/products/databases/), [Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [Dateisystemen](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [Protokollierungssystemen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)und [Objektspeicher](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Im Abschnitt **„Ressourcen“** finden Sie **Relevante Dokumente** zu verschiedenen AWS-Services, in denen Daten gespeichert werden, sowie die Backup-Funktionen dieser Services.
1. **Klassifizieren Sie Datenquellen basierend auf Kritikalität.**. Unterschiedliche Datensätze haben unterschiedliche Kritikalitäts-Niveaus für eine Workload und damit auch verschiedene Anforderungen an die Ausfallsicherheit. So können beispielsweise bestimmte kritische Daten einen RPO erfordern, der gegen Null geht, während bei anderen, weniger kritischen Daten, ein höherer RPO und somit ein gewisser Datenverlust toleriert werden kann. Ebenso können unterschiedliche Datensätze auch unterschiedliche RTO-Anforderungen haben.
1. **Nutzen Sie AWS- oder Drittanbieterservices, um Backups der Daten zu erstellen**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) ist ein verwalteter Service, mit dem Backups verschiedener Datenquellen auf AWS erstellt werden können. Die meisten dieser Services verfügen auch über native Funktionen für die Backup-Erstellung. Der AWS Marketplace umfasst zahlreiche Lösungen, die diese Funktionen ebenfalls bieten. Unter **„Ressourcen“** unten finden Sie weitere Informationen dazu, wie man Backups von Daten aus verschiedenen AWS-Services erstellt.
1. **Für Daten, die nicht gesichert werden, sollten Sie einen Datenreproduktions-Mechanismus festlegen**. Es gibt verschiedene Gründe dafür, Daten, die aus anderen Quellen reproduziert werden können, nicht zu sichern. Möglicherweise ergibt sich die Situation, dass es günstiger ist, Daten bei Bedarf aus Quellen zu reproduzieren als ein Backup zu erstellen, da mit der Speicherung von Backups gewisse Kosten verbunden sind. Ein weiterer Grund wäre, wenn das Wiederherstellen aus einem Backup länger dauert als die Reproduktion der Daten aus anderen Quellen, was zu einer Nichteinhaltung des RTO führen würde. In solchen Situationen sollten Sie sich einen Kompromiss überlegen und einen gut definierten Prozess festlegen, wie Daten aus diesen Quellen reproduziert werden können, wenn eine Datenwiederherstellung erforderlich ist. Wenn Sie beispielsweise Daten zur Analyse aus Amazon S3 in ein Data Warehouse (wie Amazon Redshift) oder einen MapReduce-Cluster (wie Amazon EMR) geladen haben, kann es sich dabei z. B. um Daten handeln, die aus anderen Quellen reproduziert werden können. Solange die Ergebnisse dieser Analysen gespeichert werden oder reproduzierbar sind, besteht kein Risiko eines Datenverlusts durch einen Ausfall im Data Warehouse oder MapReduce-Cluster. Andere Daten, die aus Quellen reproduziert werden können, sind Cache-Inhalte (z. B. Amazon ElastiCache) oder RDS Read Replicas.
1. **Legen Sie eine Kadenz für die Sicherung von Daten fest**. Das Erstellen von Datenquellen ist ein periodischer Prozess und die Häufigkeit sollte vom RPO abhängen.
**Grad des Aufwands für den Implementierungsplan:** Mittel
## Ressourcen
**Relevante bewährte Methoden:**
[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)
**Relevante Dokumente:**
+ [Was ist AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Was ist AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Was ist Volume Gateway?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [APN-Partner: Partner, die Sie bei der Sicherung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: Für die Sicherung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS Snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Backups von Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Backups von Amazon FSx für Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Backup und Wiederherstellung für ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Erstellen eines DB-Cluster-Snapshots in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Erstellen eines DB-Snapshots](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Erstellen einer EventBridge-Regel, die nach einem Zeitplan ausgelöst wird](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Regionsübergreifende Replikation](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) mit Amazon S3
+ [EFS-zu-EFS-Sicherung](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Exportieren von Protokolldaten zu Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Verwaltung des Objektlebenszyklus](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [On-Demand-Sicherung und Wiederherstellung in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Zeitpunktbezogene Wiederherstellung für DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Mit Amazon OpenSearch Service Index-Snapshots arbeiten](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**Relevante Videos:**
+ [AWS re: Ivent 2021 - Backup, disaster recovery, and ransomware protection with AWS (AWS re:Invent 2021 - Backup, Notfallwiederherstellung und Ransomware-Schutz mit AWS)](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup (AWS Backup Demo: Konto- und regionsübergreifendes Backup)](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS Backup re:Invent 2019: Ausführliche Beschreibung von AWS, mit Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Implementieren einer bidirektionalen Cross-Region Replication (CRR, regionsübergreifende Replikation) für Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Well-Architected Lab: Testen von Backup und Wiederherstellung von Daten](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected lab: Backup and Restore with Failback for Analytics Workload (Well-Architected Lab: Backups und Wiederherstellung mit Failback für Analytics-Workload)](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected Lab: Notfallwiederherstellung – Backup und Wiederherstellung](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Schützen und Verschlüsseln von Backups
Steuern und erkennen Sie den Zugriff auf Backups durch Authentifizierung und Autorisierung wie z. B. mit AWS IAM. Vermeiden und erkennen Sie mittels Verschlüsselung Beeinträchtigungen der Datenintegrität von Backups.
Amazon S3 unterstützt mehrere Verschlüsselungsmethoden für gespeicherte Daten. Mithilfe der serverseitigen Verschlüsselung akzeptiert Amazon S3 Ihre Objekte als unverschlüsselte Daten und sorgt für ihre Verschlüsselung bei der Speicherung. Bei der clientseitigen Verschlüsselung ist Ihre Workload-Anwendung für die Verschlüsselung der Daten verantwortlich, bevor sie an Amazon S3 gesendet werden. Beide Methoden ermöglichen Ihnen, zum Erstellen und Speichern des Datenschlüssels AWS Key Management Service (AWS KMS) zu verwenden oder einen eigenen Schlüssel bereitzustellen, für den Sie verantwortlich sind. Bei AWS KMS können Sie mithilfe von IAM festlegen, wer auf Ihre Datenschlüssel und entschlüsselten Daten zugreifen kann.
Wenn Sie bei Amazon RDS Ihre Datenbanken verschlüsseln, werden Ihre Sicherungsdaten ebenfalls verschlüsselt. DynamoDB-Sicherungen sind immer verschlüsselt.
**Gängige Antimuster:**
+ Derselbe Zugriff auf die Sicherungen und die automatisierte Wiederherstellung wie auf die Daten.
+ Keine Verschlüsselung der Sicherungen.
**Vorteile der Einführung dieser bewährten Methode:** Durch den Schutz der Datensicherungen wird eine Manipulation der Daten verhindert. Ihre Verschlüsselung verhindert den Zugriff auf die Daten, wenn sie versehentlich offengelegt werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Verwenden Sie die Verschlüsselung für jeden Datenspeicher. Wenn Ihre Quelldaten verschlüsselt sind, wird die Sicherung ebenfalls verschlüsselt.
+ Aktivieren Sie die Verschlüsselung in RDS. Beim Erstellen einer RDS-Instance können Sie die Verschlüsselung im Ruhezustand mit AWS Key Management Service konfigurieren.
+ [Verschlüsseln von Amazon RDS-Ressourcen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Aktivieren Sie die Verschlüsselung für EBS-Volumes. Während der Erstellung von Volumes können Sie eine Standardverschlüsselung konfigurieren oder einen eindeutigen Schlüssel angeben.
+ [Amazon EBS-Verschlüsselung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Verwenden Sie die erforderliche Amazon DynamoDB-Verschlüsselung. DynamoDB verschlüsselt alle Daten im Ruhezustand. Sie können entweder einen AWS-eigenen AWS KMS-Schlüssel oder einen AWS-verwalteten KMS-Schlüssel verwenden und dabei einen Schlüssel angeben, der in Ihrem Konto gespeichert wird.
+ [DynamoDB-Verschlüsselung im Ruhezustand](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Verwalten verschlüsselter Tabellen](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Verschlüsseln Sie Ihre in Amazon EFS gespeicherten Daten. Konfigurieren Sie die Verschlüsselung beim Erstellen des Dateisystems.
+ [Verschlüsseln von Daten und Metadaten in EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ Konfigurieren Sie die Verschlüsselung in den Quell- und Zielregionen. Sie können die Verschlüsselung im Ruhezustand in Amazon S3 mit Schlüsseln konfigurieren, die in KMS gespeichert sind. Die Schlüssel sind jedoch regionsspezifisch. Sie können die Zielschlüssel angeben, während Sie die Replikation konfigurieren.
+ [Zusätzliche CRR-Konfiguration: Replizieren von Objekten, die mit serverseitiger Verschlüsselung (SSE) unter Verwendung von Verschlüsselungsschlüsseln erstellt wurden, die in AWS KMS gespeichert wurden.](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ Implementieren Sie Rechte mit geringsten Berechtigungen für den Zugriff auf Ihre Backups. Begrenzen Sie den Zugriff auf die Backups, Snapshots und Replikate anhand bewährter Methoden im Bereich Sicherheit.
+ [Säule „Sicherheit“: AWS Well-Architected](./wat.pillar.security.en.html)
## Ressourcen
**Relevante Dokumente:**
+ [AWS Marketplace: Für die Sicherung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS-Verschlüsselung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: Daten durch Verschlüsselung schützen](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Zusätzliche CRR-Konfiguration: Replizieren von Objekten, die mit serverseitiger Verschlüsselung (SSE) unter Verwendung von Verschlüsselungsschlüsseln erstellt wurden, die in AWS KMS gespeichert wurden.](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [DynamoDB-Verschlüsselung im Ruhezustand](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Verschlüsseln von Amazon RDS-Ressourcen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Verschlüsseln von Daten und Metadaten in EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Verschlüsselung für Backups in AWS.](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Verwalten verschlüsselter Tabellen](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Säule „Sicherheit“: AWS Well-Architected](./wat.pillar.security.en.html)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Implementieren einer bidirektionalen Cross-Region Replication (CRR, regionsübergreifende Replikation) für Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Automatische Daten-Backups
Sie können die Backups so konfigurieren, dass sie automatisch nach Zeitplan, der auf dem Recovery Point Objective (RPO) basiert, oder bei Änderungen am Datensatz durchgeführt werden. Kritische Datensätze, bei denen Datenverlust vermieden werden sollte, müssen regelmäßig automatisch gesichert werden, wohingegen weniger kritische Daten, bei denen ein gewisser Verlust akzeptabel ist, weniger häufig gesichert werden können.
AWS Backup kann zum Erstellen von automatisierten Daten-Backups verschiedener AWS-Datenquellen genutzt werden. Amazon RDS-Instances können fast kontinuierlich alle fünf Minuten gesichert werden und Amazon S3-Objekte können praktisch durchgehend alle 15 Minuten gesichert werden, was eine zeitpunktbezogene Wiederherstellung (PITR) an einem bestimmten Zeitpunkt im Backup-Verlauf ermöglicht. Andere AWS-Datenquellen wie Amazon EBS-Volumes, Amazon DynamoDB-Tabellen oder Amazon FSx-Dateisysteme kann AWS Backup stündlich ein automatisiertes Backup ausführen. Diese Service bieten auch native Backup-Funktionen. Zu den AWS-Services, die ein automatisiertes Backup mit zeitpunktbezogener Wiederherstellung bieten, gehören: [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)und [Amazon Keyspaces (für Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) – diese können an einem bestimmten Zeitpunkt im Backup-Verlauf wiederhergestellt werden. Die meisten anderen AWS-Datenspeicher-Services bieten die Möglichkeit, stündliche periodische Backups einzuplanen.
Amazon RDS und Amazon DynamoDB ermöglichen eine kontinuierliche Sicherung mit zeitpunktbezogener Wiederherstellung. Die Amazon S3-Versionsverwaltung erfolgt nach der Aktivierung automatisch. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) kann genutzt werden, um das Erstellen, Kopieren und Löschen von Amazon EBS-Snapshots zu automatisieren. Außerdem kann damit das Erstellen, das Kopieren, die Deprekation und die Abmeldung von Amazon EBS-gestützten Amazon Machine Images (AMIs) und den zugrunde liegenden Amazon EBS-Snapshots automatisiert werden.
Für eine zentrale Ansicht Ihrer Sicherungsautomatisierung und des Verlaufs bietet AWS Backup eine vollständig verwaltete, richtlinienbasierte Sicherungslösung. Diese zentralisiert und automatisiert die Sicherung von Daten in mehreren AWS-Services in der Cloud sowie vor Ort mithilfe des AWS Storage Gateway.
Zusätzlich zum Versioning bietet Amazon S3 eine Replikationsfunktion. Der gesamte S3-Bucket kann automatisch in einen anderen Bucket in einer anderen AWS-Region repliziert werden.
**Gewünschtes Ergebnis:**
Ein automatisierter Prozess, der Backups von Datenquellen in einer festgelegten Kadenz erstellt.
**Gängige Antimuster:**
+ Sicherungen werden manuell durchgeführt.
+ Es werden Ressourcen mit Sicherungsfunktionen verwendet, die Sicherung wird aber nicht in die Automatisierung einbezogen.
**Vorteile der Einführung dieser bewährten Methode:** Durch die Automatisierung von Backups wird sichergestellt, dass diese regelmäßig auf Grundlage Ihres RPO erstellt werden und Sie andernfalls benachrichtigt werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
1. **Identifizieren Sie Datenquellen,** die aktuell manuell gesichert werden. 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 Anweisungen hierzu.
1. **Bestimmen Sie den RPO** für die Workload. Unter [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md) finden Sie weitere Anweisungen hierzu.
1. **Nutzen Sie eine automatisierte Backup-Lösung oder einen verwalteten Service**. AWS Backup ist ein vollständig verwalteter Service, der das [Zentralisieren und Automatisieren des Datenschutzes über verschiedene AWS-Services hinweg, in der Cloud sowie vor Ort erleichtert.](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Backup-Pläne sind ein Feature von AWS Backup, mit dem Regeln erstellt werden können, die die zu sichernden Ressourcen sowie die Häufigkeit, mit der diese Backups erstellt werden, definieren. Diese Häufigkeit sollte auf dem in Schritt 2 festgelegten RPO basieren. [Dieses WA Lab](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) bietet eine praktische Anleitung zur Erstellung von automatisierten Backups mit AWS Backup. Native Backup-Funktionen werden von den meisten AWS-Services, die Daten speichern, angeboten. So kann beispielsweise RDS für automatisierte Backups mit zeitpunktbezogener Wiederherstellung (PITR) genutzt werden.
1. **Für Datenquellen, die nicht** von einer automatisierten Backup-Lösung oder einem verwalteten Service unterstützt werden, wie etwa On-Premises-Datenquellen oder Nachrichten-Warteschlangen, können Sie für die Erstellung von automatisierten Backups eine Lösung von einem zuverlässigen Drittanbieter in Betracht ziehen. Als Alternative können Sie die Automatisierung für diesen Vorgang mit der AWS CLI oder mit SDKs erstellen. Sie können AWS Lambda-Funktionen oder AWS Step Functions nutzen, um die in die Erstellung eines Daten-Backups einbezogene Logik zu definieren und Amazon EventBridge verwenden, um es in einer auf Ihrem RPO (wie in Schritt 2 festgelegt) basierenden Häufigkeit auszuführen.
**Grad des Aufwands für den Implementierungsplan:** Niedrig
## Ressourcen
**Ähnliche Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Sicherung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: Für die Sicherung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Erstellen einer EventBridge-Regel, die nach einem Zeitplan ausgelöst wird](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Was ist AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Was ist AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**Ähnliche Videos:**
+ [AWS re:Invent 2019: Ausführliche Beschreibung von AWS Backup, mit Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Testen von Backup und Wiederherstellung von Daten](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Verifizieren der Sicherungsintegrität und -verfahren durch regelmäßiges Wiederherstellen der Daten
Überprüfen Sie mit einem Wiederherstellungstest, ob sich mit Ihren Sicherungsverfahren das RTO und das RPO einhalten lassen.
Mit AWS können Sie eine Testumgebung einrichten und Ihre Sicherungen wiederherstellen, um RTO- und RPO-Funktionen zu bewerten und Tests für Dateninhalte und Integrität durchzuführen.
Darüber hinaus ermöglichen Amazon RDS und Amazon DynamoDB eine Point-in-Time-Wiederherstellung. Durch die kontinuierliche Sicherung können Sie Ihren Datensatz in den Zustand zurücksetzen, in dem er sich an einem bestimmten Datum und zu einer bestimmten Uhrzeit befand.
**Gewünschtes Ergebnis:** Daten aus Backups werden mittels gut definierter Mechanismen regelmäßig wiederhergestellt, um zu gewährleisten, dass die Wiederherstellung innerhalb des festgelegten Recovery Time Objective (RTO) für die Workload möglich ist. Überprüfen Sie, dass die Wiederherstellung aus einem Backup in eine Ressource erfolgt, die die Originaldaten enthält und dass keine dieser Daten korrupt oder nicht zugänglich sind, sowie dass sich der Datenverlust im Rahmen des Recovery Point Objective (RPO) bewegt.
**Gängige Antimuster:**
+ Eine Sicherung wird wiederhergestellt, es werden aber keine Daten abgefragt oder abgerufen, um sicherzustellen, dass die Wiederherstellung nutzbar ist.
+ Es wird angenommen, dass ein Backup existiert.
+ Es wird angenommen, dass das Backup eines System voll funktionsfähig ist und Daten daraus wiederhergestellt werden können.
+ Es wird angenommen, dass die Zeit für das Wiederherstellen von Daten aus einem Backup innerhalb des RTO für die Workload liegt.
+ Es wird angenommen, dass die im Backup enthaltenen Daten in den RPO für die Workload fallen.
+ Es erfolgt eine Ad-hoc-Wiederherstellung ohne die Nutzung eines Runbooks oder außerhalb eines festgelegten automatisierten Verfahrens.
**Vorteile der Einführung dieser bewährten Methode:** Durch das Testen der Wiederherstellung der Backups stellen Sie sicher, dass Daten bei Bedarf wiederhergestellt werden können (ohne dass Sie sich um fehlende oder korrupte Daten sorgen müssen), dass die Wiederherstellung innerhalb des RTO für die Workload möglich ist und dass sich mögliche Datenverluste im Rahmen des RPO für die Workload bewegen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
Das Testen der Sicherungs- und Wiederherstellungsfunktionen stärkt das Vertrauen in die Fähigkeit zur Durchführung dieser Aktionen während eines Ausfalls. Stellen Sie regelmäßig Backups an einem neuen Speicherort wieder her und führen Sie Tests aus, um die Datenintegrität zu überprüfen. Zu den gängigen Tests, die ausgeführt werden sollten, gehören
das Überprüfen, ob die Daten verfügbar sind, nicht korrupt sind, zugänglich sind und ob ein möglicher Datenverlust innerhalb des RPO für die Workload liegt. Solche Tests können dabei helfen, zu ermitteln, ob die Wiederherstellungsmechanismen schnell genug sind, um dem RTO der Workload gerecht zu werden.
1. **Identifizieren Sie Datenquellen,** für die derzeit Backups erstellt werden, und prüfen Sie, wo diese Backups gespeichert werden. 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 eine Anleitung dazu, wie Sie dies umsetzen können.
1. **Legen Sie Kriterien für die Datenvalidierung** für jede Datenquelle fest. Verschieden Datentypen können unterschiedliche Eigenschaften aufweisen und somit auch unterschiedliche Validierungsmechanismen erfordern. Überlegen Sie, wie diese Daten validiert werden können, bevor Sie sie in der Produktion einsetzen. Häufig werden für die Datenvalidierung Daten- und Sicherungseigenschaften wie Datentyp, Format, Prüfsumme, Größe oder eine Kombination dieser Eigenschaften mit einer benutzerdefinierten Validierungslogik verwendet. Ein Beispiel hierfür wäre der Vergleich der Prüfsummenwerte zwischen der wiederhergestellten Ressource und der Datenquelle zum Zeitpunkt der Erstellung des Backups.
1. **Bestimmen Sie RTO und RPO,** um die Daten basierend auf der Datenkritikalität wiederherzustellen. Unter [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md) finden Sie eine Anleitung dazu, wie Sie dies umsetzen können.
1. **Bewerten Sie die Funktion zur Datenwiederherstellung**. Prüfen Sie Ihre Sicherungs- und Wiederherstellungsstrategie, um festzustellen, ob sie Ihre RTO und RPO erfüllen kann, und passen Sie die Strategie bei Bedarf an. Mit [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html)können Sie eine Bewertung Ihrer Workload durchführen. Dabei wird Ihre Anwendungskonfiguration im Hinblick auf die Ausfallsicherheitsrichtlinien bewertet und Sie erfahren, ob Ihre RTO- und RPO-Ziele erfüllt werden können.
1. **Führen Sie eine Test-Wiederherstellung** mit den aktuell festgelegten Prozessen, die in der Produktion für die Datenwiederherstellung genutzt werden, durch. Diese Prozesse hängen davon ab, wie die ursprüngliche Datenquelle gesichert wurde sowie vom Format und der Speicherung des Backups selbst oder davon, ob die Daten aus anderen Quellen reproduziert werden. Wenn Sie beispielsweise einen verwalteten Service wie [AWS Backup verwenden, könnte der Prozess ganz einfach darin bestehen, das Backup in einer neuen Ressource wiederherzustellen.](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Wenn Sie AWS Elastic Disaster Recovery verwendet haben, können Sie [einen Wiederherstellung-Drill starten](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Validieren Sie die Datenwiederherstellung** aus der wiederhergestellten Ressource (im vorangegangenen Schritt) basierend auf Kriterien, die Sie zuvor in Schritt 2 für die Datenvalidierung festgelegt haben. Enthalten diese wiederhergestellten Daten den neuesten Datensatz/das neueste Element zum Zeitpunkt des Backups? Fallen diese Daten in den RPO für die Workload?
1. **Ermitteln Sie die für das** Wiederherstellen benötigte Zeit und vergleichen Sie sie mit dem in Schritt 3 festgelegten RTO. Ist dieser Prozess Teil des RTO für die Workload? Vergleichen Sie beispielsweise den Zeitstempel des Starts des Wiederherstellungsprozesses und des Abschlusses der Wiederherstellungsbewertung, um zu ermitteln, wie lange dieser Prozess dauert. Alle AWS-API-Aufrufe haben einen Zeitstempel. Sie finden diese Informationen unter [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Während diese Informationen Details dazu liefern können, wann der Wiederherstellungsprozess gestartet wurde, sollte der End-Zeitstempel für den Abschluss der Validierung von der Validierungslogik aufgezeichnet werden. Wenn Sie einen automatisierten Prozess verwenden, können Services wie [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) zum Speichern dieser Informationen genutzt werden. Darüber hinaus können viele AWS-Services ein Ereignisprotokoll bereitstellen, das mit einem Zeitstempel versehene Informationen dazu enthält, wann bestimmte Aktionen aufgetreten sind. Innerhalb von AWS Backup werden Sicherungs- und Wiederherstellungsaktionen als *Jobs*bezeichnet. Diese Jobs enthalten Zeitstempelinformationen als Teil ihrer Metadaten, die zum Ermitteln der für die Wiederherstellung benötigte Zeit verwendet werden können.
1. **Benachrichtigen Sie die Beteiligten,** wenn die Datenvalidierung fehlschlägt oder die für die Wiederherstellung benötigte Zeit den festgelegten RTO für die Workload überschreitet. Beim Implementieren der Automatisierung hierfür, [wie in diesem Lab](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), können Services wie Amazon Simple Notification Service (Amazon SNS) genutzt werden, um Push-Benachrichtigungen wie E-Mails oder SMS an die Beteiligten zu senden. [Diese Benachrichtigungen können auch in Nachrichtenanwendungen wie Amazon Chime, Slack oder Microsoft Teams veröffentlicht](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) oder dazu verwendet werden, [Aufgaben anhand von AWS Systems Manager OpsCenter als OpsItems zu erstellen](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Lassen Sie diesen Prozess regelmäßig automatisch ausführen**. Sie können beispielsweise Services wie AWS Lambda oder einen Zustandsautomaten in AWS Step Functions nutzen, um die Wiederherstellungsprozesse zu automatisieren. Außerdem können Sie Amazon EventBridge verwenden, um diesen automatisierten Workflow regelmäßig auszulösen, wie im folgenden Architekturdiagramm abgebildet. Erfahren Sie, wie Sie [die Validierung der Datenwiederherstellung mit AWS Backup automatisieren](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Darüber hinaus bietet [dieses Well-Architected Lab](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) eine praktische Schulung zum Automatisieren mehrerer der hier aufgeführten Schritte.
![\[Diagramm: automatisierter Sicherungs- und Wiederherstellungsprozess\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**Grad des Aufwands für den Implementierungsplan:** Mittel bis hoch, je nach Komplexität des Validierungskriteriums.
## Ressourcen
**Ähnliche Dokumente:**
+ [die Validierung der Datenwiederherstellung mit AWS Backup automatisieren](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [APN-Partner: Partner, die Sie bei der Sicherung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: Für die Sicherung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Erstellen einer EventBridge-Regel, die nach einem Zeitplan ausgelöst wird](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [On-Demand-Sicherung und Wiederherstellung in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [Was ist AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Was ist AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Was ist AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Testen von Backup und Wiederherstellung von Daten](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# ZUV 10 Wie schützen Sie Ihren Workload mithilfe der Fehlerisolierung?
Fehlerisolierte Grenzen beschränken die Auswirkungen eines Ausfalls innerhalb eines Workloads auf eine begrenzte Anzahl von Komponenten. Komponenten außerhalb der Grenze sind vom Ausfall nicht betroffen. Wenn Sie mehrere fehlerisolierte Grenzen verwenden, können Sie die Auswirkungen auf Ihren Workload einschränken.
**Topics**
+ [REL10-BP01 Bereitstellen des Workloads an mehreren Standorten](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Auswählen der geeigneten Standorte für Ihre Multi-Standort-Bereitstellung](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Automatisierte Wiederherstellung für Komponenten, die auf einen einzelnen Standort beschränkt sind](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Verwenden von Bulkhead-Architekturen, um den Umfang von Beeinträchtigungen zu begrenzen](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Bereitstellen des Workloads an mehreren Standorten
Verteilen Sie die Workload-Daten und -Ressourcen über mehrere Availability Zones oder ggf. über mehrere AWS-Regionen. Die Standorte können so vielfältig wie nötig sein.
Eins der grundlegenden Prinzipien für das Servicedesign in AWS ist die Vermeidung von Single Points of Failure in der zugrunde liegenden physischen Infrastruktur. Dies treibt uns an, Software und Systeme zu entwickeln, die mehrere Availability Zones verwenden und Schutz beim Ausfall einer einzelnen Region bieten. Außerdem sollen Systeme gegen den Ausfall einzelner Compute-Knoten, einzelner Speicher-Volumes oder einzelner Instances einer Datenbank geschützt sein. Bei der Entwicklung eines Systems, das auf redundanten Komponenten basiert, muss gewährleistet sein, dass die Komponenten unabhängig voneinander betrieben werden und im Falle von AWS-Regionen autonom sind. Die Vorteile theoretischer Verfügbarkeitsberechnungen mit redundanten Komponenten sind nur anwendbar, wenn diese Voraussetzung erfüllt ist.
**Availability Zones (AZs)**
AWS-Regionen bestehen aus mehreren voneinander unabhängigen Availability Zones. Die einzelnen Availability Zones sind durch eine signifikante physische Distanz voneinander getrennt, um korrelierte Fehlerszenarios aufgrund von Umweltgefahren wie Feuer, Überflutungen und Tornados zu vermeiden. Jede Availability Zone verfügt außerdem über eine unabhängige physische Infrastruktur: eigene Verbindungen zur Stromversorgung, unabhängige Backup-Stromquellen, unabhängige mechanischen Services und unabhängige Netzwerkkonnektivität innerhalb der Availability Zone und darüber hinaus. Durch dieses Design bleiben Fehler in einem dieser Systeme auf die jeweils betroffene AZ beschränkt. Trotz ihrer geografischen Verteilung befinden sich Availability Zones in demselben regionalen Bereich, wodurch Netzwerke mit hohem Durchsatz und geringer Latenz ermöglicht werden. Die gesamte AWS-Region (über alle Availability Zones, die aus mehreren physisch unabhängigen Rechenzentren bestehen) kann wie ein logisches Bereitstellungsziel für Ihren Workload behandelt werden. Dies umfasst auch die Möglichkeit zum synchronen Replizieren von Daten (z. B. zwischen Datenbanken). So können Sie Availability Zones in einer Aktiv-Aktiv- oder einer Aktiv-Standby-Konfiguration nutzen.
Availability Zones sind voneinander unabhängig. Daher erhöht sich die Workload-Verfügbarkeit, wenn in der Architektur des Workloads mehrere Zonen verwendet werden. Einige AWS-Services (darunter auch die Amazon EC2-Instance-Datenebene) werden als strikte zonale Services bereitgestellt, die von denselben Fehlern betroffen sind wie die Availability Zone, in der sie sich befinden. Amazon EC2-Instances in den anderen AZs sind hingegen nicht betroffen und weiterhin funktionsfähig. Wenn entsprechend ein Fehler in einer Availability Zone zum Ausfall einer Amazon Aurora-Datenbank führt, kann eine Auslese-Replikat-Aurora-Instance in einer nicht betroffenen AZ automatisch zur primären Instance hochgestuft werden. Regionale AWS-Services wie Amazon DynamoDB wiederum verwenden intern mehrere Availability Zones in einer Aktiv-Aktiv-Konfiguration, um die Verfügbarkeitsdesignziele für den jeweiligen Service zu erfüllen, ohne dass Sie die AZ-Platzierung konfigurieren müssen.
![\[Diagramm einer mehrstufigen Architektur, die in drei Availability Zones bereitgestellt wird. Amazon S3 und Amazon DynamoDB nutzen immer automatisch mehrere AZs. Auch der ELB wird in allen drei Zonen bereitgestellt.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
Während Amazon EBS-Steuerebenen in der Regel die Möglichkeit bieten, Ressourcen innerhalb der gesamten Region (also in mehreren Availability Zones) zu verwalten, haben bestimmte Steuerebenen (wie AWS und Amazon EC2) die Fähigkeit, Ergebnisse in eine einzelne Availability Zone zu filtern. Wenn dies erledigt ist, wird die Anfrage nur in der angegebenen Availability Zone verarbeitet; dies reduziert die Wahrscheinlichkeit von Ausfällen in anderen Availability Zones. Dieses AWS CLI-Beispiel veranschaulicht das Abrufen von Amazon EC2-Instance-Informationen ausschließlich aus der Availability Zone „us-east-2c“:
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS Local Zones*
AWS Local Zones verhalten sich ähnlich wie Availability Zones innerhalb ihrer jeweiligen AWS-Region. Sie können als Platzierungsstandort für zonale AWS-Ressourcen wie Subnetze und EC2-Instances ausgewählt werden. Das Besondere daran ist, dass sie sich nicht in der zugehörigen AWS-Region befinden, sondern in der Nähe großer Ballungsräume, Industrie- und IT-Zentren, in denen derzeit keine AWS-Region vorhanden ist. Sie sorgen dennoch für eine sichere Verbindung mit hoher Bandbreite zwischen lokalen Workloads in der lokalen Zone und Workloads in der AWS-Region. Sie sollten AWS Local Zones verwenden, um Workloads mit Anforderungen an eine geringe Latenz näher bei Ihren Benutzern bereitzustellen.
**Amazon Global Edge Network**
Amazon Global Edge Network besteht aus Edge-Standorten in Städten auf der ganzen Welt. Amazon CloudFront nutzt dieses Netzwerk, um Inhalte mit geringerer Latenz für Endbenutzer bereitzustellen. Mit AWS Global Accelerator können Sie Ihre Workload-Endpunkte an diesen Edge-Standorten erstellen, um ein Onboarding in das globale AWS-Netzwerk in der Nähe Ihrer Benutzer zu ermöglichen. Amazon API Gateway können Sie Edge-optimierte API-Endpunkte mithilfe einer CloudFront-Verteilung verwenden, um den Client-Zugriff über den nächstgelegenen Edge-Standort zu erleichtern.
*AWS-Regionen*
AWS-Regionen sind autonom konzipiert. Daher können Sie dedizierte Kopien von Services für jede Region bereitstellen, um einen multiregionalen Ansatz zu verwenden.
Ein multiregionaler Ansatz wird häufig für Strategien der *Notfallwiederherstellung* eingesetzt, um Wiederherstellungsziele zu erfüllen, falls einmalige Ereignisse mit großer Reichweite auftreten. Siehe [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) für weitere Informationen zu diesen Strategien. Hier liegt der Schwerpunkt allerdings auf der *Verfügbarkeit*, wobei versucht wird, ein mittleres Betriebszeitziel über einen längeren Zeitraum zu erreichen. Wenn eine hohe Verfügbarkeit angestrebt wird, ist eine multiregionale Architektur normalerweise Aktiv-Aktiv konzipiert. Dabei sind die einzelnen Servicekopien (in den jeweiligen Regionen) aktiv (und bearbeiten Anfragen).
**Empfehlung**
Die Verfügbarkeitsziele für die meisten Workloads können mithilfe einer Multi-AZ-Strategie innerhalb einer einzelnen AWS-Region erfüllt werden. Ziehen Sie multiregionale Architekturen nur in Betracht, wenn für Workloads extreme Verfügbarkeitsanforderungen gelten oder andere Unternehmensziele eine solche Architektur erforderlich machen.
AWS bietet Ihnen die Möglichkeit, Services regionsübergreifend zu betreiben. AWS stellt beispielsweise eine fortlaufende asynchrone Datenreplikation mit Amazon S3-Replikation (Amazon Simple Storage Service), Amazon RDS-Lesereplikaten (u. a. Aurora-Lesereplikaten) und globalen Amazon DynamoDB-Tabellen bereit. Bei der fortlaufenden Replikation sind Versionen Ihrer Daten für die fast sofortige Nutzung in jeder aktiven Region verfügbar.
Mit AWS CloudFormation können Sie Ihre Infrastruktur definieren und einheitlich in AWS-Konten und AWS-Regionen bereitstellen. AWS CloudFormation StackSets erweitern diese Funktionen, indem Sie AWS CloudFormation-Stacks mit nur einem Vorgang in verschiedenen Konten und Regionen erstellen, aktualisieren oder löschen können. Bei Amazon EC2-Instance-Bereitstellungen wird ein AMI (Amazon Machine Image) verwendet, um Informationen wie die Hardwarekonfiguration und installierte Software bereitzustellen. Sie können eine Amazon EC2 Image Builder-Pipeline implementieren, die die benötigten AMIs erstellt, und diese in Ihre aktiven Regionen kopieren. Diese *goldenen AMIs* enthalten alles, was Sie zum Bereitstellen und Skalieren von Workloads in neuen Regionen benötigen.
Zum Weiterleiten von Datenverkehr ermöglichen sowohl Amazon Route 53 als auch AWS Global Accelerator das Definieren von Richtlinien, die angeben, welche Benutzer zu welchem aktiven regionalen Endpunkt geleitet werden. Mit Global Accelerator legen Sie für den Datenverkehr einen Prozentwert fest, der an die einzelnen Anwendungsendpunkte geleitet wird. Route 53 unterstützt diesen Ansatz mit Prozentwerten sowie eine Vielzahl weiterer Richtlinien, u. a. auf Grundlage der geografischen Nähe oder der Latenz. Global Accelerator nutzt automatisch das umfassende Netzwerk von AWS-Edge-Servern, um Datenverkehr an den Backbone des AWS-Netzwerks zu senden, sobald dies möglich ist. Dies führt zu einer geringeren Latenz bei Abfragen.
Alle diese Funktionen sind so konzipiert, dass die Autonomie der einzelnen Regionen erhalten wird. Es gibt nur sehr wenige Ausnahmen von diesem Ansatz, darunter unsere Services für eine weltweite Edge-Lieferung (z. B. Amazon CloudFront und Amazon Route 53) und die Steuerebene für den AWS Identity and Access Management-Service (IAM). Die meisten Services werden vollständig innerhalb einer einzigen Region betrieben.
**On-Premises-Rechenzentrum**
Für Workloads, die in einem On-Premises-Rechenzentrum ausgeführt werden, sollten Sie nach Möglichkeit eine hybride Umgebung erstellen. AWS Direct Connect bietet eine dedizierte Netzwerkverbindung zwischen Ihrem Standort und AWS, sodass eine Ausführung in beiden Umgebungen möglich ist.
Außerdem haben Sie die Möglichkeit, AWS-Infrastruktur und -Services mit AWS Outposts lokal auszuführen. AWS Outposts ist ein vollständig verwalteter Service, der die AWS-Infrastruktur, AWS-Services, APIs und Tools auf Ihr Rechenzentrum erweitert. Die gleiche Hardwareinfrastruktur, die in der AWS Cloud verwendet wird, wird dafür in Ihrem Rechenzentrum installiert. AWS Outposts werden dann mit der nächstgelegenen AWS-Region verbunden. Anschließend können Sie AWS Outposts verwenden, um Workloads mit geringer Latenz oder lokalen Datenverarbeitungsanforderungen zu unterstützen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Verwenden Sie mehrere Availability Zones und AWS-Regionen. Verteilen Sie die Workload-Daten und -Ressourcen über mehrere Availability Zones oder ggf. über mehrere AWS-Regionen. Die Standorte können so vielfältig wie nötig sein.
+ Regionale Services werden von Haus aus in Availability Zones bereitgestellt.
+ Dazu gehören Amazon S3, Amazon DynamoDB und AWS Lambda (wenn keine VPC-Verbindung vorhanden ist).
+ Stellen Sie Ihre Container-, Instance- und funktionsbasierten Workloads in mehreren Availability Zones bereit. Verwenden Sie Multi-AZ-Datenspeicher, einschließlich Cache. Nutzen Sie EC2 Auto Scaling, die ECS-Aufgabenplatzierung, ElastiCache-Cluster sowie bei Ausführung in Ihrer VPC AWS Lambda-Funktionen.
+ Verwenden Sie für die Bereitstellung von Auto-Scaling-Gruppen Subnetze in getrennten Availability Zones.
+ [Beispiel: Verteilen von Instances in Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Strategien zur Aufgabenplatzierung mit Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Konfigurieren einer AWS Lambda-Funktion für den Zugriff auf Ressourcen in einer Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Auswählen von Regionen und Availability Zones](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Verwenden Sie für die Bereitstellung von Auto-Scaling-Gruppen Subnetze in getrennten Availability Zones.
+ [Beispiel: Verteilen von Instances in Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Verwenden Sie ECS-Parameter für die Platzierung von Aufgaben unter Angabe von DB-Subnetzgruppen.
+ [Strategien zur Aufgabenplatzierung mit Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Nutzen Sie Subnetze in mehreren Availability Zones, wenn Sie eine in Ihrem VPC auszuführende Funktion konfigurieren.
+ [Konfigurieren einer AWS Lambda-Funktion für den Zugriff auf Ressourcen in einer Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Verwenden Sie mehrere Availability Zones mit ElastiCache-Clustern.
+ [Auswählen von Regionen und Availability Zones](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Wenn Ihr Workload für mehrere Regionen bereitgestellt werden muss, sollten Sie sich für eine Strategie mit mehreren Regionen entscheiden. Die meisten Zuverlässigkeitsanforderungen können mithilfe einer Multi-Availability-Zone-Strategie innerhalb einer einzelnen AWS-Region erfüllt werden. Verwenden Sie eine Multi-Regionen-Strategie, wenn notwendig, um Ihre Geschäftsanforderungen zu erfüllen.
+ [AWS re:Invent 2018: Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ Ein Backup in einer anderen AWS-Region kann zusätzliche Gewissheit bieten, dass Daten verfügbar sind, wenn sie benötigt werden.
+ Für einige Workloads gibt es gesetzliche Anforderungen, die eine Multi-Region-Strategie erfordern.
+ Evaluieren Sie AWS Outposts für Ihren Workload. Wenn Ihre Workload eine niedrige Latenz für Ihr Rechenzentrum vor Ort erfordert oder lokale Datenverarbeitungsanforderungen hat. Führen Sie anschließend AWS-Infrastruktur und -Services On-Premises mit AWS Outposts aus.
+ [Was ist AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Ermitteln Sie, ob AWS Local Zones Sie bei der Bereitstellung von Services für Ihre Benutzer unterstützt. Wenn Sie Anforderungen an eine geringe Latenz haben, prüfen Sie, ob sich AWS Local Zones in der Nähe Ihrer Benutzer befindet. Wenn dies der Fall ist, stellen Sie damit Workloads näher an diesen Benutzern bereit.
+ [AWS Local Zones – häufig gestellte Fragen](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Ressourcen
**Ähnliche Dokumente:**
+ [Globale AWS-Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones – häufig gestellte Fragen](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Strategien zur Aufgabenplatzierung mit Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Auswählen von Regionen und Availability Zones](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Beispiel: Verteilen von Instances in Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Globale Tabellen: Multiregionale Replikation mit DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Verwenden von Amazon Aurora Global Databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Blog-Reihe: Creating a Multi-Region Application with AWS Services (Erstellen einer Multi-Region-Anwendung mit AWS-Services)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Was ist AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation und Betrieb der globalen Netzwerkinfrastruktur von AWS (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Auswählen der geeigneten Standorte für Ihre Multi-Standort-Bereitstellung
## Gewünschtes Ergebnis
Für eine hohe Verfügbarkeit stellen Sie Ihre Workload-Komponenten (falls möglich) immer in mehreren Availability Zone (AZ) bereit, wie in Abbildung 10 dargestellt. Überdenken Sie bei Workloads mit extremen Anforderungen an die Ausfallsicherheit die Optionen für eine Multi-Region-Architektur genau.
![\[Diagramm einer resilienten Multi-AZ-Datenbankbereitstellung mit Backup in einer anderen AWS-Region\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## Gängige Antimuster
+ Entscheidung für das Design einer Multi-Region-Architektur, wenn eine Multi-AZ-Architektur für die Anforderungen ausreichend wäre.
+ Fehlende Berücksichtigung der Abhängigkeiten zwischen Anwendungskomponenten, wenn diese Komponenten unterschiedliche Anforderungen im Bezug auf Ausfallsicherheit und mehrere Standorte aufweisen.
## Vorteile der Einführung dieser bewährten Methode:
Für die Ausfallsicherheit sollten Sie einen Ansatz wählen, bei dem verschiedene Verteidigungsebenen aufgebaut werden. Eine Ebene schützt vor kleineren, häufiger auftretenden Unterbrechungen, indem eine hochverfügbare Architektur mit mehreren AZs erstellt wird. Eine weitere Verteidigungsebene schützt vor seltenen Ereignissen wie Naturkatastrophen mit großer Reichweite und Unterbrechungen auf Regionsebene. Für diese zweite Ebene muss die Architektur Ihrer Anwendung mehrere AWS-Regionen umfassen.
+ Der Unterschied zwischen einer Verfügbarkeit von 99,5 % und 99,99 % beträgt über 3,5 Stunden pro Monat. Die erwartete Verfügbarkeit eines Workloads kann nur „four nines“ (d. h. 99,99 %) erreichen, wenn er sich in mehreren AZs befindet.
+ Indem Sie einen Workload in mehreren AZs ausführen, können Sie Fehler bei der Stromversorgung, Kühlung, im Netzwerk sowie die meisten Naturkatastrophen wie Feuer und Überflutung isolieren.
+ Wenn Sie eine Multi-Region-Strategie für Ihren Workload implementieren, ist er vor weitreichenden Naturkatastrophen, die einen großen geografischen Bereich in einem Land betreffen, oder technischen Fehlern in einer ganzen Region geschützt. Beachten Sie dabei, dass das Implementieren einer Multi-Region-Architektur äußerst komplex sein kann und bei den meisten Workloads nicht erforderlich ist.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Bei einer Unterbrechung oder dem teilweisen Ausfall einer Availability Zone hilft die Implementierung eines hoch verfügbaren Workloads in mehreren Availability Zones innerhalb einer einzelnen AWS-Region, die Folgen von Naturkatastrophen oder technischen Problemen zu begrenzen. Jede AWS-Region besteht aus mehreren Availability Zones, die von Fehlern in den jeweils anderen Zonen isoliert sind und die eine deutliche Distanz aufweisen. In Bezug auf Notfallereignisse, bei denen das Risiko des Ausfalls mehrerer, voneinander weit entfernter Availability-Zone-Komponenten besteht, sollten Sie Optionen für die Notfallwiederherstellung implementieren. So können Sie Fehler eingrenzen, die sich auf eine ganze Region auswirken. Bei Workloads, für die eine extreme Ausfallsicherheit erforderlich ist (kritische Infrastruktur, gesundheitsbezogene Anwendungen, Infrastruktur von Finanzsystemen usw.) wird möglicherweise eine Multi-Region-Strategie benötigt.
## Implementierungsschritte
1. Analysieren Sie Ihren Workload und bestimmen Sie, ob die Anforderungen an die Ausfallsicherheit mit einem Multi-AZ-Ansatz erfüllt werden (eine AWS-Region) oder ob ein Multi-Region-Ansatz erforderlich ist. Das Implementieren einer Multi-Region-Architektur, um diese Anforderungen zu erfüllen, führt zu einer höheren Komplexität. Betrachten Sie daher Ihren Anwendungsfall und wägen Sie die Anforderungen sorgfältig ab. Die Anforderungen an die Ausfallsicherheit können fast immer auch mit einer AWS-Region erfüllt werden. Berücksichtigen Sie bei der Entscheidung, ob Sie mehrere Regionen verwenden möchten, die folgenden möglichen Anforderungen:
1. **Notfallwiederherstellung (Disaster Recovery, DR)**: Bei einer Unterbrechung oder dem teilweisen Ausfall einer Availability Zone hilft die Implementierung eines hoch verfügbaren Workloads in mehreren Availability Zones innerhalb einer einzelnen AWS-Region, die Folgen von Naturkatastrophen oder technischen Problemen zu begrenzen. In Bezug auf Notfallereignisse, bei denen das Risiko des Ausfalls mehrerer, voneinander weit entfernter Availability Zone-Komponenten besteht, sollten Sie eine Notfallwiederherstellung in mehreren Regionen implementieren. So können Sie die Risiken durch Naturkatastrophen oder technische Fehler eingrenzen, die sich auf eine ganze Region auswirken.
1. **Hohe Verfügbarkeit (High Availability, HA)**: Mit einer Multi-Region-Architektur (mit mehreren AZs in jeder Region) kann eine höhere Verfügbarkeit als „four 9’s“ (> 99,99 %) erreicht werden.
1. **Stack-Lokalisierung**: Beim Bereitstellen eines Workloads für Benutzer weltweit können Sie lokalisierte Stacks in verschiedenen AWS-Regionen bereitstellen, um die Benutzer in diesen Regionen zu versorgen. Die Lokalisierung kann Sprache, Währung und die gespeicherten Datentypen umfassen.
1. **Nähe zu den Benutzern:** Wenn Sie einen Workload für Benutzer weltweit bereitstellen, können Sie die Latenz reduzieren, indem Sie Stacks in AWS-Regionen in der Nähe der Endbenutzer bereitstellen.
1. **Datenresidenz**: Für einige Workloads gelten Anforderungen an die Datenresidenz, d. h. die Daten von bestimmten Nutzern müssen innerhalb der Grenzen eines bestimmten Landes gespeichert werden. Abhängig von der jeweiligen Regelung können Sie einen ganzen Stack oder nur die Daten in der AWS-Region innerhalb dieser Landesgrenzen bereitstellen.
1. Im Folgenden finden Sie einige Bespiele für Multi-AZ-Funktionen, die von AWS-Services bereitgestellt werden:
1. Um Workloads mit EC2 oder ECS zu schützen, stellen Sie einen Elastic Load Balancer vor den Datenverarbeitungsressourcen bereit. Elastic Load Balancing bietet so die Lösung, um Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr zu fehlerfreien Zonen zu leiten.
1. [Erste Schritte mit Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Erste Schritte mit Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. Bei EC2-Instances, auf denen kommerzielle Standardsoftware ohne Unterstützung für Load Balancing ausgeführt wird, können Sie eine gewisse Fehlertoleranz durch die Implementierung einer Methodologie für die Multi-AZ-Notfallwiederherstellung erreichen.
1. [REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)
1. Stellen Sie für Amazon ECS-Aufgaben den Service gleichmäßig auf drei AZs verteilt bereit, um eine ausgeglichene Verteilung von Verfügbarkeit und Kosten zu erreichen.
1. [Bewährte Methoden für die Amazon ECS-Verfügbarkeit \$1 Container](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Wenn Sie nicht mit Aurora Amazon RDS arbeiten, können Sie Multi-AZ als Konfigurationsoption auswählen. Beim Ausfall der primären Datenbank-Instance stuft Amazon RDS automatisch eine Standby-Datenbank hoch, sodass sie Datenverkehr in einer anderen Availability Zone empfangen kann. Außerdem können Multi-Region-Lesereplikate erstellt werden, um die Ausfallsicherheit zu steigern.
1. [Amazon RDS-Multi-AZ-Bereitstellungen](https://aws.amazon.com/rds/features/multi-az/)
1. [Erstellen eines Lesereplikats in einer anderen AWS-Region](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. Im Folgenden finden Sie einige Bespiele für Multi-Region-Funktionen, die von AWS-Services bereitgestellt werden:
1. Für Amazon S3-Workloads, bei denen Multi-AZ-Verfügbarkeit automatisch vom Service bereitgestellt wird, erwägen Sie Multi-Region-Zugriffspunkte, wenn eine Multi-Region-Bereitstellung benötigt wird.
1. [Multi-Region-Zugriffspunkte in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. Wenn bei DynamoDB-Tabellen Multi-AZ-Verfügbarkeit automatisch vom Service bereitgestellt wird, können Sie vorhandene Tabellen problemlos in globale Tabellen konvertieren, um mehrere Regionen nutzen zu können.
1. [Konvertieren von Amazon DynamoDB-Tabellen für eine Region in globale Tabellen](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Wenn Ihr Workload hinter Application Load Balancers oder Network Load Balancers liegt, verwenden Sie AWS Global Accelerator, um die Verfügbarkeit Ihrer Anwendung zu verbessern, indem Sie Datenverkehr zu mehreren Regionen mit fehlerfreien Endpunkten leiten.
1. [Endpunkte für Standard-Accelerators in AWS Global Accelerator – AWS Global Accelerator (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. Erwägen Sie bei Anwendungen, die AWS EventBridge nutzen, die Verwendung von regionsübergreifenden Buses, um Ereignisse an ausgewählte Regionen weiterzuleiten.
1. [Senden und Empfangen von Amazon EventBridge-Ereignissen zwischen AWS-Regionen](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Ziehen Sie bei Amazon Aurora-Datenbanken globale Aurora-Datenbanken in Erwägungen, die mehrere AWS-Regionen umfassen können. Vorhandene Cluster können ebenfalls geändert werden, um neue Regionen hinzuzufügen.
1. [Erste Schritte mit globalen Amazon Aurora-Datenbanken](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Wenn Ihr Workload AWS Key Management Service-Verschlüsselungsschlüssel (AWS KMS) umfasst, überlegen Sie, ob Multi-Region-Schlüssel für Ihre Anwendung geeignet sind.
1. [Multi-Region-Schlüssel in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Weitere Funktionen von AWS-Services finden Sie in dieser Blog-Reihe zum [Erstellen einer Multi-Region-Anwendung mit AWS-Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**Grad des Aufwands für den Implementierungsplan: **Mittel bis hoch
## Ressourcen
**Ähnliche Dokumente:**
+ [Erstellen einer Multi-Region-Anwendung mit AWS-Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Architektur für die Notfallwiederherstellung (Disaster Recovery, DR) 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/)
+ [Globale AWS-Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones – häufig gestellte Fragen](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Architektur für die Notfallwiederherstellung in AWS, Teil I: Strategien für die Wiederherstellung in der Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Die Notfallwiederherstellung in der Cloud unterscheidet sich](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Globale Tabellen: Multiregionale Replikation mit DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: multiregionale Architektur mit hoher Verfügbarkeit, die auf mehr als 1,5 Milliarden Anmeldungen pro Monat mit automatisiertem Failover skaliert werden kann.](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Ähnliche Beispiele:**
+ [Architektur für die Notfallwiederherstellung in AWS, Teil I: Strategien für die Wiederherstellung in der Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC erzielt Resilienz weit über das hinaus, was On-Premises möglich wäre](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group nutzt eine Architektur mit mehreren Regionen und Availability Zones und einem proprietären DNS-Service, um den Anwendungen Resilienz hinzuzufügen.](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: Notfallwiederherstellung für multiregionales Kafka](https://eng.uber.com/kafka/)
+ [Netflix: Aktiv-Aktiv für multiregionale Resilienz](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Entwicklung von Data Residency für Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax wird über zwei Regionen ausgeführt](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Automatisierte Wiederherstellung für Komponenten, die auf einen einzelnen Standort beschränkt sind
Wenn Komponenten des Workloads nur in einer einzelnen Availability Zone oder einem On-Premises-Rechenzentrum ausgeführt werden können, müssen Sie die Funktion implementieren, um eine vollständige Neuerstellung des Workloads innerhalb festgelegter Wiederherstellungsziele durchzuführen.
Wenn die bewährte Methode zur Bereitstellung des Workloads an mehreren Standorten aufgrund technologischer Einschränkungen nicht möglich ist, müssen Sie einen alternativen Pfad zur Ausfallsicherheit implementieren. Sie müssen die Möglichkeit automatisieren, die erforderliche Infrastruktur neu zu erstellen, Anwendungen neu bereitzustellen und die erforderlichen Daten für diese Fälle neu zu erstellen.
Amazon EMR startet beispielsweise alle Knoten für einen bestimmten Cluster in derselben Availability Zone, da die Ausführung eines Clusters in derselben Zone eine höhere Datenzugriffsrate bietet und dadurch eine höhere Leistung für die Aufgabenbearbeitung bereitstellt. Wenn diese Komponente für die Ausfallsicherheit von Workloads erforderlich ist, müssen Sie die Möglichkeit haben, den Cluster und seine Daten erneut bereitzustellen. Für Amazon EMR sollten Sie nicht nur Multi-AZs verwenden, um für Redundanz zu sorgen. Sie können [mehrere Knoten bereitstellen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Mit [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)können Daten in EMR in Amazon S3 gespeichert und dann über mehrere Availability Zones oder AWS-Regionen repliziert werden.
Ähnlich wie bei Amazon Redshift wird Ihr Cluster standardmäßig in einer zufällig ausgewählten Availability Zone innerhalb der ausgewählten AWS-Region bereitgestellt. Alle Cluster-Knoten werden in derselben Zone bereitgestellt.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Implementieren Sie Selbstreparatur. Stellen Sie Ihre Instances oder Container nach Möglichkeit mit automatischer Skalierung bereit. Wenn dies nicht möglich ist, nutzen Sie für EC2-Instances die automatische Wiederherstellung oder implementieren Sie eine automatische Selbstreparatur basierend auf Amazon EC2- oder ECS-Container-Lebenszyklusereignissen.
+ Verwenden Sie Auto-Scaling-Gruppen für Instances und Container-Workloads, die keine IP-Adresse für eine einzelne Instance, keine private IP-Adresse, keine elastische IP-Adresse und keine Instance-Metadaten benötigen.
+ [Was ist EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Automatische Skalierung von Services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ Die Benutzerdaten der Startkonfiguration können für die Automatisierung der Selbstreparatur der meisten Workloads verwendet werden.
+ Verwenden Sie die automatische Wiederherstellung von EC2-Instances für Workloads, die eine IP-Adresse für eine einzelne Instance, eine private IP-Adresse, eine elastische IP-Adresse und Instance-Metadaten benötigen.
+ [Stellen Sie Ihre Instance wieder her.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ Automatic Recovery sendet Benachrichtigungen zum Wiederherstellungsstatus an ein SNS-Thema, wenn der Instance-Fehler erkannt wird.
+ Verwenden Sie EC2-Instance-Lebenszyklusereignisse bzw. ECS-Ereignisse für die Automatisierung der Selbstreparatur, wenn die automatische Skalierung oder EC2-Wiederherstellung nicht verwendet werden kann.
+ [Lebenszyklus-Hooks für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Amazon ECS-Events](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Verwenden Sie die Ereignisse, um die Automatisierung der Reparatur der Komponente entsprechend der erforderlichen Prozesslogik aufzurufen.
## Ressourcen
**Ähnliche Dokumente:**
+ [Amazon ECS-Events](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Lebenszyklus-Hooks für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Stellen Sie Ihre Instance wieder her.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Automatische Skalierung von Services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Was ist EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Verwenden von Bulkhead-Architekturen, um den Umfang von Beeinträchtigungen zu begrenzen
Wie Schotten auf einem Schiff stellt dieses Bulkhead-Muster sicher, dass ein Fehler auf eine kleine Teilmenge von Anfragen oder Clients eingeschränkt bleibt. So wird die Anzahl der beeinträchtigten Anfragen begrenzt und die meisten Anfragen können fehlerfrei ausgeführt werden. Bulkheads für Daten werden häufig als Partitionen bezeichnet, während Bulkheads für Services als Zellen bezeichnet werden.
In einer *zellenbasierten Architektur*ist jede Zelle eine vollständige, unabhängige Instance des Service und hat eine feste maximale Größe. Mit zunehmender Last wachsen die Workloads, indem weitere Zellen hinzugefügt werden. Bei eingehendem Datenverkehr wird mit einem Partitionsschlüssel ermittelt, welche Zelle die Anfrage verarbeitet. Jeder Fehler beschränkt sich auf die Zelle, in der er auftritt, sodass die Anzahl der beeinträchtigten Anfragen begrenzt ist, da andere Zellen weiterhin fehlerfrei funktionieren. Es ist wichtig, den richtigen Partitionsschlüssel zu identifizieren, um zellenübergreifende Interaktionen zu minimieren und zu verhindern, dass bei jeder Anfrage komplexe Zuordnungsservices berücksichtigt werden müssen. Services, die komplexe Zuordnungen erfordern, führen nur zu einer Verlagerung des Problems auf die Zuordnungsservices, während Services, für die zellenübergreifende Interaktionen erforderlich sind, Abhängigkeiten zwischen den Zellen schaffen (und damit die angenommenen Verfügbarkeitsverbesserungen reduzieren).
![\[Diagramm einer zellenbasierten Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Colm MacCarthaigh erläutert in seinem AWS-Blogbeitrag, wie Amazon Route 53 das Konzept des [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) nutzt, um Kundenanfragen in Shards zu isolieren. Ein Shard besteht in diesem Fall aus mindestens zwei Zellen. Auf der Basis des Partitionsschlüssels wird der Datenverkehr von einem Kunden (oder von Ressourcen, je nachdem, was Sie isolieren möchten) an den zugewiesenen Shard weitergeleitet. Bei acht Zellen mit zwei Zellen pro Shard und Kunden, die auf die vier Shards aufgeteilt sind, sind im Falle eines Problems 25 % der Kunden betroffen.
![\[Diagramm eines in herkömmliche Shards aufgeteilten Service\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Mit Shuffle Sharding erstellen Sie virtuelle Shards mit jeweils zwei Zellen und weisen Ihre Kunden einem dieser virtuellen Shards zu. Wenn ein Problem auftritt, können Sie zwar trotzdem ein Viertel des gesamten Service verlieren, aber die Art der Kunden- oder Ressourcenzuweisung sorgt dafür, dass der Umfang der Auswirkungen durch Shuffle Sharding deutlich kleiner ausfällt als 25 %. Bei acht Zellen gibt es 28 eindeutige Kombinationen von zwei Zellen, was bedeutet, dass es 28 mögliche Shuffle Shards (virtuelle Shards) gibt. Wenn Sie Hunderte oder Tausende von Kunden haben und jeden Kunden einem Shuffle Shard zuweisen, beträgt der Umfang der Auswirkungen aufgrund eines Problems nur 1/28. Das ist siebenmal besser als beim regulären Sharding.
![\[Diagramm eines in Shuffle Shards aufgeteilten Service.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Ein Shard kann zusätzlich zu den Zellen für Server, Warteschlangen oder andere Ressourcen verwendet werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Verwenden Sie Bulkhead-Architekturen. Wie Schotten auf einem Schiff stellt dieses Bulkhead-Muster sicher, dass ein Fehler auf eine kleine Teilmenge von Anfragen oder Benutzern eingeschränkt bleibt. So wird die Anzahl der beeinträchtigten Anfragen begrenzt und die meisten Anfragen können fehlerfrei ausgeführt werden. Bulkheads für Daten werden häufig als Partitionen bezeichnet, während Bulkheads für Services als Zellen bezeichnet werden.
+ [Well-Architected Lab: Fehlerisolierung mit Shuffle Sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle Sharding: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: So minimiert AWS den Wirkungsradius von Fehlern (ARC338)](https://youtu.be/swQbA4zub20)
+ Evaluieren Sie eine zellenbasierte Architektur für Ihren Workload. In einer zellenbasierten Architektur ist jede Zelle eine vollständige, unabhängige Instance des Service und hat eine feste maximale Größe. Mit zunehmender Last wachsen die Workloads, indem weitere Zellen hinzugefügt werden. Bei eingehendem Datenverkehr wird mit einem Partitionsschlüssel ermittelt, welche Zelle die Anfrage verarbeitet. Jeder Fehler beschränkt sich auf die Zelle, in der er auftritt, sodass die Anzahl der beeinträchtigten Anfragen begrenzt ist, da andere Zellen weiterhin fehlerfrei funktionieren. Es ist wichtig, den richtigen Partitionsschlüssel zu identifizieren, um zellenübergreifende Interaktionen zu minimieren und zu verhindern, dass bei jeder Anfrage komplexe Zuordnungsservices berücksichtigt werden müssen. Services, die komplexe Zuordnungen erfordern, führen nur zu einer Verlagerung des Problems auf die Zuordnungsservices, während Services, für die zellenübergreifende Interaktionen erforderlich sind, die Autonomie von Zellen (und damit die angenommenen Verfügbarkeitsverbesserungen) reduzieren.
+ Colm MacCarthaigh beschreibt in seinem Beitrag zum AWS-Blog, wie Amazon Route 53 das Konzept des Shuffle Sharding nutzt, um Kundenanfragen in Shards zu isolieren.
+ [Shuffle Sharding: massive und magische Fehlerisolierung](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Ressourcen
**Ähnliche Dokumente:**
+ [Shuffle Sharding: massive und magische Fehlerisolierung](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [Die Amazon Builders' Library: Workload-Isolation mit Shuffle Sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Relevante Videos:**
+ [AWS re:Invent 2018: So minimiert AWS den Wirkungsradius von Fehlern (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle Sharding: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Fehlerisolierung mit Shuffle Sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# ZUV 11 Wie lassen sich Workloads so gestalten, dass sie Komponentenausfälle verkraften?
Workloads, die eine hohe Verfügbarkeit und eine niedrige mittlere Wiederherstellungszeit (Mean Time To Recovery, MTTR) benötigen, müssen auf Resilienz ausgelegt sein.
**Topics**
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover zu fehlerfreien Ressourcen](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatisieren der Reparatur auf allen Ebenen](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler
Überwachen Sie den Zustand Ihrer Workload kontinuierlich, damit Sie und die automatisierten Systeme eine Verschlechterung oder einen Ausfall umgehend bemerken. Überwachen Sie Key Performance Indicators (KPIs, wichtige Leistungskennzahlen) auf Grundlage des geschäftlichen Wertes.
Alle Wiederherstellungs- und Reparaturmechanismen müssen auf eine schnelle Erkennung von Problemen ausgelegt sein. Technische Fehler sollten zuerst erkannt werden, damit sie behoben werden können. Die Verfügbarkeit basiert jedoch auf der Fähigkeit Ihrer Workload, einen Unternehmenswert zu liefern. Daher müssen wichtige Leistungskennzahlen (KPIs), die dies messen, in Ihre Erkennungs- und Behebungsstrategie integriert sein.
**Gängige Antimuster:**
+ Es sind keine Alarme konfiguriert, sodass Ausfälle ohne Benachrichtigung auftreten.
+ Alarme sind vorhanden, aber mit Schwellenwerten, die keine ausreichende Zeit für die Reaktion bieten.
+ Metriken werden nicht häufig genug erfasst, um das Recovery Time Objective (RTO, Wiederherstellungsdauer) zu erreichen.
+ Nur die kundenseitige Ebene der Workload wird aktiv überwacht.
+ Es werden nur technische Metriken erfasst, keine Metriken für Geschäftsfunktionen.
+ Es gibt keine Metriken, die die Benutzererfahrung der Workload messen.
**Vorteile der Einführung dieser bewährten Methode:** Wenn alle Ebenen entsprechend überwacht werden, können Sie die Wiederherstellungszeit durch eine schnellere Fehlererkennung verkürzen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Bestimmen Sie das Erfassungsintervall für die Komponenten auf Grundlage Ihrer Wiederherstellungsziele.
+ Das Überwachungsintervall hängt davon ab, wie schnell Wiederherstellungen durchgeführt werden müssen. Die Wiederherstellungszeit hängt davon ab, wie viel Zeit für eine Wiederherstellung benötigt wird. Daher müssen Sie die Häufigkeit der Erfassung bestimmen, indem Sie diese Zeit und das RTO einkalkulieren.
+ Konfigurieren Sie eine detaillierte Überwachung für die Komponenten.
+ Legen Sie fest, ob eine detaillierte Überwachung für EC2-Instances und Auto Scaling erforderlich ist. Die detaillierte Überwachung stellt Metriken in 1-Minuten-Intervallen bereit; die Standardüberwachung stellt Metriken in 5-Minuten-Intervallen bereit.
+ [Aktivieren oder deaktivieren Sie die detaillierte Überwachung für Ihre Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Überwachen Ihrer Auto-Scaling-Gruppen und Instances mit Amazon CloudWatch.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Legen Sie fest, ob eine erweiterte Überwachung für RDS notwendig ist. Die erweiterte Überwachung verwendet einen Agenten in den RDS-Instances, um nützliche Informationen zu verschiedenen Prozessen oder Threads in einer RDS-Instance abzurufen.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Erstellen Sie benutzerdefinierte Metriken, um Leistungskennzahlen (KPIs) zu messen. Mit Workloads werden wichtige Geschäftsfunktionen implementiert. Diese Funktionen sollten als KPIs verwendet werden, um die Identifizierung indirekter Probleme zu unterstützen.
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Überwachen Sie das Benutzererlebnis auf Fehler mithilfe von Benutzer-Canaries. Synthetische Transaktionstests (auch bekannt als „Canary-Tests“, die aber nicht mit Canary-Bereitstellungen zu verwechseln sind), mit denen das Kundenverhalten simuliert werden kann, gehören zu den wichtigsten Testprozessen. Führen Sie diese Tests für Ihre Workload-Endpunkte konstant von verschiedenen Remote-Standorten aus.
+ [Amazon CloudWatch Synthetics unterstützt Sie bei der Erstellung von Benutzer-Canaries.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Erstellen Sie benutzerdefinierte Metriken zur Nachverfolgung des Benutzererlebnisses. Wenn Sie das Kundenerlebnis instrumentieren können, können Sie die Verschlechterung des Kundenerlebnisses feststellen.
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Richten Sie Alarme ein, um zu erkennen, wenn ein Teil Ihrer Workload nicht ordnungsgemäß funktioniert, und um anzugeben, wann Ressourcen automatisch skaliert werden müssen. Alarme können visuell in Dashboards angezeigt werden, Warnungen per Amazon SNS oder E-Mail senden und mit Auto Scaling die Ressourcen für eine Workload auf- oder abzuskalieren.
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Erstellen Sie Dashboards, um Ihre Metriken zu visualisieren. Dashboards können verwendet werden, um Trends, Ausreißer und andere Indikatoren für potenzielle Probleme zu visualisieren, und auf Probleme hinweisen, die Sie untersuchen sollten.
+ [Verwenden von CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Ressourcen
**Relevante Dokumente:**
+ [Amazon CloudWatch Synthetics unterstützt Sie bei der Erstellung von Benutzer-Canaries.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Aktivieren oder deaktivieren Sie die detaillierte Überwachung für Ihre Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Überwachen Ihrer Auto-Scaling-Gruppen und Instances mit Amazon CloudWatch.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Verwenden von CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover zu fehlerfreien Ressourcen
Stellen Sie sicher, dass fehlerfreie Ressourcen weiterhin Anforderungen erfüllen können, wenn ein Ressourcenausfall auftritt. Stellen Sie bei Standortausfällen (z. B. einer Availability Zone oder AWS-Region) sicher, dass Sie Failover zu fehlerfreien Ressourcen an nicht beeinträchtigten Standorten eingerichtet haben.
AWS-Services wie Elastic Load Balancing und AWS Auto Scaling helfen dabei, Lasten über verschiedene Ressourcen und Availability Zones hinweg zu verteilen. Daher können der Ausfall einer einzelnen Ressource (wie etwa einer EC2-Instance) oder die Beeinträchtigung einer Availability Zone gemindert werden, indem Datenverkehr verlagert wird, um Ressourcen fehlerfrei zu halten. Bei Workloads mit mehreren Regionen ist dies komplizierter. Regionsübergreifende Lesereplikate ermöglichen Ihnen beispielsweise die Bereitstellung Ihrer Daten in mehreren AWS-Regionen. Sie müssen die Lesereplikate jedoch als primär hochstufen und Ihren Datenverkehr bei einem Failover darauf verweisen. Amazon Route 53 und AWS Global Accelerator können dabei helfen, Datenverkehr über AWS-Regionen zu leiten.
Wenn in Ihrer Workload AWS-Services wie Amazon S3 oder Amazon DynamoDB verwendet werden, werden diese automatisch in mehreren Availability Zones bereitgestellt. Bei einem Ausfall leitet die AWS-Steuerebene den Datenverkehr automatisch an fehlerfreie Standorte weiter. Die Daten werden redundant in mehreren Availability Zones gespeichert und bleiben verfügbar. Für Amazon RDS müssen Sie Multi-AZ als Konfigurationsoption auswählen. Bei einem Ausfall leitet AWS den Datenverkehr dann automatisch an die fehlerfreie Instance weiter. Für Amazon EC2-Instances, Amazon ECS-Aufgaben oder Amazon EKS-Pods wählen Sie aus, in welchen Availability Zones die Bereitstellung erfolgen soll. Elastic Load Balancing bietet dann die Lösung, um Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr an die fehlerfreien Zonen weiterzuleiten. Elastic Load Balancing kann den Datenverkehr sogar an Komponenten in Ihrem On-Premises-Rechenzentrum weiterleiten.
Für multiregionale Ansätze (zu denen auch On-Premises-Rechenzentren gehören können) bietet Amazon Route 53 eine Möglichkeit, Internetdomänen zu definieren und Routing-Richtlinien zuzuweisen, die Zustandsprüfungen enthalten können. So wird sichergestellt, dass der Datenverkehr an fehlerfreie Regionen weitergeleitet wird. Alternativ stellt AWS Global Accelerator statische IP-Adressen bereit, die als fester Einstiegspunkt in Ihre Anwendung dienen, und sorgt für eine Weiterleitung an Endpunkte in AWS-Regionen Ihrer Wahl. Dabei wird anstelle des Internets das globale AWS-Netzwerk verwendet, das mehr Leistung und Zuverlässigkeit bietet.
Beim Design der Services berücksichtigt AWS immer die Wiederherstellung nach einem Fehler. Wir konzipieren Services mit dem Ziel, die Wiederherstellungszeit nach Ausfällen und die Auswirkungen auf Daten zu minimieren. Unsere Services verwenden primär Datenspeicher, die Anfragen erst akzeptieren, nachdem sie dauerhaft auf mehreren Replikaten in einer Region gespeichert wurden. Zu diesen Services und Ressourcen gehören Amazon Aurora, Amazon Relational Database Service (Amazon RDS) Multi-AZ-DB-Instances, Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) und Amazon Elastic File System (Amazon EFS). Sie sind so aufgebaut, dass sie eine zellenbasierte Isolation und die Fehlerisolierung von Availability Zones nutzen. In unseren betrieblichen Abläufen setzen wir sehr stark auf Automatisierung. Außerdem optimieren wir unsere Funktionalität für Ersetzungsvorgänge und Neustarts, um nach Unterbrechungen eine schnelle Wiederherstellung zu ermöglichen.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Failover zu fehlerfreien Ressourcen. Stellen Sie sicher, dass fehlerfreie Ressourcen weiterhin Anforderungen erfüllen können, wenn ein Ressourcenausfall auftritt. Stellen Sie bei Standortausfällen (z. B. einer Availability Zone oder AWS-Region) sicher, dass Sie Failover zu fehlerfreien Ressourcen an nicht beeinträchtigten Standorten eingerichtet haben.
+ Wenn in Ihrer Workload AWS-Services wie Amazon S3 oder Amazon DynamoDB verwendet werden, werden diese automatisch in mehreren Availability Zones bereitgestellt. Bei einem Ausfall leitet die AWS-Steuerebene den Datenverkehr automatisch an fehlerfreie Standorte weiter.
+ Für Amazon RDS müssen Sie Multi-AZ als Konfigurationsoption auswählen. Bei einem Ausfall leitet AWS den Datenverkehr dann automatisch an die fehlerfreie Instance weiter.
+ [Hochverfügbarkeit (Multi-AZ) für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Für Amazon EC2-Instances oder Amazon ECS-Aufgaben wählen Sie aus, in welchen Availability Zones die Bereitstellung erfolgen soll. Elastic Load Balancing bietet dann die Lösung, um Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr an die fehlerfreien Zonen weiterzuleiten. Elastic Load Balancing kann den Datenverkehr sogar an Komponenten in Ihrem On-Premise-Rechenzentrum weiterleiten.
+ Bei multiregionalen Ansätzen (die auch On-Premises-Rechenzentren einschließen können) sollten Sie sicherstellen, dass Daten und Ressourcen an fehlerfreien Standorten weiterhin Anforderungen erfüllen können.
+ Regionsübergreifende Lesereplikate ermöglichen Ihnen beispielsweise die Bereitstellung Ihrer Daten in mehreren AWS-Regionen. Sie müssen die Lesereplikate jedoch hochstufen, um den Datenverkehr zu steuern und weiterzuleiten, wenn der primäre Standort ausfüllt.
+ [Arbeiten mit Lesereplikaten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 ermöglicht die Definition von Internetdomänen und die Zuweisung von Routing-Richtlinien, die Zustandsprüfungen enthalten können. So wird sichergestellt, dass der Datenverkehr an fehlerfreie Regionen weitergeleitet wird. Alternativ stellt AWS Global Accelerator statische IP-Adressen bereit, die als fester Einstiegspunkt in Ihre Anwendung dienen, und sorgt für eine Weiterleitung an Endpunkte in AWS-Regionen Ihrer Wahl. Dabei wird anstelle des öffentlichen Internets das globale AWS-Netzwerk verwendet, das mehr Leistung und Zuverlässigkeit bietet.
+ [Amazon Route 53: Auswählen einer Routing-Richtlinie](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Ressourcen
**Relevante Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Automatisierung der Fehlertoleranz unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: Zur Erzielung von Fehlertoleranz geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: Auswählen einer Routing-Richtlinie](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Hochverfügbarkeit (Multi-AZ) für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Arbeiten mit Lesereplikaten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategien für die Platzierung von Aufgaben in Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones (Erstellen von Kubernetes-Auto-Scaling-Gruppen für mehrere Availability Zones)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatisieren der Reparatur auf allen Ebenen
Verwenden Sie bei Erkennung eines Fehlers automatisierte Funktionen, um Maßnahmen zur Behebung durchzuführen.
*Die Möglichkeit zum Neustart* ist ein wichtiges Tool zur Behebung von Fehlern. Wie zuvor für verteilte Systeme beschrieben, besteht eine bewährte Methode darin, Services nach Möglichkeit zustandslos zu machen. Dadurch wird der Verlust von Daten oder Verfügbarkeit beim Neustart verhindert. In der Cloud können (und sollten) Sie die gesamte Ressource (z. B. eine EC2-Instance oder Lambda-Funktion) im Rahmen des Neustarts ersetzen. Der Neustart selbst ist eine einfache und zuverlässige Methode zur Wiederherstellung nach einem Ausfall. Bei Workloads treten viele verschiedene Arten von Fehlern auf. Fehler können sich auf Hardware, Software, Kommunikation und den Betrieb beziehen. Statt neue Mechanismen zu entwickeln, um die verschiedenen Fehlertypen zu erfassen, zu identifizieren und zu korrigieren, sollten Sie viele verschiedene Fehlerkategorien derselben Wiederherstellungsstrategie zuordnen. Instances können aufgrund von Hardware- oder Betriebssystemfehlern, aufgrund von unzureichendem Speicher oder aus anderen Gründen ausfallen. Anstatt eine benutzerdefinierte Fehlerbehebung für jede Situation zu entwickeln, sollten Sie alle Szenarios als Instance-Ausfälle behandeln. Beenden Sie die Instance und lassen Sie sie durch AWS Auto Scaling ersetzen. Die ausgefallene Ressource können Sie genauer untersuchen, nachdem sie außer Betrieb genommen wurde.
Ein weiteres Beispiel ist die Möglichkeit, eine Netzwerkanfrage neu zu starten. Nutzen Sie denselben Wiederherstellungsansatz für eine Netzwerk-Zeitüberschreitung und einen Abhängigkeitsfehler, bei dem die Abhängigkeit einen Fehler ausgibt. Beide Ereignisse wirken sich in ähnlicher Weise auf das System aus. Statt also zu versuchen, aus den einzelnen Ereignissen einen "Sonderfall" zu konstruieren, sollten Sie eine ähnliche Strategie anwenden und versuchen, einen exponentiellen Backoff mit Jitter durchzuführen.
*Die Möglichkeit zum Neustart* ist ein Wiederherstellungsmechanismus, der in Recovery Oriented Computing und Cluster-Architekturen mit hoher Verfügbarkeit verwendet wird.
Mit Amazon EventBridge lassen sich Ereignisse wie CloudWatch-Alarme oder Statusänderungen in anderen AWS-Services überwachen und filtern. Anhand der Ereignisinformationen kann der Service anschließend AWS Lambda, AWS Systems Manager-Automation oder andere Ziele auslösen, um für Ihre Workload eine benutzerdefinierte Korrekturlogik auszuführen.
Amazon EC2 Auto Scaling kann dafür konfiguriert werden, den Zustand der EC2-Instance zu prüfen. Wenn sich die Instance nicht im ausgeführten Status befindet oder der Systemstatus beeinträchtigt ist, betrachtet Amazon EC2 Auto Scaling die Instance als fehlerhaft und startet eine Ersatz-Instance. Wenn Sie AWS OpsWorks verwenden, können Sie Auto Healing für EC2-Instances auf der OpsWorks-Layer-Ebene konfigurieren.
Für umfangreiche Ersetzungen (z. B. beim Verlust einer gesamten Availability Zone) ist statische Stabilität die bevorzugte Methode, um für hohe Verfügbarkeit zu sorgen, statt mehrere neue Ressourcen gleichzeitig abzurufen.
**Gängige Antimuster:**
+ Einzelne Bereitstellung von Anwendungen in Instances oder Containern.
+ Bereitstellen von Anwendungen, die nicht ohne automatische Wiederherstellung an mehreren Standorten bereitgestellt werden können.
+ Manuelle Reparatur von Anwendungen, die sich mit Auto Scaling und einer automatischen Wiederherstellung nicht reparieren lassen.
**Vorteile der Einführung dieser bewährten Methode:** Selbst wenn die Workload jeweils nur an einem Standort bereitgestellt werden kann, verkürzt die automatisierte Reparatur die durchschnittliche Zeit bis zur Wiederherstellung und stellt die Verfügbarkeit der Workload sicher.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Stellen Sie die Ebenen in einer Workload mithilfe von Auto-Scaling-Gruppen bereit. Die automatische Skalierung kann Selbstreparaturen für zustandslose Anwendungen ausführen sowie Kapazitäten hinzufügen oder entfernen.
+ [Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementieren Sie eine automatische Wiederherstellung für EC2-Instances, in denen Anwendungen bereitgestellt werden, die nicht an mehreren Standorten bereitgestellt werden können, und die einen Neustart nach Ausfällen tolerieren. Mithilfe der automatischen Wiederherstellung kann ausgefallene Hardware ersetzt und die Instance neu gestartet werden, wenn die Anwendung sich nicht an mehreren Standorten bereitstellen lässt. Die Metadaten der Instance und die zugehörigen IP-Adressen werden beibehalten, ebenso wie die Amazon EBS-Volumes und Bindungspunkte für Elastic File Systems oder Dateisysteme für Lustre und Windows.
+ [Automatische Wiederherstellung in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Was ist Amazon FSx für Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Was ist Amazon FSx für Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Wenn Sie AWS OpsWorks verwenden, können Sie Auto Healing für EC2-Instances auf Layer-Ebene konfigurieren.
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementieren Sie die automatisierte Wiederherstellung mit AWS Step Functions und AWS Lambda, wenn keine automatische Skalierung oder Wiederherstellung möglich ist oder die automatische Wiederherstellung fehlschlägt. Wenn Sie keine automatische Skalierung verwenden können und die automatische Wiederherstellung entweder nicht genutzt werden kann oder fehlschlägt, können Sie die Reparatur mithilfe von AWS Step Functions und AWS Lambda automatisieren.
+ [Was ist AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Mit Amazon EventBridge lassen sich Ereignisse wie CloudWatch-Alarme oder Statusänderungen in anderen AWS-Services überwachen und filtern. Anhand der Ereignisinformationen kann der Service anschließend AWS Lambda (oder andere Ziele) auslösen, um eine benutzerdefinierte Korrekturlogik für die Workload auszuführen.
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressourcen
**Relevante Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Automatisierung der Fehlertoleranz unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: Zur Erzielung von Fehlertoleranz geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Automatische Wiederherstellung in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Was ist AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Was ist Amazon FSx für Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Was ist Amazon FSx für Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Relevante Videos:**
+ [Statische Stabilität in AWS: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung
Die Steuerebene wird für die Konfigurierung von Ressourcen verwendet. Die Datenebene stellt Services bereit. Datenebenen besitzen in der Regel höhere Ziele in Bezug auf das Verfügbarkeitsdesign als Steuerebenen und sind in der Regel weniger komplex. Bei der Implementierung von Wiederherstellungs- oder Eingrenzungsantworten auf Ereignisse, die sich potenziell auf die Resilienz auswirken könnten, kann durch die Verwendung von Operationen auf Steuerebene die Gesamtresilienz Ihrer Architektur reduziert werden. Sie können beispielsweise die Amazon Route 53-Datenebene nutzen, um DNS-Abfragen auf der Basis von Zustandsprüfungen zuverlässig weiterzuleiten. Da bei der Aktualisierung von Route 53-Routing-Richtlinien jedoch die Steuerebene verwendet wird, sollten Sie diese nicht für Wiederherstellungen verwenden.
Die Route 53-Datenebenen beantworten DNS-Abfragen, führen Zustandsprüfungen durch und bewerten diese. Sie werden global für ein [100%-iges Service Level Agreement (SLA) verteilt und entworfen.](https://aws.amazon.com/route53/sla/) Die Route 53-Management-APIs und -Konsolen, in denen Sie Route 53-Ressourcen erstellen, aktualisieren und löschen können, werden auf Steuerebenen ausgeführt. Diese Ebenen sind darauf ausgelegt, die starke Konsistenz und Stabilität zu priorisieren, die Sie bei der Verwaltung von DNS benötigen. Zu diesem Zweck befinden sich die Steuerebenen in einer einzelnen Region, US East (N. Virginia). Beide Systeme sind zwar äußerst zuverlässig, aber die Steuerebenen sind nicht in der SLA enthalten. In seltenen Fällen kann es vorkommen, dass das ausfallsichere Design der Datenebene es ermöglicht, die Verfügbarkeit aufrechtzuerhalten, während die Steuerebene dies nicht tut. Verwenden Sie für die Notfallwiederherstellung und Failover-Mechanismen Datenebenen-Funktionen, um die bestmögliche Zuverlässigkeit bereitzustellen.
Weitere Informationen über Datenebenen, Steuerebenen und wie AWS Services aufbaut, um Hochverfügbarkeitsziele zu erfüllen, finden Sie im Dokument [Statische Stabilität mithilfe von Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) und in der [Amazon Builders’ Library.](https://aws.amazon.com/builders-library/)
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Nutzen Sie die Datenebene statt der Steuerebene, wenn Sie Amazon Route 53 für die Notfallwiederherstellung verwenden. Route 53 Application Recovery Controller hilft Ihnen, anhand von Bereitschaftsprüfungen und Routing-Steuerung Failover-Vorgänge zu verwalten und zu koordinieren. Diese Funktionen überwachen kontinuierlich die Fähigkeit Ihrer Anwendung, nach Fehlern wiederhergestellt zu werden, und ermöglichen Ihnen die Steuerung der Anwendungswiederherstellung über mehrere AWS-Regionen, Availability Zones und On-Premises.
+ [Was ist Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Erstellen von Mechanismen für die Notfallwiederherstellung mit Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 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/)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 2: Stack für eine mehrere Regionen](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Erfahren Sie, welche Operationen auf der Datenebene und welche Operationen auf der Steuerebene ausgeführt werden.
+ [Amazon Builders' Library: Vermeiden von Überlastungen verteilter Systeme durch Übernahme der Steuerung durch den kleineren Service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API (Steuerebene und Datenebene)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda-Ausführungen](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (in Steuerebene und Datenebene unterteilt)
+ [AWS Lambda-Ausführungen](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (in Steuerebene und Datenebene unterteilt)
## Ressourcen
**Relevante Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Automatisierung der Fehlertoleranz unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: Zur Erzielung von Fehlertoleranz geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: Vermeiden von Überlastungen verteilter Systeme durch Übernahme der Steuerung durch den kleineren Service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API (Steuerebene und Datenebene)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda-Ausführungen](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (in Steuerebene und Datenebene unterteilt)
+ [AWS-Elemental-MediaStore-Datenebene](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 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/)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 2: Stack für eine mehrere Regionen](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Erstellen von Mechanismen für die Notfallwiederherstellung mit Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Was ist Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Ähnliche Beispiele:**
+ [What is Amazon Route 53 Application Recovery Controller? (Was ist Amazon Route 53 Application Recovery Controller?)](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität
Bimodales Verhalten bedeutet, dass eine Workload im normalen Modus und im Fehlermodus unterschiedliche Verhaltensweisen zeigt, indem sie z. B. bei Ausfall einer Availability Zone neue Instances startet. Stattdessen sollten Sie Workloads erstellen, die statisch stabil sind und nur in einem Modus betrieben werden. In diesem Fall sollten Sie genügend Instances in jeder Availability Zone bereitstellen, damit die Verarbeitung der Workload auch beim Entfernen einer Availability Zone gewährleistet ist. Anschließend sollten Sie die beeinträchtigten Instances mithilfe von Elastic Load Balancing oder Amazon Route 53-Zustandsprüfungen entlasten.
Statische Stabilität für die Bereitstellung von Rechenleistung (z. B. EC2-Instances oder -Container) führt zu höchster Zuverlässigkeit. Dabei müssen Sie das Kosten-Nutzen-Verhältnis abwägen. Es ist kostengünstiger, weniger Rechenkapazität bereitzustellen und sich bei einem Ausfall auf das Starten neuer Instances zu verlassen. Bei großen Ausfällen (z. B. einem Ausfall einer Availability Zone) ist dieser Ansatz jedoch weniger effektiv, da er sich darauf stützt, auf bereits eingetretene Beeinträchtigungen zu reagieren, statt auf diese Beeinträchtigungen vorbereitet zu sein, bevor sie auftreten. Ihre Lösung sollte die Zuverlässigkeits- und Kostenanforderungen für Ihre Workload berücksichtigen. Wenn Sie eine größere Anzahl von Availability Zones verwenden, verringert sich die Menge der zusätzlichen Rechenleistung, die Sie für die statische Stabilität benötigen.
![\[Diagramm: Statische Stabilität von EC2-Instances in Availability Zones\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/static-stability.png)
Nachdem der Datenverkehr verlagert wurde, können Sie AWS Auto Scaling verwenden, um Instances in der ausgefallenen Zone asynchron zu ersetzen und sie in den fehlerfreien Zonen zu starten.
Ein weiteres Beispiel für bimodales Verhalten ist eine Netzwerk-Zeitüberschreitung, die dazu führen kann, dass ein System versucht, den Konfigurationsstatus des gesamten Systems zu aktualisieren. Dies kann zu einer unerwarteten Belastung einer anderen Komponente führen, die daraufhin ausfallen könnte und möglicherweise weitere unerwartete Konsequenzen nach sich zieht. Diese negative Feedback-Schleife wirkt sich auf die Verfügbarkeit Ihrer Workload aus. Deshalb sollten Sie Systeme erstellen, die statisch stabil sind und nur in einem Modus betrieben werden. Ein statisch stabiles Design besteht aus konstanter Arbeit und einer regelmäßigen Aktualisierung des Konfigurationsstatus. Wenn ein Aufruf fehlschlägt, verwendet die Workload den zuvor zwischengespeicherten Wert und löst einen Alarm aus.
Ein weiteres Beispiel für bimodales Verhalten: Sie lassen zu, dass Clients im Fehlerfall den Workload-Cache umgehen. Dies scheint eine Lösung zu sein, die Clientanforderungen erfüllt, sollte aber nicht zugelassen werden, da sie die Belastung Ihrer Workload erheblich ändert und wahrscheinlich zu Fehlern führt.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Nutzen Sie statische Stabilität, um bimodales Verhalten zu verhindern. Bimodales Verhalten bedeutet, dass eine Workload im normalen Modus und im Fehlermodus unterschiedliche Verhaltensweisen zeigt, indem sie z. B. bei Ausfall einer Availability Zone neue Instances startet.
+ [Minimierung der Abhängigkeiten bei der Planung der Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Die Amazon Builders' Library: Statische Stabilität durch Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Statische Stabilität in AWS: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Sie sollten stattdessen Systeme erstellen, die statisch stabil sind und nur in einem einzigen Modus ausgeführt werden. In diesem Fall sollten Sie genügend Instances in jeder Zone bereitstellen, damit die Verarbeitung der Workload auch beim Entfernen einer AZ gewährleistet ist, und verwenden Sie anschließend Elastic Load Balancing oder Amazon Route 53-Zustandsprüfungen, um die Last von den beeinträchtigten Instances wegzuverlagern.
+ Ein weiteres Beispiel für bimodales Verhalten: Sie lassen zu, dass Clients im Fehlerfall den Workload-Cache umgehen. Dies mag zwar wie eine praktikable Lösung zur Erfüllung der Clientanforderungen aussehen, sollte aber vermieden werden, da sie die Ansprüche an die Workload erheblich verändert und wahrscheinlich zu Fehlern führt.
## Ressourcen
**Relevante Dokumente:**
+ [Minimierung der Abhängigkeiten bei der Planung der Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Die Amazon Builders' Library: Statische Stabilität durch Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Relevante Videos:**
+ [Statische Stabilität in AWS: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken
Benachrichtigungen werden nach Erkennung wichtiger Ereignisse gesendet, auch wenn das durch das Ereignis verursachte Problem automatisch behoben wurde.
Auto Healing sorgt dafür, dass Ihre Workload zuverlässig ist. Allerdings können dadurch auch zugrunde liegende Probleme verschleiert werden, die behoben werden müssen. Implementieren Sie geeignete Überwachungsfunktionen und Ereignisse, damit Sie Problemmuster erkennen können, einschließlich solcher, die durch Auto Healing behoben werden. Auf diese Weise können Sie die Fehlerursachen beheben. Amazon CloudWatch-Alarme können basierend auf auftretenden Fehlern ausgelöst werden. Sie können auch basierend auf Aktionen der automatischen Fehlerbehebung ausgelöst werden. CloudWatch-Alarme können so konfiguriert werden, dass E-Mails gesendet oder Vorfälle mithilfe der Amazon SNS-Integration in Drittanbietersystemen zur Nachverfolgung von Vorfällen protokolliert werden.
**Gängige Antimuster:**
+ Senden von Alarmen, auf die niemand reagiert.
+ Durchführen automatischer Reparaturen ohne die Benachrichtigung, dass eine Reparatur erforderlich war.
**Vorteile der Einführung dieser bewährten Methode:** Benachrichtigungen zu Wiederherstellungen sorgen dafür, dass Sie selten auftretende Probleme nicht ignorieren.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Alarme für wichtige geschäftliche Leistungskennzahlen, wenn diese eine niedrige Schwelle überschreiten. Wenn Sie eine niedrige Alarmschwelle für Ihre geschäftlichen KPIs ansetzen, können Sie besser erkennen, wann Ihre Workload nicht verfügbar ist oder nicht funktioniert.
+ [Erstellen eines CloudWatch-Alarms auf der Basis eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarme für Ereignisse, die eine automatisierte Reparatur auslösen. Sie können eine SNS-API direkt aufrufen, um bei von Ihnen erstellten Automatisierungen Benachrichtigungen zu senden.
+ [Was ist Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Ressourcen
**Relevante Dokumente:**
+ [Erstellen eines CloudWatch-Alarms auf der Basis eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# ZUV 12 Wie lässt sich die Zuverlässigkeit testen?
Nachdem Sie Ihre Workload so konzipiert haben, dass sie den Belastungen der Produktion standhält, sind Tests die einzige Möglichkeit, sie auf die erwartete Funktionalität und Ausfallsicherheit hin zu testen.
**Topics**
+ [REL12-BP01 Untersuchen von Fehlern mit Playbooks:](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Durchführen von Analysen nach Vorfällen](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Testen funktionaler Anforderungen](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Testen von Skalierungs- und Leistungsanforderungen](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Testen der Ausfallsicherheit mit Chaos-Engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Regelmäßiges Abhalten von Gamedays](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Untersuchen von Fehlern mit Playbooks:
Ermöglichen Sie konsistente und schnelle Antworten auf noch unbekannte Fehlerszenarien, indem Sie den Untersuchungsprozess in Playbooks dokumentieren. Playbooks sind vordefinierte Abläufe zum Identifizieren der Faktoren, die zu einem Fehlerszenario beitragen. Die Ergebnisse aus jedem Prozessschritt sind die Grundlage für die nächsten Schritte. Nach diesem Muster wird vorgegangen, bis das Problem identifiziert oder eskaliert wird.
Das Playbook ist eine proaktive Planung, die für effektive Reaktionen erforderlich ist. Wenn nicht vom Playbook abgedeckte Fehlerszenarien in der Produktion auftreten, beheben Sie zunächst das Problem. Analysieren Sie danach die unternommenen Schritte und verwenden Sie diese, um einen neuen Eintrag im Playbook hinzuzufügen.
Beachten Sie, dass Playbooks als Reaktion auf bestimmte Vorfälle verwendet werden, während Runbooks verwendet werden, um bestimmte Ergebnisse zu erzielen. Häufig werden Runbooks für Routineaktivitäten verwendet, Playbooks hingegen, um auf außergewöhnliche Ereignisse zu reagieren.
**Gängige Antimuster:**
+ Planen der Bereitstellung eines Workloads, ohne die Prozesse für die Diagnose von Problemen oder die Reaktion auf Vorfälle zu kennen.
+ Ungeplante Entscheidungen darüber, in welchen Systemen bei der Untersuchung von Ereignissen Protokolle und Metriken erfasst werden sollen.
+ Metriken und Ereignisse werden nicht lange genug aufbewahrt, um die Daten abrufen zu können.
**Vorteile der Einführung dieser bewährten Methode:** Durch das Erfassen von Playbooks wird sichergestellt, dass Prozesse konsistent befolgt werden können. Ihre Playbooks werden als Code festgehalten, um die Entstehung von Fehlern durch manuelle Aktivitäten zu reduzieren. Durch die Automatisierung von Playbooks kann schneller auf Ereignisse reagiert werden, weil Teammitglieder nicht eingreifen müssen oder ihnen vor dem Eingreifen zusätzliche Informationen zur Verfügung gestellt werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Ermitteln von Probleme mit Playbooks. Playbooks sind dokumentierte Prozesse für die Untersuchung von Problemen. Durch die Dokumentation der Prozesse in Playbooks schaffen Sie die Voraussetzung für eine einheitliche und schnelle Reaktion auf Fehlerszenarien. Playbooks müssen die Informationen und Anleitungen enthalten, die eine entsprechend qualifizierte Person zum Zusammentragen sachdienlicher Informationen, zum Identifizieren möglicher Fehlerursachen, zum Isolieren von Fehlern und zum Bestimmen beitragender Faktoren (zum Analysieren nach einem Vorfall) benötigt.
+ Implementieren von Playbooks als Code. Führen Sie Ihre Operationen als Code aus, indem Sie Skripts für Ihre Playbooks erstellen, um Konsistenz sicherzustellen und Fehler zu reduzieren, die durch manuelle Prozesse verursacht werden. Playbooks können aus mehreren Skripts bestehen, die die verschiedenen Schritte darstellen, die erforderlich sein können, um die zu einem Problem beitragenden Faktoren zu identifizieren. Runbook-Aktivitäten können ausgelöst oder im Rahmen von Playbook-Aktivitäten ausgeführt werden. Sie können auch als Antwort auf identifizierte Ereignisse die Ausführung eines Playbooks auslösen.
+ [Automatisieren Sie Ihre operativen Playbooks mit AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Befehl ausführen](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Verwenden von Amazon CloudWatch Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressourcen
**Zugehörige Dokumente:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Befehl ausführen](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automatisieren Sie Ihre operativen Playbooks mit AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Verwenden von Amazon CloudWatch Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Verwenden von Canaries (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Ähnliche Beispiele:**
+ [Automatisieren von Vorgängen mit Playbooks und Runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Durchführen von Analysen nach Vorfällen
Überprüfen Sie die Ereignisse mit Auswirkungen auf Kunden und bestimmen Sie die beitragenden Faktoren und Präventivmaßnahmen. Entwickeln Sie anhand dieser Informationen Abhilfemaßnahmen, um ein wiederholtes Auftreten nach Möglichkeit zu verhindern. Entwickeln Sie Verfahren für schnelle und effektive Reaktionen. Informieren Sie nach Bedarf auf zielgruppengerechte Weise über beitragende Faktoren und Korrekturmaßnahmen. Legen Sie eine Kommunikationsmethode fest, um andere bei Bedarf über die Ursachen zu informieren.
Bewerten Sie, warum bestehende Tests das Problem nicht gefunden haben. Fügen Sie Tests für diesen Fall hinzu, wenn noch keine Tests vorhanden sind.
**Gängige Antimuster:**
+ Beitragende Faktoren werden ermittelt, es wird jedoch nicht weiter nach anderen potenziellen Problemen und Lösungsansätzen gesucht.
+ Es werden nur menschliche Fehlerursachen ermittelt, es wird aber keine Schulung oder Automatisierung bereitgestellt, die menschliche Fehler verhindern könnte.
**Vorteile der Einführung dieser bewährten Methode:** Durch Analysen von Vorfällen und das Teilen von Ergebnissen können die Risiken für andere Workloads mit den gleichen beitragenden Faktoren die Risiken verringert werden. Außerdem können Abhilfemaßnahmen oder automatisierte Wiederherstellungen implementiert werden, bevor es zu einem Vorfall kommt.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Festlegen eines Standards für Analysen nach Vorfällen. Durch gute Analysen nach Vorfällen lassen sich allgemeine Lösungen für Probleme mit Architekturmustern ermitteln, die Sie bereits an anderer Stelle in den Systemen anwenden.
+ Sorgen Sie dafür, dass die beitragenden Faktoren auf ehrliche Weise und ohne Schuldzuweisungen aufgeführt werden.
+ Wenn Sie Probleme nicht dokumentieren, können Sie sie auch nicht korrigieren.
+ Verzichten Sie bei Analysen nach Vorfällen auf Schuldzuweisungen, damit Sie die Korrekturmaßnahmen unparteiisch vorschlagen können. Fördern Sie zudem in Ihren Anwendungsteams eine ehrliche Selbstbewertung und Zusammenarbeit.
+ Verwenden eines Prozesses zur Ermittlung beitragender Faktoren. Erarbeiten Sie ein Verfahren, um die beitragenden Faktoren eines Ereignisses zu ermitteln und zu dokumentieren. Damit können Sie Abhilfemaßnahmen entwickeln, um ein erneutes Auftreten einzudämmen oder gänzlich zu verhindern, und Verfahren für eine rasche und wirksame Reaktion erstellen. Kommunizieren Sie beitragende Faktoren wie zutreffend, jeweils auf die Zielgruppen ausgerichtet.
+ [Was ist Protokollanalytik?](https://aws.amazon.com/log-analytics/)
## Ressourcen
**Zugehörige Dokumente:**
+ [Was ist Protokollanalytik?](https://aws.amazon.com/log-analytics/)
+ [Darum sollten Sie eine Fehlerkorrektur (COE) entwickeln](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Testen funktionaler Anforderungen
Verwenden Sie Techniken wie Komponenten- und Integrationstests, mit denen die erforderliche Funktionalität validiert wird.
Im Idealfall sollten diese Tests automatisch als Teil von Build- und Bereitstellungsaktionen ausgeführt werden. Mit AWS CodePipeline übergeben Entwickler beispielsweise Änderungen an ein Quell-Repository, in dem CodePipeline die Änderungen automatisch erkennt. Diese Änderungen werden vorgenommen und Tests werden ausgeführt. Nachdem die Tests abgeschlossen sind, wird der erstellte Code für Tests auf Staging-Servern bereitgestellt. Auf dem Staging-Server führt CodePipeline weitere Tests aus, z. B. Integrations- oder Belastungstests. Nach dem erfolgreichen Abschluss dieser Tests stellt CodePipeline den getesteten und genehmigten Code für Produktions-Instances bereit.
Außerdem zeigen frühere Erfahrungen, dass synthetische Transaktionstests (auch bekannt als *Canary-Tests*, aber nicht zu verwechseln mit Canary-Bereitstellungen), die ausgeführt werden können und das Kundenverhalten simulieren, zu den wichtigsten Testprozessen gehören. Führen Sie diese Tests für Ihre Workload-Endpunkte konstant von verschiedenen Remote-Standorten aus. Mit Amazon CloudWatch Synthetics können Sie [Canaries erstellen,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) um Ihre Endpunkte und APIs zu überwachen.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Testen funktionaler Anforderungen: Dazu gehören Komponenten- und Integrationstests, mit denen die erforderliche Funktionalität validiert wird.
+ [Verwenden von AWS CodeBuild mit CodePipeline zum Testen von Code und zum Ausführen von Builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline fügt Unterstützung für Komponententests und angepasste Integrationstests mit AWS CodeBuild hinzu)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Kontinuierliche Bereitstellung und kontinuierliche Integration](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Using synthetic monitoring (Amazon CloudWatch Synthetics) (Verwenden von synthetischer Überwachung (Amazon CloudWatch Synthetics))](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Automatisierung von Softwaretests](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Implementierung einer Continuous Integration-Pipeline unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline fügt Unterstützung für Komponententests und angepasste Integrationstests mit AWS CodeBuild hinzu)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: Für die kontinuierliche Integration geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Kontinuierliche Bereitstellung und kontinuierliche Integration](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Automatisierung von Softwaretests](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Verwenden von AWS CodeBuild mit CodePipeline zum Testen von Code und zum Ausführen von Builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Using synthetic monitoring (Amazon CloudWatch Synthetics) (Verwenden von synthetischer Überwachung (Amazon CloudWatch Synthetics))](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Testen von Skalierungs- und Leistungsanforderungen
Verwenden Sie Techniken wie Lasttests, um zu überprüfen, ob die Workload die Skalierungs- und Leistungsanforderungen erfüllt.
In der Cloud können Sie bei Bedarf eine Testumgebung für Ihren Workload in Produktionsumgebungen erstellen. Wenn Sie diese Tests auf einer herunterskalierten Infrastruktur ausführen, müssen Sie die Ergebnisse auf den Maßstab der Produktionsumgebung hochrechnen. Last- und Leistungstests können auch in der Produktion durchgeführt werden. Achten Sie dabei darauf, Benutzer nicht zu beeinträchtigen und Ihre Testdaten mit Tags zu versehen, sodass sie nicht mit Benutzerdaten vermischt werden und Nutzungsstatistiken oder Produktionsberichte verfälschen.
Stellen Sie mit Tests sicher, dass Ihre Basisressourcen, Skalierungseinstellungen, Servicekontingente und die Ausfallsicherheit unter Auslastung wie erwartet funktionieren.
**Risikostufe, wenn diese Best Practice nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Testen Sie Skalierungs- und Leistungsanforderungen. Führen Sie Lasttests durch, um zu prüfen, ob der Workload die Skalierungs- und Leistungsanforderungen erfüllt.
+ [Verteilte Lasttests auf AWS: Simulation Tausender verbundener Benutzer](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Stellen Sie Ihre Anwendung in einer Umgebung bereit, die mit Ihrer Produktionsumgebung identisch ist, und führen Sie einen Lasttest durch.
+ Erstellen Sie auf Grundlage von "Infrastructure as Code"-Konzepten eine Umgebung, die Ihrer Produktionsumgebung möglichst ähnlich ist.
## Ressourcen
**Zugehörige Dokumente:**
+ [Verteilte Lasttests auf AWS: Simulation Tausender verbundener Benutzer](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Testen der Ausfallsicherheit mit Chaos-Engineering
Führen Sie regelmäßig Chaos-Experimente in oder nahe an Produktionsumgebungen aus, um zu verstehen, wie Ihr System auf ungünstige Bedingungen reagiert.
** Gewünschtes Ergebnis: **
Die Ausfallsicherheit der Workload wird regelmäßig durch die Anwendung von Chaos-Engineering in Form von Fehlerinjektionsexperimenten oder einer Injektion unerwarteter Last überprüft. Dazu kommen Tests der Ausfallsicherheit, um das bekannte erwartete Verhalten der Workload während eines Ereignisses zu validieren. Kombinieren Sie Chaos-Engineering mit Tests der Ausfallsicherheit, um sicher zu sein, dass Ihre Workload Komponentenausfällen standhalten und sich von unerwarteten Unterbrechungen erholen kann – mit minimalen oder gar keinen Auswirkungen.
** Typische Anti-Muster: **
+ Auslegung der Systeme auf Ausfallsicherheit, aber keine Überprüfung, wie die Workload als Ganzes funktioniert, wenn Fehler auftreten.
+ Keine Experimente unter echten Bedingungen und der erwarteten Last.
+ Keine Behandlung der Experimente als Code und fehlendes Aufrechterhalten während des Entwicklungszyklus.
+ Keine Durchführung von Chaosexperimenten als Teil Ihrer CI/CD-Pipeline und außerhalb von Bereitstellungen.
+ Keine Nutzung früherer Analysen nach Vorfällen bei der Entscheidung über die Fehler, mit denen experimentiert werden soll.
** Vorteile der Nutzung dieser bewährten Methode:** Durch die Injektion von Fehlern zur Überprüfung der Resilienz Ihres Workloads gewinnen Sie die nötige Zuversicht, dass die Wiederherstellungsverfahren Ihres resilienten Entwurfs im Fall eines realen Fehlers funktionieren.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel
## Implementierungsleitfaden
Das Chaos-Engineering bietet Ihren Teams die nötigen Chancen, um auf kontrollierte Weise kontinuierlich reale Störungen (Simulationen) auf Serviceanbieter-, Infrastruktur-, Workload- und Komponentenebene zu injizieren – mit nur minimalen oder gar keinen Auswirkungen auf Ihre Kunden. Ihre Teams können so aus Fehlern lernen und die Resilienz Ihrer Workloads beobachten, messen und verbessern. Darüber hinaus können sie überprüfen, ob Warnungen ausgelöst werden und die Teams über Ereignisse benachrichtigt werden.
Bei kontinuierlicher Ausführung kann das Chaos-Engineering Mängel in Ihren Workloads aufzeigen, die sich negativ auf Verfügbarkeit und Ausführung auswirken könnten, wenn sie nicht behoben werden.
**Anmerkung**
Beim Chaos-Engineering geht es um das Experimentieren mit einem System, um sich davon zu überzeugen, dass das System in der Produktion auch außergewöhnlichen Bedingungen standhalten kann. – [Grundlagen des Chaos-Engineering](https://principlesofchaos.org/)
Wenn ein System diesen Disruptionen standhalten kann, sollte das Chaos-Experiment weiter als automatisierter Regressionstest ausgeführt werden. In dieser Form sollten Chaos-Experimente als Teil Ihres Systementwicklungszyklus (Systems Development Lifecycle, SDLC) und Ihrer CI/CD-Pipeline ausgeführt werden.
Um sicherzustellen, dass Ihr Workload resilient gegenüber dem Ausfall von Komponenten ist, sollten Sie im Rahmen Ihrer Experimente Ereignisse aus der Praxis injizieren. Sie könnten beispielsweise mit dem Verlust von Amazon EC2-Instances oder einem Failover der primären Amazon RDS-Datenbank-Instance experimentieren und so verifizieren, dass Ihr Workload nicht beeinträchtigt wird (oder nur minimal beeinträchtigt wird). Mit einer Kombination von Komponentenfehlern könnten Sie Ereignisse simulieren, die von einer Disruption in einer Availability Zone verursacht werden könnten.
Hinsichtlich Fehlern auf Anwendungsebene (z. B. Abstürzen) könnten Sie mit Stressfaktoren wie Speicher- und CPU-Auslastung beginnen.
Zur Validierung [von Fallback- oder Failover-Mechanismen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) für externe Abhängigkeiten, die bei zeitweisen Netzwerkdisruptionen ausgelöst werden, sollten Ihre Komponenten diese Ereignisse durch das Blockieren des Zugriffs auf externe Anbieter über einen bestimmten Zeitraum simulieren, der von wenigen Sekunden bis zu mehreren Stunden dauern kann.
Andere Degradierungsmodi führen möglicherweise zu einer reduzierten Funktionalität und zu verzögerten Reaktionen, was eine Disruption Ihrer Services verursachen kann. Bekannte Quellen für diese Degradierung sind eine erhöhte Latenz bei kritischen Services und eine unzuverlässige Netzwerkkommunikation (Verlust von Paketen). Experimente mit diesen Fehlern, darunter Netzwerkeffekten wie Latenz, Nachrichtenverlust und DNS-Ausfällen, könnten die fehlende Fähigkeit zur Auflösung eines Namens, zum Erreichen des DNS-Service oder zur Herstellung von Verbindungen zu abhängigen Services umfassen.
**Chaos-Engineering-Tools:**
AWS Fault Injection Service (AWS FIS) ist ein vollständig verwalteter Service für die Injektion von Fehlern, den Sie innerhalb oder außerhalb Ihrer CD-Pipeline verwenden können, um mit diesen Fehlern zu experimentieren. AWS FIS ist eine gute Wahl für Gamedays, die dem Chaos-Engineering gewidmet sind. Der Service unterstützt die gleichzeitige Injektion von Fehlern in verschiedene Arten von Ressourcen, darunter Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) und Amazon RDS. Zu diesen Fehlern gehören die Beendigung von Ressourcen, die Erzwingung von Failovern, die Auslastung von CPU oder Arbeitsspeicher, Drosselung, Latenz und Paketverluste. Da dieser Service in Amazon CloudWatch Alarms integriert ist, können Sie Stoppbedingungen als Integritätsschutz einrichten, um Experimente rückgängig zu machen, wenn sie unerwartete Auswirkungen haben.
![\[Diagramm, das die Integration von AWS Fault Injection Service in AWS-Ressourcen zeigt, um Ihnen die Ausführung von Fehlerinjektionsexperimenten für Ihre Workloads zu ermöglichen.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
Es gibt auch verschiedene Drittanbieteroptionen für Fehlerinjektionsexperimente. Dazu gehören Open-Source-Tools wie [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)und [Litmus Chaos](https://litmuschaos.io/)sowie kommerzielle Optionen wie Gremlin. Zur Erweiterung der Art der Fehler, die in AWS injiziert werden können, kann AWS FIS [in Chaos Mesh und Litmus Chaos integriert werden.](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)So können Sie Fehlerinjektions-Workflows über verschiedene Tools hinweg koordinieren. Sie können beispielsweise einen Stresstest für die CPU eines Pods mit Chaos-Mesh- oder Litmus-Fehlern ausführen und gleichzeitig einen zufällig ausgewählten Prozentsatz von Cluster-Knoten mit AWS FIS-Fehleraktionen beenden.
## Implementierungsschritte
+ Ermitteln Sie die Fehler, mit denen experimentiert werden soll.
Bewerten Sie das Design Ihres Workloads in Bezug auf die Resilienz. Diese Designs (anhand der Best Practices des [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)erstellt) berücksichtigen Risiken im Zusammenhang mit kritischen Abhängigkeiten, früheren Ereignissen, bekannten Problemen und Compliance-Anforderungen. Listen Sie die einzelnen Elemente des Designs auf, die Resilienz zeigen sollen, und die Fehler, denen es standhalten soll. Weitere Informationen zur Erstellung dieser Listen finden Sie im [Whitepaper zur Überprüfung der betrieblichen Bereitschaft.](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) Dieses Whitepaper führt Sie durch die Entwicklung eines Prozesses zur Verhinderung der Wiederholung früherer Vorfälle. Der Prozess für die Analyse von Fehlerarten und ihren Auswirkungen (Failure Modes and Effects Analysis, FMEA) stellt Ihnen ein Framework für Fehleranalysen auf Komponentenebene und die Analyse der Auswirkungen dieser Fehler auf Ihren Workload bereit. FMEA wird von Adrian Cockcroft in [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5)(Fehlerarten und kontinuierliche Resilienz) detaillierter beschrieben.
+ Weisen Sie jedem Fehler eine Priorität zu.
Beginnen Sie mit einer groben Kategorisierung wie hoch, mittel oder niedrig. Berücksichtigen Sie bei der Festlegung der Priorität die Häufigkeit des Fehlers und die Auswirkungen des Fehlers auf den Workload insgesamt.
Analysieren Sie hinsichtlich der Häufigkeit eines bestimmten Fehlers frühere Daten für den betreffenden Workload, wenn verfügbar. Wenn keine Daten verfügbar sind, verwenden Sie Daten zu anderen Workloads, die in einer ähnlichen Umgebung ausgeführt werden.
Bei der Betrachtung der Auswirkungen eines bestimmten Fehlers gilt, dass die Auswirkungen im Allgemeinen umso größer sind, je größer der vom Fehler betroffene Bereich ist. Sie sollten auch das Design und den Zweck des Workloads berücksichtigen. Beispielsweise ist für einen Workload, der Daten transformiert und analysiert, der Zugriff auf die Quelldatenspeicher von kritischer Bedeutung. In diesem Fall würden Sie Experimente im Zusammenhang mit Zugriffsfehlern, Zugriffsdrosselungen und Latenzen priorisieren.
Nach Vorfällen durchgeführte Analysen stellen eine gute Datenquelle dar, um Häufigkeit und Auswirkungen von Fehlerarten besser zu verstehen.
Legen Sie anhand der zugewiesenen Priorität die Fehler fest, mit denen zuerst experimentiert werden soll, und die Reihenfolge, in der neue Fehlerinjektionsexperimente entwickelt werden sollen.
+ Für jedes von Ihnen ausgeführte Experiment sollten Sie sich am Schwungrad für Chaos-Engineering und kontinuierliche Resilienz orientieren.
![\[Diagramm des Schwungrads für Chaos-Engineering und kontinuierliche Resilienz, das die Phasen Verbesserung, Steady-State, Hypothese, Experimentausführung und Verifizierung zeigt.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ Definieren Sie den Steady-State als die messbare Ausgabe eines Workloads, der ein normales Verhalten zeigt.
Ihr Workload befindet sich im Steady-State, wenn er zuverlässig und wie erwartet ausgeführt wird. Daher sollten Sie die Integrität Ihres Workloads überprüfen, bevor Sie den Steady-State definieren. Steady-State bedeutet nicht notwendigerweise, dass sich ein Fehler nicht auf den Workload auswirkt, da ein bestimmter Prozentsatz an Fehlern innerhalb akzeptabler Grenzen liegen könnte. Der Steady-State ist die Basislinie, die Sie während des Experiments beobachten. Diese wird Anomalien aufweisen, wenn Ihre Hypothese, die Sie im nächsten Schritt definieren, nicht die erwarteten Ergebnisse zeigt.
Der Steady-State eines Zahlungssystems kann beispielsweise als die Verarbeitung von 300 TPS mit einer Erfolgsrate von 99 % und einer Roundtrip-Zeit von 500 ms definiert sein.
+ Formulieren Sie eine Hypothese dazu, wie der Workload auf den Fehler reagieren wird.
Eine gute Hypothese basiert darauf, wie der Workload den Fehler voraussichtlich bewältigt, um den Steady-State zu wahren. Die Hypothese besagt, dass bei einem Fehler eines spezifischen Typs das System oder der Workload weiter im Steady-State bleiben, da der Workload mit bestimmten Resilienzmerkmalen entworfen wurde. Der spezifische Fehlertyp und die Fehlerbewältigung sollten in der Hypothese angegeben werden.
Sie können für die Hypothese die folgende Vorlage verwenden (andere Formulierungen sind jedoch auch akzeptabel):
**Anmerkung**
Wenn *(spezifischer Fehler)* auftritt, wird der *Workload* (Name des Workloads) *(Maßnahmen zur Bewältigung beschreiben),* um die Auswirkungen auf *geschäftliche oder technische Metriken einzudämmen*.
Beispiel:
+ Wenn 20 % der Knoten in der Amazon EKS-Knotengruppe ausfallen, wird die Transaction Create API das 99. Perzentil der Anforderungen weiter in weniger als 100 ms erfüllen (Steady-State). Die Amazon EKS-Knoten werden innerhalb von fünf Minuten wiederhergestellt und die Pods werden geplant und verarbeiten Traffic innerhalb von acht Minuten nach der Einleitung des Experiments. Warnungen werden innerhalb von drei Minuten ausgelöst.
+ Wenn eine einzelne Amazon EC2-Instance ausfällt, veranlasst die Elastic Load Balancing-Zustandsprüfung des Bestellsystems Elastic Load Balancing, Anforderungen ausschließlich an die noch intakten Instances zu senden, während Amazon EC2 Auto Scaling die ausgefallene Instance ersetzt. Dabei kommt es zu einer Steigerung der serverseitigen Fehler (5xx) um weniger als 0,01 % (Steady-State).
+ Wenn die primäre Amazon RDS-Datenbank-Instance ausfällt, führt der Workload für die Erfassung von Lieferkettendaten einen Failover aus und stellt eine Verbindung zur Amazon RDS-Standby-Datenbank-Instance her, sodass es für weniger als 1 Minute zu Lese- oder Schreibfehlern für die Datenbank kommt (Steady-State).
+ Führen Sie das Experiment aus, indem Sie den Fehler injizieren.
Ein Experiment sollte grundsätzlich nicht zu einem Ausfall führen und vom Workload toleriert werden. Wenn Sie wissen, dass der Workload ausfallen wird, sollten Sie das Experiment nicht durchführen. Das Chaos-Engineering sollte verwendet werden, um bekannt-unbekannte oder unbekannt-unbekannte Ereignisse zu untersuchen. *Bekannt-unbekannte Ereignisse* sind Ereignisse, die Ihnen bekannt sind, die Sie jedoch nicht vollständig verstehen. *Unbekannt-unbekannte Ereignisse* sind Ereignisse, die Sie weder kennen noch vollständig verstehen. Wenn Sie Experimente für einen Workload ausführen, von dem Sie wissen, dass er fehlerhaft ist, werden Sie keine neuen Erkenntnisse gewinnen. Ihr Experiment sollte sorgfältig geplant sein, einen klaren Wirkungsumfang besitzen und einen Rollback-Mechanismus besitzen, der bei unerwarteten Störungen angewendet werden kann. Wenn eine sorgfältige Überprüfung zeigt, dass Ihr Workload das Experiment überstehen sollte, können Sie das Experiment starten. Für die Injektion von Fehlern gibt es verschiedene Optionen. Für AWS-Workloads stellt [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) zahlreiche vordefinierte Fehlersimulationen bereit, die als [Aktionen](https://docs.aws.amazon.com/fis/latest/userguide/actions.html)bezeichnet werden. Sie können auch angepasste Aktionen für AWS FIS definieren, die mithilfe von [AWS Systems Manager-Dokumenten ausgeführt werden](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Wir raten davon ab, angepasste Skripts für Chaos-Experimente zu verwenden, es sei denn, die Skripts können den aktuellen Zustand des Workloads erkennen, können Protokolle ausgeben und stellen Rollback-Mechanismen und Stoppbedingungen bereit, soweit möglich.
Ein effektives Framework oder Toolset, das Chaos-Engineering unterstützt, sollte den aktuellen Status des Experiments nachverfolgen, Protokolle ausgeben und Rollback-Mechanismen bereitstellen, um eine kontrollierte Ausführung zu unterstützen. Beginnen Sie mit einem verbreitet verwendeten Service wie AWS FIS, der Ihnen die Ausführung von Experimenten mit einem klar definierten Umfang ermöglicht und Sicherheitsmechanismen bereitstellt, um ein Experiment rückgängig machen zu können, wenn es zu unerwarteten Störungen führt. Weitere Informationen zu Experimenten unter Verwendung von AWS FIS finden Sie im [Resilient and Well-Architected Apps with Chaos Engineering Lab](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Darüber hinaus analysiert [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) Ihren Workload und erstellt Experimente, die Sie in AWS FIS implementieren und ausführen können.
**Anmerkung**
Sie sollten den Umfang und die Auswirkungen jedes Experiments genau verstehen. Wir empfehlen, Fehler zunächst in einer Nichtproduktionsumgebung zu simulieren, bevor sie in der Produktion ausgeführt werden.
Experimente sollten in der Produktion unter realen Bedingungen ausgeführt werden. Dabei sollten nach Möglichkeit [Canary-Bereitstellungen](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) verwendet werden, die sowohl ein Kontrollsystem als auch ein Experimentsystem bereitstellen. Die Ausführung von Experimenten außerhalb von Spitzenzeiten stellt ein empfehlenswertes Verfahren dar, um potenzielle Auswirkungen zu reduzieren, wenn ein Experiment zum ersten Mal in der Produktion durchgeführt wird. Wenn die Verwendung von tatsächlichem Kunden-Traffic ein zu großes Risiko darstellt, können Sie unter Verwendung der Kontroll- und Experimentbereitstellungen Experimente mit synthetischem Traffic in der Produktionsinfrastruktur durchführen. Wenn ein Experiment nicht in der Produktion ausgeführt werden kann, führen Sie es in einer Präproduktionsumgebung aus, die der Produktionsumgebung so nahe wie möglich ist.
Sie müssen einen Integritätsschutz einrichten und überwachen, um sicherzustellen, dass sich das Experiment nicht jenseits akzeptabler Grenzen auf den Produktions-Traffic oder andere Systeme auswirkt. Richten Sie Stoppbedingungen ein, um ein Experiment anhalten zu können, wenn es in einer Integritätsschutz-Metrik einen von Ihnen definierten Schwellenwert erreicht. Diese Metriken sollten die Metrik für den Steady-State des Workloads und die Metrik für die Komponenten einschließen, in die Sie den Fehler injizieren. Die [synthetische Überwachung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (auch als Benutzer-Canary bezeichnet) gehört zu den Metriken, die Sie in der Regel als Benutzer-Proxy einschließen sollten. [Stoppbedingungen für AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) werden als Teil der Experimentvorlage unterstützt. Es sind bis zu fünf Stoppbedingungen pro Vorlage möglich.
Zu den Grundsätzen des Chaos-Engineering gehört die Minimierung von Umfang und Auswirkungen des Experiments:
Auch wenn einige kurzfristige negative Auswirkungen zulässig sein sollten, ist der Chaos-Engineer dafür verantwortlich, die Auswirkungen der Experimente zu minimieren und einzudämmen.
Eine Methode für die Überprüfung des Umfangs und der möglichen Auswirkungen besteht darin, das Experiment statt in der Produktionsumgebung zunächst in einer Nichtproduktionsumgebung durchzuführen. Dabei wird überprüft, ob die Schwellenwerte für Stoppbedingungen während des Experiments wie vorgesehen aktiviert werden und ob das Experiment beobachtet werden kann, um Ausnahmen abzufangen.
Wenn Sie Fehlerinjektionsexperimente durchführen, müssen alle verantwortlichen Beteiligten gut informiert sein. Teilen Sie den betroffenen Teams mit, wann die Experimente durchgeführt werden und was zu erwarten ist. Dies können Operations-Teams, die für die Servicezuverlässigkeit verantwortlichen Teams und der Kundensupport sein. Stellen Sie diesen Teams Kommunikationstools bereit, damit sie das Team, das das Experiment durchführt, über nachteilige Auswirkungen informieren können.
Sie müssen nach dem Experiment den Workload und die zugrunde liegenden Systeme wieder in den ursprünglichen, gut funktionierenden Zustand zurückversetzen. Häufig führt das resiliente Design des betreffenden Workloads eine Selbstreparatur durch. Einige Fehlerdesigns oder fehlgeschlagenen Experimente können Ihren Workload jedoch in einem nicht erwarteten Fehlerzustand zurücklassen. Nach dem Ende des Experiments müssen Sie dies erkennen und den Workload und die Systeme wiederherstellen können. Mit AWS FIS können Sie eine Rollback-Konfiguration innerhalb der Aktionsparameter einrichten (auch als „Post-Aktion“ bezeichnet). Eine Post-Aktion führt das Ziel in den Zustand zurück, in dem es sich vor Ausführung der Aktion befunden hat. Ob automatisiert (bei Verwendung von AWS FIS) oder manuell – diese Post-Aktionen sollten Teil eines Playbooks sein, das die Erkennung und Behandlung von Fehlern und Ausfällen beschreibt.
+ Prüfen Sie die Hypothese.
[Grundlagen des Chaos-Engineering](https://principlesofchaos.org/) stellt die folgende Anleitung für die Verifizierung des Steady-State Ihres Workloads bereit:
Konzentrieren Sie sich auf die messbare Ausgabe des Systems und nicht auf die internen Attribute des Systems. Messungen dieser Ausgabe über einen kurzen Zeitraum stellen einen Proxy für den Steady-State des Systems dar. Der Gesamtdurchsatz, die Fehlerraten und die Latenz-Perzentile des Systems könnten Metriken sein, die das Steady-State-Verhalten beschreiben. Durch die Konzentration auf die Verhaltensmuster des Systems während Experimenten überprüft das Chaos-Engineering, ob das System funktioniert, statt zu versuchen, die Art der Funktion zu validieren.
In unseren beiden Beispielen oben verwenden wir die Steady-State-Metrik einer Erhöhung von weniger als 0,01 % bei serverseitigen Fehlern (5xx) und von weniger als einer Minute, in der Datenbankschreib- und Lesefehler auftreten.
Die 5xx-Fehler stellen eine gute Metrik dar, da sie die Folge des Fehlermodus sind, dem ein Client des Workloads direkt unterliegen wird. Die Messung der Datenbankfehler ist als direkte Folge des Fehlers gut als Metrik geeignet, sollte jedoch durch eine Messung der Client-Auswirkungen ergänzt werden, beispielsweise in Form von fehlgeschlagenen Kundenanfragen oder Fehlern im Client. Zusätzlich sollten Sie für alle APIs oder URIs, auf die der Client Ihres Workloads direkt zugreift, eine synthetische Überwachung einrichten (auch als Benutzer-Canary bezeichnet).
+ Verbessern Sie das Workload-Design hinsichtlich der Resilienz.
Wenn der Steady-State nicht bewahrt wurde, untersuchen Sie, wie das Workload-Design verbessert werden könnte, um den Fehler zu bewältigen. Wenden Sie dabei die Best Practices der [AWS Well-Architected-Säule „Zuverlässigkeit“ an](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Zusätzliche Anleitungen und Ressourcen finden Sie in der [AWS Builder’s Library.](https://aws.amazon.com/builders-library/)Diese Bibliothek enthält Artikel zur [Verbesserung von Zustandsprüfungen](https://aws.amazon.com/builders-library/implementing-health-checks/) oder [zur Nutzung von Wiederholungen mit Backoff im Anwendungscode](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)und mehr.
Führen Sie das Experiment nach der Implementierung dieser Änderungen erneut durch (angezeigt durch die gepunktete Linie im Flywheel für das Chaos-Engineering), um ihre Effektivität zu ermitteln. Wenn der Verifizierungsschritt zeigt, dass die Hypothese zutrifft, befindet sich der Workload im Steady-State und der Zyklus wird fortgesetzt.
+ Führen Sie regelmäßig Experimente durch.
Ein Chaos-Experiment ist ein Zyklus. Daher sollten Experimente regelmäßig als Teil des Chaos-Engineering durchgeführt werden. Wenn die Hypothese eines Experiments auf einen Workload zutrifft, sollte das Experiment automatisiert werden, um innerhalb Ihrer CI/CD-Pipeline kontinuierlich als Regression ausgeführt zu werden. Informationen hierzu finden Sie in diesem Blog, der die [Ausführung von AWS FIS-Experimenten mit AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)beschreibt. Dieses Lab für wiederholte [AWS FIS-Experimente in einer CI/CD-Pipeline](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) ermöglicht Ihnen de Sammlung praktischer Erfahrungen.
Fehlerinjektionsexperimente sind auch Bestandteil von Gamedays (siehe [REL12-BP06 Regelmäßiges Abhalten von Gamedays](rel_testing_resiliency_game_days_resiliency.md)). Bei Gamedays wird ein Fehler oder Ereignis simuliert, um Systeme, Prozesse und die Reaktionen von Teams zu testen. Dabei sollen die auszuführenden Aktionen vom Team wie im Fall eines außergewöhnlichen Ereignisses tatsächlich ausgeführt werden.
+ Erfassen und speichern Sie die Ergebnisse der Experimente.
Die Ergebnisse von Fehlerinjektionsexperimenten müssen erfasst und gespeichert werden. Erfassen Sie dabei alle notwendigen Daten (wie Zeit, Workload und Bedingungen), um die Ergebnisse und Trends von Experimenten später analysieren zu können. Beispiele für erfasste Ergebnisse können Screenshots von Dashboards, CSV-Versionen der Metrikdatenbank oder manuell eingegebene Aufzeichnungen von Ereignissen und Beobachtungen während des Experiments sein. [Die Protokollierung von Experimenten mit AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) kann Bestandteil dieser Datenerfassung sein.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL08-BP03 Integrieren von Ausfallsicherheitstests in die Bereitstellung](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:](rel_planning_for_recovery_dr_tested.md)
**Zugehörige Dokumente:**
+ [Was ist AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [Was ist AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Grundlagen des Chaos-Engineering](https://principlesofchaos.org/)
+ [Chaos-Engineering: Planung Ihres ersten Experiments](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Aus Fehlern lernen](https://queue.acm.org/detail.cfm?id=2371297)
+ [Chaos-Engineering-Geschichten](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Canary-Bereitstellung für Chaos-Experimente](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Zugehörige Videos:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Zugehörige Beispiele:**
+ [Well-Architected Lab: Level 300: Testen auf Resilienz von Amazon EC2, Amazon RDS und Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Chaos Engineering in AWS (Lab)](https://chaos-engineering.workshop.aws/en/)
+ [Resilient and Well-Architected Apps with Chaos Engineering Lab](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Serverless-Chaos (Lab)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Messen und Verbessern der Resilienz Ihrer Anwendung mit AWS Resilience Hub (Lab)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Zugehörige Tools: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Regelmäßiges Abhalten von Gamedays
Nutzen Sie Gamedays, um Ihre Verfahren für Reaktionen auf Ereignisse und Fehler unter möglichst produktionsnahen Bedingungen (einschließlich Produktionsumgebungen) regelmäßig mit den Personen zu testen, die auch in tatsächlichen Fehlerszenarien beteiligt sind. Bei Gamedays werden Vorkehrungen getroffen, die sicherstellen, das sich Produktionsereignisse nicht auf Benutzer auswirken.
Bei Gamedays wird ein Fehler oder Ereignis simuliert, um Systeme, Prozesse und die Reaktion von Teams zu testen. Dabei sollen die auszuführenden Aktionen vom Team wie im Fall eines außergewöhnlichen Ereignisses tatsächlich ausgeführt werden. So können Sie nachvollziehen, wo nachgebessert werden kann. Zudem üben Sie dabei ein, wie Ihre Organisation mit Ereignissen umgeht. Gamedays sollten regelmäßig ausgeführt werden, damit *die Reaktion für Ihr Team* zu einem Reflex wird.
Nachdem Sie Ihre Maßnahmen für Ausfallsicherheit implementiert und in Umgebungen abseits der Produktion getestet haben, können Sie an einem Gameday feststellen, ob in der Produktion alles wie geplant funktioniert. An einem Gameday, insbesondere am ersten, werden alle Entwickler und Betriebsteams miteinbezogen und über Zeitpunkt sowie Ablauf des Tests informiert. Die Runbooks müssen vorhanden sein. Simulierte Ereignisse, auch potenzielle Ausfallereignisse, werden wie vorgeschrieben in den Produktionssystemen ausgeführt und deren Auswirkungen werden bewertet. Wenn alle Systeme wie vorgesehen funktionieren, erfolgen Erkennung und Selbstreparatur mit minimalen oder gar keinen Auswirkungen. Wenn jedoch negative Auswirkungen festgestellt werden, wird ein Rollback des Tests durchgeführt und die Workload-Probleme werden bei Bedarf manuell behoben (gemäß Runbook). Da Gamedays oft in der Produktion stattfinden, sollten alle Vorkehrungen getroffen werden, um Kunden vor Beeinträchtigungen der Verfügbarkeit zu schützen.
**Gängige Antimuster:**
+ Die eigenen Verfahren werden dokumentiert, jedoch nie trainiert.
+ Entscheidungsträger werden bei den Tests außen vorgelassen.
**Vorteile der Einführung dieser Best Practice:** Die regelmäßige Durchführung von Gamedays sorgt dafür, dass bei einem tatsächlichen Vorfall alle Mitarbeiter die Richtlinien und Verfahren befolgen. Außerdem wird überprüft, ob diese Richtlinien und Verfahren geeignet sind.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Planen Sie Gamedays, um Ihre Runbooks und Playbooks regelmäßig zu trainieren. An Gamedays sollten alle Mitarbeiter beteiligt werden, die von Produktionsunterbrechungen betroffen sein können: Geschäftsinhaber, Entwickler, Produktionsmitarbeiter und die Teams, die auf Vorfälle reagieren.
+ Führen Sie Ihre Last- oder Leistungstests durch und schleusen Sie anschließend Fehler ein.
+ Prüfen Sie die Runbooks auf Anomalien und suchen Sie nach Möglichkeiten zur Ausführung der Playbooks.
+ Optimieren Sie bei Abweichungen die Runbooks oder ändern Sie das Verhalten. Ermitteln Sie bei Ausführung eines Playbooks das Runbook, das hätte verwendet werden sollen, oder erstellen Sie ein neues.
## Ressourcen
**Zugehörige Dokumente:**
+ [Was ist AWS GameDay?](https://aws.amazon.com/gameday/)
**Zugehörige Videos:**
+ [AWS re:Invent 2019: Verbesserung der Ausfallsicherheit mit Chaos-Engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Zugehörige Beispiele:**
+ [AWS Well-Architected Labs: Testen der Ausfallsicherheit](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# ZUV 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 Ihrer Workload. Legen Sie diese Ziele 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/2022-03-31/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/2022-03-31/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.
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. *Wiederherstellungsregion* bezieht sich auf einen AWS-Region anders als der primäre, der für Ihre Workload verwendet wird.
![\[Diagramm der DR-Strategien\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/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 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 in Minuten, RTO in zehn Minuten): Bereitstellung einer Kopie Ihrer Kern-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 in Sekunden, RTO in Minuten): Behalten Sie eine verkleinerte, aber voll funktionsfähige Version Ihres Workloads in der Wiederherstellungsregion bei. 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 Kontrollebene. Wenn voll skaliert, wird dies als **Hot Standby bezeichnet**.
+ **Multi-Region (Multi-Site) aktiv-aktiv** (RPO nahe Null, RTO potenziell Null): Ihre Workload wird auf mehreren AWS-Regionen bereitgestellt und bedient aktiv 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 ist oft nicht sofort klar. 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.
**Gewünschtes Ergebnis:**
Für jede Workload gibt es eine definierte und implementierte DR-Strategie, die es dieser Workload ermöglicht, die DR-Ziele zu erreichen. DR-Strategien zwischen Workloads nutzen wiederverwendbare Muster (wie die zuvor beschriebenen Strategien),
**Gängige Antimuster:**
+ Implementierung von inkonsistenten Wiederherstellungsprozeduren für Workloads mit ähnlichen DR-Zielen.
+ Die DR-Strategie muss im Notfall Ad-hoc umgesetzt werden.
+ Kein Plan verfügbar für DR.
+ Abhängigkeit von Vorgängen auf der Steuerungsebene während der Wiederherstellung.
**Vorteile der Einführung dieser bewährten Methode:**
+ Durch die Nutzung definierter Wiederherstellungsstrategien können Sie verbreitet verwendete Tools und Testverfahren verwenden.
+ Die Verwendung definierter Wiederherstellungsstrategien ermöglicht einen effizienteren Wissensaustausch zwischen den Teams und eine einfachere Implementierung von DR für die eigenen Workloads.
**Risikostufe, falls 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
Zu jedem dieser Schritte finden Sie unten weitere Informationen.
1. Bestimmen Sie eine DR-Strategie, die die Wiederherstellungsanforderungen für diese Workload erfüllt.
1. Überprüfen Sie die Muster, wie die ausgewählte DR-Strategie umgesetzt werden kann.
1. Beurteilen Sie die Ressourcen Ihrer Workloads und deren Konfiguration in der Wiederherstellungsregion vor dem Failover (während des normalen Betriebs).
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.
1. Legen Sie fest und implementieren Sie, wie Sie den Datenverkehr bei Bedarf (im Notfall) zum Failover umleiten werden.
1. Entwerfen Sie einen Plan, wie Ihre Workload zurückgehen wird.
**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/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Weitere Information finden Sie unter [Betriebskontinuitätsplan (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 darauf folgenden Schritten werden Sie die Strategie auf Ihre spezifische Workload anwenden.
**Sicherung und Wiederherstellung**
*Sicherung und Wiederherstellung* ist die am einfachsten zu implementierende Strategie, erfordert aber mehr Zeit und Aufwand für die Wiederherstellung der Workload, was zu höheren RTO- und RPO-Werten 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/2022-03-31/framework/images/backup-restore-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Notfallwiederherstellungsarchitektur (DR) auf 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**
Mit dem *Pilot Light-Verfahren* replizieren Sie Ihre Daten von Ihrer primären Region auf 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 Compute Instances bereitgestellt.
![\[Diagramm der Architektur eines Pilot Light\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Notfallwiederherstellungsarchitektur (DR) auf 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/).
**Warm Standby**
Das *Warm Standby* Verfahren stellt sicher, dass eine verkleinerte, 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 eingesetzt wird, spricht man von einem *Hot Standby*.
![\[Diagramm mit Abbildung 21: Warm Standby-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/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 die Kapazität bei Bedarf zur Verfügung steht, sollten Sie die Verwendung für [Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) für EC2-Instances erwägen. Wenn Sie AWS Lambda verwenden, [können Sie mit Hilfe der Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) Ausführungsumgebungen sicherstellen, die darauf vorbereitet sind, sofort auf die Aufrufe Ihrer Funktion zu reagieren.
Weitere Details zu dieser Strategie finden Sie unter [Notfallwiederherstellungsarchitektur (DR) auf 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**
Sie können Ihre 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). Bei einer DR-Strategie wird, wenn die Workload in einer der AWS-Regionen, in denen sie bereitgestellt wird, nicht unterstützt werden kann, diese Region evakuiert und die verbleibende(n) Region(en) wird (werden) zur Aufrechterhaltung der Verfügbarkeit verwendet. 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/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Architektur für die Notfallwiederherstellung (Disaster Recovery, DR) auf 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/).
**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 Multi-Site Aktiv/Akitv-Ansatz als [Amazon EC2-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) und [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) stellen Ressourcen in mehreren AZs bereit, die Anfragen bearbeiten. Die Architektur demonstriert auch Hot Standby, wo, wenn die primäre [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) Instance ausfällt (oder die AZ selbst ausfällt), die Standby-Instance dann zur primären Instance hochgestuft wird.
![\[Diagramm mit Abbildung 23: Multi-AZ-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/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 wichtig für Daten, die sich auf eine einzige Zone beschränken, wie z. B. [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 ein AZ ausfällt, müssen Sie diese Daten auf einem 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 gebräuchlicher alternativer Ansatz für eine einzelne Region, Multi-AZ DR, wird in diesem Blogbeitrag vorgestellt, [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 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/). 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/aktiven oder aktiv/passiven Ansatz entscheiden.
Hinweis: Für einige Workloads gibt es gesetzliche Anforderungen an die Datenaufbewahrung. 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 Infrastruktur und AWS-Ressourcen verwenden Sie Infrastruktur als Code oder Tools [AWS CloudFormation](https://aws.amazon.com/cloudformation) von Drittanbietern wie Hashicorp Terraform. Für die Bereitstellung auf mehrere Konten und Regionen mit einem einzigen Vorgang können Sie [AWS CloudFormation-StackSets verwenden](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). 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 der Hilfe 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 steuern, ob ein bereitgestellter Stack aktiv oder in Bereitschaft ist. Ein Beispiel für eine solche CloudFormation-Vorlage ist in diesem [Blogbeitrag enthalten.](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Alle DR-Strategien setzen voraus, dass die Datenquellen innerhalb der AWS-Region gesichert werden und diese Sicherungen dann 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. Bei Pilot Light, Warm Standby und Multi-Site Aktiv/Aktiv sollten Sie auch 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-Dienste regionenübergreifend funktionieren, finden Sie in dieser Blogserie über das [Erstellen einer regionenübergreifenden 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-/Schreibinstance 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 Daten in der Wiederherstellungsregion wiederherstellen. Transparenz [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md) für weitere Informationen. Der Wiederaufbau der Infrastruktur umfasst die Erstellung von Ressourcen wie EC2-Instances zusätzlich zu den [Amazon Virtual Private Cloud (Amazon VPC),](https://aws.amazon.com/vpc)Subnetzen und benötigten Sicherheitsgruppen. Sie können einen Großteil des Wiederherstellungsprozesses automatisieren. Um zu erfahren wie das gemacht wird, [sehen Sie sich diesen Blogbeitrag an.](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 eingeleitetes Failover auf der Grundlage von Zustandsprüfungen oder Alarmen ist mit Vorsicht zu genießen, da ein unnötiges Failover (Fehlalarm) Kosten wie Nichtverfügbarkeit und Datenverlust verursacht. Daher wird häufig eine manuell initiiertes Failover verwendet. In diesem Fall sollten Sie die Schritte für das Failover dennoch automatisieren, so dass 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 initiiertes Failover zu implementieren, können Sie den [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/)verwenden, der eine hochverfügbare API für die Datenebene bietet, 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 Steuerungsebene, wie in beschriebe in [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md).
Mehr Information darüber sowie andere Optionen finden [Sie in diesem Abschnitt des Disaster Recovery Whitepaper](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, wie Ihre Workload zurückgehen wird.**
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. Bei der Verwendung [Amazon DynamoDB globaler Tabellen,](https://aws.amazon.com/dynamodb/global-tables/)setzt DynamoDB die Übertragung aller anstehenden Schreibvorgänge fort, auch wenn die Tabelle in der primären Region nicht mehr verfügbar ist, sobald sie wieder online ist. Bei der Verwendung von [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) und [verwaltetem geplanten Failover](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)wird die bestehende Replikationstopologie der Aurora globalen Datenbank wird beibehalten. Daher wird die ehemalige Lese-/Schreibinstance 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. Eine Anleitung, wie Sie dies mit Amazon Aurora Global Database unter der Annahme eines ungeplanten Failover tun können, *finden Sie beispielsweise* in dieser Übung: [Fail-Back einer globalen Datenbank](https://awsauroralabsmy.com/global/failback/).
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.
**Grad des Aufwands für den Implementierungsplan:**Hoch
## Ressourcen
**Ähnliche 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 (Erste Schritte)](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)
**Relevante 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) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
+ [Erste Schritte mit AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Ähnliche Beispiele:**
+ [AWS Well-Architected Labs – Disaster Recovery (Notfallwiederherstellung)](https://wellarchitectedlabs.com/reliability/disaster-recovery/) – Eine Reihe von Workshops zur Veranschaulichung der DR-Strategien
# REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:
Testen Sie regelmäßig den Failover zu Ihrem Wiederherstellungsstandort, um den ordnungsgemäßen Betrieb und die Einhaltung von RTO und RPO sicherzustellen.
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.
**Gängige Antimuster:**
+ Failover werden nie in der Produktion durchgeführt.
**Vorteile der Einführung dieser bewährten Methode:** Durch regelmäßige Tests des Notfallwiederherstellungsplans wird sichergestellt, dass er bei Bedarf funktioniert und vom Team umgesetzt werden kann.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Workloads für die Wiederherstellung auslegen. Testen Sie regelmäßig Ihre Wiederherstellungspfade. Mithilfe des Recovery Oriented Computing (wiederherstellungsorientiertes Computing) können Sie die für die Wiederherstellung förderlichen Merkmale in Systemen identifizieren. Hierzu zählen: Isolation und Redundanz, die systemweite Fähigkeit zum Zurücksetzen von Änderungen, das Überwachen und Ermitteln des Systemzustands, die Bereitstellung von Diagnosen, automatisierte Wiederherstellungen, ein modulares Design und die Möglichkeit von Neustarts. Erproben Sie den Wiederherstellungspfad, um sicherzustellen, dass die Wiederherstellung innerhalb des vorgegebenen Zeitraums erfolgt und der vorgegebene Zustand erreicht wird. Dokumentieren Sie während dieser Wiederherstellung auftretende Probleme in Ihren Runbooks und suchen Sie vor dem nächsten Test nach Lösungen.
+ [The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project](http://roc.cs.berkeley.edu/)
+ Verwenden Sie CloudEndure Disaster Recovery zum Implementieren und Testen Ihrer Strategie für die Notfallwiederherstellung.
+ [Testen der Lösung für die Notfallwiederherstellung mit CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [CloudEndure Disaster Recovery auf AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 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)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-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)
+ [Testen der Lösung für die Notfallwiederherstellung mit CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [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)
**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)
+ [AWS re:Invent 2019: Lösungen für Sicherung, Wiederherstellung und Notfallwiederherstellung mit AWS AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Ähnliche Beispiele:**
+ [AWS Well-Architected Labs: Testen der Ausfallsicherheit](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# 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)