# Zuverlässigkeit
<a name="a-reliability"></a>

**Topics**
+ [Grundlagen](a-foundations.md)
+ [Workload-Architektur](a-workload-architecture.md)
+ [Änderungsverwaltung](a-change-management.md)
+ [Fehlerverwaltung](a-failure-management.md)

# Grundlagen
<a name="a-foundations"></a>

**Topics**
+ [ZUV 1 Was ist bei der Verwaltung von Servicekontingenten und Einschränkungen zu beachten?](w2aac19b9b5b5.md)
+ [ZUV 2 Was ist bei der Planung der Netzwerktopologie zu beachten?](w2aac19b9b5b7.md)

# ZUV 1 Was ist bei der Verwaltung von Servicekontingenten und Einschränkungen zu beachten?
<a name="w2aac19b9b5b5"></a>

Für cloudbasierte Workload-Architekturen gibt es Servicekontingente (die auch als Service Limits bezeichnet werden). Diese Kontingente dienen dazu, nicht versehentlich mehr Ressourcen bereitzustellen als nötig und Anfrageraten für API-Vorgänge zu begrenzen, um Services vor Missbrauch zu schützen. Darüber hinaus gibt es Ressourceneinschränkungen, z. B. die Rate, mit der Bits durch ein Glasfaserkabel geschleust werden können, oder die Speichermenge auf einer physischen Festplatte. 

**Topics**
+ [REL01-BP01 Kenntnis von Servicekontingenten und Einschränkungen](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Verwalten von Servicekontingenten für mehrere Konten und Regionen](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Berücksichtigen von festen Servicekontingenten und Einschränkungen durch die Architektur](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Überwachen und Verwalten von Kontingenten](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automatisieren der Kontingentverwaltung](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Sicherstellen eines ausreichenden Spielraums zwischen den aktuellen Kontingenten und der maximalen Nutzung, damit ein Failover möglich ist](rel_manage_service_limits_suff_buffer_limits.md)

# REL01-BP01 Kenntnis von Servicekontingenten und Einschränkungen
<a name="rel_manage_service_limits_aware_quotas_and_constraints"></a>

 Sie wissen über die Standardkontingente und Anfragen zur Kontingenterhöhung für Ihre Workload-Architektur Bescheid. Außerdem wissen Sie, welche Ressourceneinschränkungen, z. B. bezüglich Datenträgern oder Netzwerken, potenziell große Auswirkungen haben. 

 Service Quotas ist ein AWS-Service, mit dem Sie Ihre Kontingente für über 100 AWS-Services von einem Standort aus verwalten können. Neben der Suche nach den Kontingentwerten können Sie auch Kontingenterhöhungen über die Service Quotas-Konsole oder über das AWS SDK anfordern und nachverfolgen. AWS Trusted Advisor bietet eine Servicekontingent-Prüfung, die Ihre Nutzung und Ihre Kontingente für bestimmte Aspekte einiger Services anzeigt. Die Standardkontingente pro Service finden Sie ebenfalls in der AWS-Dokumentation für den jeweiligen Service. Weitere Informationen finden Sie unter [Amazon VPC Quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). Ratenlimits für gedrosselte APIs werden innerhalb des API Gateway selbst festgelegt. Dazu wird ein Nutzungsplan konfiguriert. Andere Limits, die für ihre jeweiligen Services konfiguriert werden, sind bereitgestellte IOPS, zugewiesener RDS-Speicher und EBS-Volume-Zuweisungen. Amazon Elastic Compute Cloud (Amazon EC2) verfügt über ein eigenes Service Limits-Dashboard, mit dem Sie Ihre Limits für Instances, Amazon Elastic Block Store (Amazon EBS) und Elastic IP-Adressen verwalten können. Wenn Sie einen Anwendungsfall haben, bei dem sich Servicekontingente auf die Leistung Ihrer Anwendung auswirken und eine Anpassung an Ihre Anforderungen nicht möglich ist, wenden Sie sich an den AWS Support, um zu ermitteln, ob es Lösungen gibt. 

 **Gängige Antimuster:** 
+  Bereitstellen einer Workload ohne Berücksichtigung der Servicekontingente für die verwendeten AWS-Services. 
+  Entwerfen einer Workload ohne Untersuchung und Berücksichtigung der Designeinschränkungen für AWS-Services. 
+  Bereitstellen einer vielgenutzten Workload, die eine bekannte vorhandene Workload ersetzt, ohne vorher die notwendigen Kontingente zu konfigurieren oder sich mit AWS Support in Verbindung zu setzen. 
+  Planen eines Ereignisses, das Datenverkehr zur Workload lenken soll, ohne vorher die notwendigen Kontingente zu konfigurieren oder sich mit AWS Support in Verbindung zu setzen. 

 **Vorteile der Einführung dieser bewährten Methode:** Wenn Sie die Servicekontingente, API-Drosselungslimits und Designeinschränkungen kennen, können Sie diese Aspekte bei Entwurf, Implementierung und Betrieb der Workload berücksichtigen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Überprüfen Sie die AWS-Servicekontingente in der veröffentlichten Dokumentation und in Service Quotas. 
  +  [AWS Service Quotas (früher als Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  Ermitteln Sie alle für die Workload erforderlichen Services durch Untersuchung des Bereitstellungscodes. 
+  Verwenden Sie AWS Config, um alle AWS-Ressourcen zu finden, die in Ihren AWS-Konten verwendet werden. 
  +  [AWS Config-unterstützte AWS-Ressourcentypen](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) 
+  Sie können auch Ihre AWS CloudFormation verwenden, um die genutzten AWS-Ressourcen zu ermitteln. Sehen Sie sich die Ressourcen an, die in der AWS-Managementkonsole oder über den Befehl „list-stack-resources“ in der Befehlszeilenschnittstelle erstellt wurden. Sie können zudem Ressourcen anzeigen, die für die Bereitstellung in der Vorlage selbst konfiguriert sind. 
  +  [Anzeigen Ihrer AWS CloudFormation-Stack-Daten und -Ressourcen auf der AWS-Managementkonsole](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) 
  +  [AWS CLI for CloudFormation: list-stack-resources (AWS CLI für CloudFormation: list-stack-resources)](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) 
+  Ermitteln Sie die geltenden Servicekontingente. Nutzen Sie die programmgesteuert über Trusted Advisor und Service Quotas zugänglichen Informationen. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [AWS Marketplace: CMDB-Produkte zur Nachverfolgung von Limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (früher als Service Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Bewährte AWS Trusted Advisor Trusted Advisor-Methoden (Prüfungen) (siehe Abschnitt „Servicelimits“)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS Limit Monitor in AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Ähnliche Videos:** 
+  [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP02 Verwalten von Servicekontingenten für mehrere Konten und Regionen
<a name="rel_manage_service_limits_limits_considered"></a>

 Wenn Sie mehrere AWS-Konten oder AWS-Regionen verwenden, müssen Sie die entsprechenden Kontingente in allen Umgebungen anfordern, in denen die Produktions-Workloads ausgeführt werden. 

 Servicekontingente werden pro Konto aufgezeichnet. Sofern nicht anders angegeben, gilt jedes Kontingent für eine bestimmte AWS-Region. Zusätzlich zu den Produktionsumgebungen verwalten Sie auch Kontingente in allen anwendbaren Nicht-Produktionsumgebungen, damit Tests und Entwicklung nicht behindert werden. 

 **Gängige Antimuster:** 
+  Es wird zugelassen, dass die Ressourcennutzung in einer Isolationszone zunimmt, ohne dass es einen Mechanismus zur Aufrechterhaltung der Kapazität in den anderen Zonen gibt. 
+  Alle Kontingente werden manuell und in jeder Isolationszone einzeln festgelegt. 
+  Es wird nicht sichergestellt, dass regional isolierte Bereitstellungen groß genug sind, um bei Ausfall einer Bereitstellung den zunehmenden Datenverkehr aus einer anderen Region zu bewältigen. 

 **Vorteile der Einführung dieser bewährten Methode:** Wenn Sie die aktuelle Last bei Nichtverfügbarkeit einer Isolationszone bewältigen können, kann dies dabei helfen, dass beim Failover eine geringere Anzahl von Fehlern auftritt, anstatt dass dieser einen Denial-of-Service für die Kunden verursacht. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Wählen Sie relevante Konten und Regionen anhand von Serviceanforderungen, regulatorischen Anforderungen sowie Anforderungen für die Latenz und die Notfallwiederherstellung aus. 
+  Ermitteln Sie Servicekontingente für alle relevanten Konten, Regionen und Availability Zones. Die Limits gelten für ein Konto und eine Region. 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [AWS Marketplace: CMDB-Produkte zur Nachverfolgung von Limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (früher als Service Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Bewährte AWS Trusted Advisor Trusted Advisor-Methoden (Prüfungen) (siehe Abschnitt „Servicelimits“)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS Limit Monitor in AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Relevante Videos:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP03 Berücksichtigen von festen Servicekontingenten und Einschränkungen durch die Architektur
<a name="rel_manage_service_limits_aware_fixed_limits"></a>

 Achten Sie auf unveränderliche Servicekontingente und physische Ressourcen und gestalten Sie sie so, dass sie keine Auswirkungen auf die Zuverlässigkeit haben. 

 Beispiele sind Netzwerkbandbreite, AWS Lambda-Nutzlastgröße, Drosselungs-/Burst-Rate für API Gateway und gleichzeitige Benutzerverbindungen zu einem Amazon Redshift-Cluster. 

 **Gängige Antimuster:** 
+  Benchmarking erfolgt unter Ausnutzung des Burst-Limits nur für sehr kurze Zeit, anschließend wird aber erwartet, dass der Service über einen längeren Zeitraum mit der betreffenden Kapazität ausgeführt wird. 
+  Auswahl eines Designs, bei dem pro Benutzer oder Kunde eine Ressource eines Services verwendet wird, ohne die Einschränkungen des Designs zu kennen, die bei dessen Skalierung zum Ausfall führen. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Nachverfolgung fester Kontingente in AWS-Services und von Einschränkungen in anderen Teilen der Workload (wie z. B. Einschränkungen in Bezug auf Konnektivität, IP-Adressen und Services von Drittanbietern) können Sie Trends hin zu einem Kontingent erkennen. Außerdem können Sie so das Kontingent erweitern, bevor es überschritten wird. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Berücksichtigen Sie feste Servicekontingente. Achten Sie bei der Gestaltung der Architektur auf feste Servicekontingente und Einschränkungen. 
  +  [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [AWS Marketplace: CMDB-Produkte zur Nachverfolgung von Limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (früher als Service Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Bewährte AWS Trusted Advisor Trusted Advisor-Methoden (Prüfungen) (siehe Abschnitt „Servicelimits“)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS Limit Monitor in AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Ähnliche Videos:** 
+  [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP04 Überwachen und Verwalten von Kontingenten
<a name="rel_manage_service_limits_monitor_manage_limits"></a>

 Überprüfen Sie die potenzielle Nutzung und erhöhen Sie Ihre Kontingente entsprechend, um einen geplanten Nutzungsanstieg zu ermöglichen. 

 Für unterstützte Dienste können Sie Ihre Kontingente verwalten, indem Sie CloudWatch-Alarme konfigurieren. So wird die Nutzung überwacht und bei einer sich abzeichnenden Erschöpfung von Kontingenten werden Sie benachrichtigt. Diese Alarme können über Service Quotas oder Trusted Advisor ausgelöst werden. Sie können auch Metrikfilter für CloudWatch Logs verwenden, um Muster in Protokollen zu suchen und zu extrahieren und dadurch zu bestimmen, ob die Nutzung Kontingentschwellenwerte erreicht. 

 **Gängige Antimuster:** 
+  Es werden Alarme für den Fall konfiguriert, dass Service Quotas zur Neige gehen, aber es gibt keinen Prozess für die Reaktion auf eine entsprechende Warnung. 
+  Es werden nur Alarme für Services konfiguriert, die von Service Quotas unterstützt werden, und es erfolgt keine Überwachung anderer Services. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die automatische Verfolgung der AWS-Servicekontingente und die Überwachung ihrer Nutzung können Sie feststellen, wann ein Kontingent zu Neige geht. Mithilfe dieser Überwachungsdaten können Sie zudem abschätzen, wann Kontingente zur Kosteneinsparung verringert werden sollten. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Überwachen und verwalten Sie Ihre Kontingente. Überprüfen Sie Ihre potenzielle Nutzung in AWS, erhöhen Sie Ihre regionalen Servicekontingente entsprechend und planen Sie eine steigende Nutzung ein. 
  +  Erfassen Sie die aktuelle Ressourcennutzung (z. B. Buckets, Instances). Erfassen Sie die aktuelle Ressourcennutzung mithilfe von Service-API-Vorgängen wie der DescribeInstances-API von Amazon EC2. 
  +  Erfassen Sie Ihre aktuellen Kontingente. Verwenden Sie AWS Service Quotas, AWS Trusted Advisor und AWS-Dokumentation. 
    +  Verwenden Sie AWS Service Quotas, ein AWS-Service, der Sie bei der Verwaltung von mehr als 100 AWS-Services an einem einzigen Ort unterstützt. 
    +  Ermitteln Sie Ihre aktuellen Service-Limits anhand von Trusted-Advisor-Service-Limits. 
    +  Ermitteln Sie aktuelle Servicekontingente mithilfe von Service-API-Vorgängen, sofern unterstützt. 
    +  Protokollieren von angeforderten Kontingenterhöhungen und deren Status Nachdem eine Kontingenterhöhung genehmigt wurde, sollten Sie sicherstellen, dass Sie Ihre Datensätze aktualisieren, um die Kontingentänderung widerzuspiegeln. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [AWS Marketplace: CMDB-Produkte zur Nachverfolgung von Limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (früher als Service Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor Überprüfen bewährter Methoden für Service Limits](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html) 
+  [AWS Limit Monitor in AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+  [Überwachen von Service Quotas unter Verwendung von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html) 

 **Ähnliche Videos:** 
+  [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP05 Automatisieren der Kontingentverwaltung
<a name="rel_manage_service_limits_automated_monitor_limits"></a>

 Implementieren Sie Tools, um vor dem Erreichen von Schwellenwerten benachrichtigt zu werden. Durch die Verwendung von AWS Service Quotas-APIs können Sie Anfragen zur Kontingenterhöhung automatisieren. 

 Wenn Sie Ihre Konfigurationsmanagementdatenbank (CMDB) oder das Ticketing-System mit Service Quotas integrieren, können Sie die Verfolgung von Kontingenterhöhungsanfragen und von aktuellen Kontingenten automatisieren. Zusätzlich zum AWS SDK bietet Service Quotas Automatisierung unter Verwendung der AWS Command Line Interface (AWS CLI). 

 **Gängige Antimuster:** 
+  Die Kontingente und die Nutzung werden in Tabellen verfolgt. 
+  Es werden Berichte zur täglichen, wöchentlichen oder monatlichen Nutzung ausgeführt und anschließend wird die Nutzung mit den Kontingenten verglichen. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die automatisierte Nachverfolgung der AWS-Servicekontingente und die Überwachung ihrer Nutzung können Sie feststellen, wann ein Kontingent zu Neige geht. Sie können die Automatisierung einrichten, damit Sie beim Anfordern einer Kontingenterhöhung bei Bedarf unterstützt werden. Wenn sich Ihre Nutzung in die entgegengesetzte Richtung entwickelt, sollten Sie einige Kontingente reduzieren, um von den verringerten Risiken (im Falle von kompromittierten Anmeldeinformationen) und von Kosteneinsparungen zu profitieren. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Richten Sie eine automatisierte Überwachung ein. Implementieren Sie Tools mithilfe von SDKs, um vor dem Erreichen von Schwellenwerten benachrichtigt zu werden. 
  +  Nutzen Sie Service Quotas und erweitern Sie den Service mit einer Lösung zur automatisierten Kontingentüberwachung, z. B. mit AWS Limit Monitor oder einem Angebot aus AWS Marketplace. 
    +  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
    +  [Quota Monitor on AWS – AWS-Lösung](https://aws.amazon.com/answers/account-management/limit-monitor/) 
  +  Richten Sie automatische Reaktionen anhand von Schwellenwerten für Kontingente mit Amazon SNS- und AWS Service Quotas-APIs ein. 
  +  Testen Sie die Automatisierung. 
    +  Konfigurieren Sie Limit-Schwellenwerte. 
    +  Integrieren Sie Änderungsereignisse von AWS Config-Bereitstellungspipelines, Amazon EventBridge oder Ereignisse von Drittanbietern. 
    +  Legen Sie unnatürlich niedrige Schwellenwerte für Kontingente fest, um die Reaktionen zu testen. 
    +  Richten Sie Trigger ein, damit bei Benachrichtigungen geeignete Maßnahmen ergriffen werden und bei Bedarf der AWS Support kontaktiert wird. 
    +  Lösen Sie Änderungsereignisse manuell aus. 
    +  Führen Sie eine Ernstfallübung aus, um den Prozess für die Kontingenterhöhung zu testen. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Konfigurationsverwaltung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management) 
+  [AWS Marketplace: CMDB-Produkte zur Nachverfolgung von Limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (früher als Service Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Bewährte AWS Trusted Advisor Trusted Advisor-Methoden (Prüfungen) (siehe Abschnitt „Servicelimits“)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [Quota Monitor on AWS – AWS-Lösung](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Ähnliche Videos:** 
+  [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP06 Sicherstellen eines ausreichenden Spielraums zwischen den aktuellen Kontingenten und der maximalen Nutzung, damit ein Failover möglich ist
<a name="rel_manage_service_limits_suff_buffer_limits"></a>

 Eine ausgefallene Ressource kann bis zu ihrer ordnungsgemäßen Beendigung weiterhin zu den Kontingenten zählen. Stellen Sie sicher, dass etwaige Überschneidungen aller ausgefallenen Ressourcen mit ihrem Ersatz bis zur Beendigung der ausgefallenen Ressourcen durch Ihre Kontingente abgedeckt sind. Berücksichtigen Sie bei der Berechnung des Spielraums auch den Ausfall einer Availability Zone. 

 **Gängige Antimuster:** 
+  Es werden Servicekontingente auf Grundlage des aktuellen Bedarfs eingerichtet, ohne dass Failover-Szenarien berücksichtigt werden. 

 **Vorteile der Einführung dieser bewährten Methode:** Wenn Ereignisse die Verfügbarkeit potenziell beeinträchtigen könnten, haben Sie die Möglichkeit, in der Cloud Strategien für die Abschwächung solcher Ereignisse oder für die Wiederherstellung im Anschluss daran zu implementieren. Zu solchen Strategien gehört häufig auch das Schaffen zusätzlicher Ressourcen, um solche zu ersetzen, die fehlgeschlagen sind. Ihre Kontingentstrategie muss diese zusätzlichen Ressourcen berücksichtigen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Stellen Sie einen ausreichenden Spielraum zwischen Ihrem Servicekontingent und der maximalen Nutzung sicher, damit ein Failover möglich ist. 
  +  Ermitteln Sie die Servicekontingente unter Berücksichtigung von Bereitstellungsmustern, Verfügbarkeitsanforderungen und Nutzungsanstieg. 
  +  Fordern Sie bei Bedarf Kontingenterhöhungen an. Planen Sie den erforderlichen Zeitraum bis zur Bewilligung von Kontingenterhöhungen. 
    +  Ermitteln Sie die Anforderungen bezüglich der Zuverlässigkeit („Anzahl der Neunen“). 
    +  Legen Sie Fehlerszenarien fest (z. B. Verlust einer Komponente, Availability Zone oder Region). 
    +  Führen Sie eine Bereitstellungsmethode ein (z. B. Canary, Blau/Grün-Bereitstellung, Rot/Schwarz-Bereitstellung oder schrittweise). 
    +  Beziehen Sie einen angemessenen Puffer (z. B. 15 %) in aktuelle Limits ein. 
    +  Planen Sie den Nutzungsanstieg (z. B. Überwachen des Nutzungstrends). 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [AWS Marketplace: CMDB-Produkte zur Nachverfolgung von Limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (früher als Service Limits bezeichnet)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Bewährte AWS Trusted Advisor Trusted Advisor-Methoden (Prüfungen) (siehe Abschnitt „Servicelimits“)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Was ist Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Relevante Videos:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# ZUV 2 Was ist bei der Planung der Netzwerktopologie zu beachten?
<a name="w2aac19b9b5b7"></a>

Workloads existieren häufig in mehreren Umgebungen. Dazu gehören mehrere Cloud-Umgebungen (öffentlich zugängliche und private) und möglicherweise die vorhandene Infrastruktur Ihres Rechenzentrums. Die Pläne müssen Netzwerkaspekte umfassen, wie z. B. die Konnektivität innerhalb und zwischen Systemen, die Verwaltung öffentlicher und privater IP-Adressen und die Auflösung von Domänennamen.

**Topics**
+ [REL02-BP01 Bereitstellen einer hochverfügbaren Netzwerkkonnektivität für öffentliche Endpunkte der Workload](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Bereitstellen redundanter Konnektivität zwischen privaten Netzwerken in der Cloud und in On-Premises-Umgebungen](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Berücksichtigen von Erweiterungen und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Vorziehen von Nabe-und-Speiche-Topologien gegenüber M-zu-N-Netzen](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Erzwingen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht](rel_planning_network_topology_non_overlap_ip.md)

# REL02-BP01 Bereitstellen einer hochverfügbaren Netzwerkkonnektivität für öffentliche Endpunkte der Workload
<a name="rel_planning_network_topology_ha_conn_users"></a>

 Diese Endpunkte und das entsprechende Routing müssen hochverfügbar sein. Verwenden Sie dazu ein hochverfügbares DNS, Content Delivery Networks (CDNs), API Gateway, Load Balancing oder Reverse-Proxys. 

 Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway und Elastic Load Balancing (ELB) bieten allesamt hochverfügbare öffentliche Endpunkte. Sie können auch AWS Marketplace-Software-Appliances für Load Balancing und Proxyvorgänge auswerten. 

 Nutzer des Service, den Ihre Workload bereitstellt, unabhängig davon, ob es sich um Endbenutzer oder andere Services handelt, stellen Anfragen an diese Service-Endpunkte. Es stehen mehrere AWS-Ressourcen zur Verfügung, damit Sie hochverfügbare Endpunkte bereitstellen können. 

 Elastic Load Balancing bietet Load Balancing über Availability Zones hinweg, führt Layer 4 (TCP)- oder Layer 7-Routing (http/https) durch und lässt sich in AWS WAF und in AWS Auto Scaling integrieren, um eine Infrastruktur mit automatischer Fehlerbehebung zu erstellen und Datenverkehrssteigerungen zu absorbieren, während Ressourcen freigegeben werden, wenn der Datenverkehr abnimmt. 

 Amazon Route 53 ist ein skalierbares und hochverfügbares Domain Name System (DNS), das Benutzeranfragen auf effektive Weise mit über AWS bereitgestellter Infrastruktur verbindet – z. B. Amazon EC2-Instances, Elastic Load Balancing-Load Balancers oder Amazon S3-Buckets. Der Service kann außerdem zum Weiterleiten von Benutzern an Infrastruktur außerhalb von AWS eingesetzt werden. 

 AWS Global Accelerator ist ein Service auf Netzwerkebene, mit dem Sie Datenverkehr über das globale AWS-Netzwerk an optimale Endpunkte leiten können. 

 Distributed Denial of Service (DDoS)-Angriffe blockieren möglicherweise legitimen Datenverkehr und verringern die Verfügbarkeit für Ihre Benutzer. AWS Shield bietet automatischen Schutz gegen diese Angriffe ohne zusätzliche Kosten für AWS-Service-Endpunkte in Ihrer Workload. Sie können diese Funktionen zur Erfüllung Ihrer Anforderungen mit bei APN-Partnern und auf dem AWS Marketplace erhältlichen virtuellen Appliances erweitern. 

 **Gängige Antimuster:** 
+  Es werden öffentliche Internetadressen für Instances oder Container verwendet und die Verwaltung der Konnektivität zu ihnen erfolgt über DNS. 
+  Zum Suchen von Services werden IP-Adressen anstelle von Domänennamen verwendet. 
+  Inhalte (Webseiten, statische Komponenten, Mediendateien) werden in einem großen geografischen Bereich ohne ein CDN bereitgestellt. 

 **Vorteile der Einführung dieser bewährten Methode:** Wenn Sie hochverfügbare Services in der Workload implementieren, haben Sie die Gewissheit, dass sie den Benutzern zur Verfügung steht. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Stellen Sie eine hochverfügbare Netzwerkkontinuität für die Benutzer der Workload sicher. Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway und Elastic Load Balancing (ELB) stellen allesamt hochverfügbare öffentliche Endpunkte bereit. Sie können auch AWS Marketplace-Software-Appliances für Load Balancing und Proxyvorgänge auswerten. 
+  Gewährleisten Sie eine hochverfügbare Verbindung zu den Benutzern. 
+  Verwenden Sie einen hochverfügbaren DNS zur Verwaltung der Domänennamen für die Anwendungsendpunkte. 
  +  Wenn die Benutzer über das Internet auf Ihre Anwendung zugreifen, sollten Sie mithilfe von Service-API-Vorgängen die korrekte Nutzung von Internet-Gateways überprüfen. Überprüfen Sie auch, ob die Einträge in den Routing-Tabellen für die Subnetze, die Ihre Anwendungsendpunkte hosten, korrekt sind. 
    +  [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html) 
    +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 
+  Stellen Sie Ihrer Anwendung unbedingt einen hochverfügbaren Reverse-Proxy oder Load Balancer voran. 
  +  Wenn die Benutzer über Ihre On-Premises-Umgebung auf die Anwendung zugreifen, sollten Sie für eine hochverfügbare Verbindung zwischen AWS und der On-Premises-Umgebung sorgen. 
  +  Verwalten Sie Domänennamen mit Route 53. 
    +  [Was ist Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  Nutzen Sie einen externen DNS-Anbieter, der Ihre Anforderungen erfüllt. 
  +  Nutzen Sie Elastic Load Balancing. 
    +  [Was ist Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
  +  Nutzen Sie eine AWS Marketplace-Appliance, die Ihren Anforderungen entspricht. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Direct Connect Resiliency Recommendations (AWS Direct Connect-Resilienzempfehlungen)](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud-Konnektivitätsoptionen – Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Hochverfügbare Netzwerkkonnektivität zwischen mehreren Rechenzentren](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Erste Schritte mit Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [VPC-Endpunkte und VPC-Endpunktservices (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [Was ist Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Was ist Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Was ist Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [Arbeiten mit Direct-Connect-Gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **Ähnliche Videos:** 
+  [AWS re:Invent 2018: Erweitertes VPC-Design und neue Funktionen für Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway-Referenzarchitekturen für verschiedene VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP02 Bereitstellen redundanter Konnektivität zwischen privaten Netzwerken in der Cloud und in On-Premises-Umgebungen
<a name="rel_planning_network_topology_ha_conn_private_networks"></a>

 Verwenden Sie mehrere AWS Direct Connect-Verbindungen oder VPN-Tunnel zwischen separat bereitgestellten privaten Netzwerken. Verwenden Sie für eine hohe Verfügbarkeit mehrere Direct-Connect-Standorte. Wenn Sie mehrere AWS-Regionen verwenden, stellen Sie in mindestens zwei davon Redundanz sicher. Erwägen Sie gegebenenfalls den Einsatz von AWS Marketplace-Appliances als Endpunkte von VPNs. Stellen Sie bei Verwendung von AWS Marketplace-Appliances redundante Instances bereit, um eine hohe Verfügbarkeit in verschiedenen Availability Zones zu gewährleisten. 

 Mit dem Cloud-Service AWS Direct Connect ist es einfach, eine dedizierte Netzwerkverbindung zwischen Ihrer On-Premises-Umgebung und AWS herzustellen. Mit Direct Connect Gateway kann Ihr On-Premises-Rechenzentrum mit mehreren AWS-VPCs verbunden werden, die über mehrere AWS-Regionen verteilt sind. 

 Diese Redundanz behebt mögliche Ausfälle, die sich auf die Ausfallsicherheit der Konnektivität auswirken: 
+  Wie können Sie sich gegen Fehler in Ihrer Topologie wappnen? 
+  Was passiert, wenn Sie etwas falsch konfigurieren oder die Konnektivität entfernen? 
+  Sind Sie in der Lage, eine unerwartete Erhöhung des Datenverkehrs bzw. der Nutzung Ihrer Services aufzufangen? 
+  Sind Sie in der Lage, den Versuch eines Distributed Denial of Service (DDoS)-Angriffs abzuwehren? 

 Berücksichtigen Sie bei der Verbindung Ihrer VPC mit Ihrem On-Premise-Rechenzentrum über VPN auch die Ausfallsicherheits- und Bandbreitenanforderungen, die Sie benötigen, wenn Sie den Anbieter und die Instance-Größe für die Ausführung der Appliance auswählen. Bei der Auswahl einer VPN-Appliance, die in ihrer Implementierung keine Ausfallsicherheit bietet, sollten Sie eine redundante Verbindung über eine zweite Appliance aufbauen. Bei all diesen Szenarios müssen Sie eine akzeptable Wiederherstellungszeit definieren und testen, um sicherzustellen, dass Sie diese Anforderungen erfüllen können. 

 Wenn Sie Ihre VPC über eine Direct-Connect-Verbindung mit Ihrem Rechenzentrum verbinden und diese Verbindung hochverfügbar sein muss, benötigen Sie redundante Direct-Connect-Verbindungen mit jedem Rechenzentrum. Die redundante Verbindung sollte eine zweite Direct-Connect-Verbindung von einem anderen Standort als der ersten verwenden. Wenn Sie mehrere Rechenzentren betreiben, stellen Sie sicher, dass Ihre Verbindungen an unterschiedlichen Orten enden. Verwenden Sie das [Direct Connect Resiliency Toolkit,](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) um dies einzurichten. 

 Wenn Sie sich für ein internetbasiertes Failover auf ein VPN mit einem Site-to-Site VPN entscheiden, ist es wichtig zu verstehen, dass es einen Datendurchsatz von bis zu 1,25 Gbit/s pro VPN-Tunnel bietet, dass Equal Cost Multi Path (ECMP) für ausgehenden Datenverkehr jedoch nicht unterstützt wird, wenn mehrere von AWS verwaltete VPN-Tunnel auf demselben VGW enden. Wir raten davon ab, AWS Managed VPN als Sicherung für Direct-Connect-Verbindungen zu verwenden, es sei denn, Geschwindigkeiten von weniger als 1 Gbit/s während des Failovers stellen für Sie kein Problem dar. 

 Sie können VPC-Endpunkte auch verwenden, um Ihre VPC privat mit unterstützten AWS-Services und VPC-Endpunktservices zu verbinden, powered by AWS PrivateLink, ohne das öffentliche Internet zu durchlaufen. Endpunkte sind virtuelle Geräte. Sie sind horizontal skalierte, redundante und hochverfügbare VPC-Komponenten. Sie ermöglichen die Kommunikation zwischen Instances in Ihrer VPC und Ihren Services, ohne dass es zu Verfügbarkeitsrisiken oder Bandbreitenbeschränkungen für Ihren Netzwerkdatenverkehr kommt. 

 **Gängige Antimuster:** 
+  Einsatz nur eines Konnektivitätsanbieters zwischen dem lokalen Netzwerk und AWS. 
+  Die Konnektivitätsfunktionen der AWS Direct Connect-Verbindung werden genutzt, es gibt aber nur eine Verbindung. 
+  Es gibt nur einen Pfad für die VPN-Konnektivität. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Implementierung redundanter Konnektivität zwischen Ihrer Cloud-Umgebung und Ihrer Unternehmens- bzw. On-Premises-Umgebung können Sie die sichere Kommunikation der abhängigen Services zwischen den beiden Umgebungen gewährleisten. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Stellen Sie sicher, dass eine hochverfügbare Konnektivität zwischen AWS und der On-Premises-Umgebung vorhanden ist. Verwenden Sie mehrere AWS Direct Connect-Verbindungen oder VPN-Tunnel zwischen separat bereitgestellten privaten Netzwerken. Verwenden Sie für eine hohe Verfügbarkeit mehrere Direct-Connect-Standorte. Wenn Sie mehrere AWS-Regionen verwenden, stellen Sie in mindestens zwei davon Redundanz sicher. Erwägen Sie gegebenenfalls den Einsatz von AWS Marketplace-Appliances als Endpunkte von VPNs. Stellen Sie bei Verwendung von AWS Marketplace-Appliances redundante Instances bereit, um eine hohe Verfügbarkeit in verschiedenen Availability Zones zu gewährleisten. 
  +  Stellen Sie sicher, dass eine redundante Verbindung zu Ihrer On-Premises-Umgebung besteht. Möglicherweise benötigen Sie redundante Verbindungen zu mehreren AWS-Regionen, um Ihre Verfügbarkeitsanforderungen zu erfüllen. 
    +  [AWS Direct Connect Resiliency Recommendations (AWS Direct Connect-Resilienzempfehlungen)](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
    +  [Verwenden redundanter Site-to-Site-VPN-Verbindungen für Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
      +  Ermitteln Sie über die Service-API die ordnungsgemäße Nutzung von Direct-Connect-Verbindungen. 
        +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
        +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
        +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
        +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
        +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
        +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
        +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
      +  Wenn nur eine oder gar keine Direct-Connect-Verbindung besteht, richten Sie redundante VPN-Tunnel zu Ihren Virtual Private Gateways ein. 
        +  [Was ist AWS-Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
  +  Erfassen Sie die aktuelle Konnektivität (z. B. Direct Connect, Virtual Private Gateways, AWS Marketplace-Appliances). 
    +  Ermitteln Sie über die Service-API die Konfiguration von Direct-Connect-Verbindungen. 
      +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
      +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
      +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
      +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
      +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
      +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
      +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
    +  Erfassen Sie über die Service API die von Routing-Tabellen genutzten Virtual Private Gateways. 
      +  [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html) 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 
    +  Erfassen Sie über die Service-API die von Routing-Tabellen genutzten AWS Marketplace-Anwendungen. 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Direct Connect Resiliency Recommendations (AWS Direct Connect-Resilienzempfehlungen)](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud-Konnektivitätsoptionen – Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Hochverfügbare Netzwerkkonnektivität zwischen mehreren Rechenzentren](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Verwenden redundanter Site-to-Site-VPN-Verbindungen für Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
+  [Erste Schritte mit Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [VPC-Endpunkte und VPC-Endpunktservices (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [Was ist AWS-Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
+  [Arbeiten mit Direct-Connect-Gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **Relevante Videos:** 
+  [AWS re:Invent 2018: Erweitertes VPC-Design und neue Funktionen für Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway-Referenzarchitekturen für verschiedene VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP03 Berücksichtigen von Erweiterungen und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze
<a name="rel_planning_network_topology_ip_subnet_allocation"></a>

 Die IP-Adressbereiche für Amazon VPC müssen ausreichend groß sein, um die Anforderungen einer Workload zu erfüllen. Dabei sind zukünftige Erweiterungen und Zuweisungen von IP-Adressen zu Subnetzen in verschiedenen Availability Zones zu berücksichtigen. Dies betrifft Load Balancer, EC2-Instances sowie containerbasierte Anwendungen. 

 Wenn Sie Ihre Netzwerktopologie planen, besteht der erste Schritt in der Definition des IP-Adressbereichs. Private IP-Adressbereiche (gemäß RFC 1918-Richtlinien) sollten jeder VPC zugewiesen werden. Berücksichtigen Sie im Rahmen dieses Prozesses die folgenden Anforderungen: 
+  Ermöglichen Sie einen IP-Adressbereich für mehr als eine VPC pro Region. 
+  Planen Sie innerhalb einer VPC Platz für mehrere Subnetze ein, die sich auf mehrere Availability Zones erstrecken. 
+  Lassen Sie für eine zukünftige Erweiterung stets Raum für nicht verwendete CIDR-Blöcke innerhalb einer VPC. 
+  Stellen Sie sicher, dass ein IP-Adressbereich vorhanden ist, um die Anforderungen von temporären EC2-Instances zu erfüllen, die Sie möglicherweise verwenden, z. B. Spot-Flotten für Machine Learning, Amazon EMR-Cluster oder Amazon Redshift-Cluster. 
+  Beachten Sie, dass die ersten vier IP-Adressen und die letzte IP-Adresse in jedem Subnetz-CIDR-Block reserviert und nicht für Sie verfügbar sind. 
+  Sie sollten die Bereitstellung großer VPC CIDR-Blöcke planen. Beachten Sie, dass der VPC CIDR-Block, der anfänglich Ihrer VPC zugewiesen war, nicht geändert oder gelöscht werden kann. Sie können der VPC jedoch zusätzliche, nicht überlappende CIDR-Blöcke hinzufügen. IPv4-CIDRs für Subnetze können nicht geändert werden, IPv6 CIDRs jedoch schon. Bedenken Sie, dass die Bereitstellung der größtmöglichen VPC (/16) mehr als 65 000 IP-Adressen zur Folge hat. Allein im IP-Adressbereich 10.x.x.x könnten Sie 255 solcher VPCs bereitstellen. Sie sollten daher eher auf eine zu große als eine zu kleine Lösung setzen, um die Verwaltung Ihrer VPCs zu vereinfachen. 

 **Gängige Antimuster:** 
+  Es werden kleine VPCs erstellt. 
+  Es werden kleine Subnetze erstellt und anschließend müssen beim Wachstum Subnetze zu Konfigurationen hinzugefügt werden. 
+  Es wird falsch eingeschätzt, wie viele IP-Adressen ein Elastic Load Balancer verwenden kann. 
+  Es werden viele Load Balancer mit hohem Datenverkehr in denselben Subnetzen bereitgestellt. 

 **Vorteile der Einführung dieser bewährten Methode:** So wird sichergestellt, dass Sie das Wachstum Ihrer Workloads bewältigen können und beim Hochskalieren weiterhin die entsprechende Verfügbarkeit bereitstellen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Berücksichtigen Sie bei der Planung Ihres Netzwerks Ihr zukünftiges Wachstum, die Einhaltung gesetzlicher Vorschriften sowie die Kompatibilität mit anderen Netzwerken. Das Wachstum kann unterschätzt werden, gesetzliche Vorschriften können sich ändern, und bei Unternehmensübernahmen oder privaten Netzwerkverbindungen kann die Implementierung ohne fundierte Planung zur Herausforderung werden. 
  +  Wählen Sie relevante AWS-Konten und Regionen anhand von Serviceanforderungen, regulatorischen Anforderungen sowie Anforderungen für die Latenz und die Notfallwiederherstellung aus. 
  +  Identifizieren Sie Ihre Anforderungen bezüglich regionaler VPC-Bereitstellungen. 
  +  Ermitteln Sie die erforderliche Größe der VPCs. 
    +  Ermitteln Sie, ob Multi-VPC-Konnektivität bereitgestellt werden soll. 
      +  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
      +  [Multi-VPC-Konnektivität in einer Region](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
    +  Ermitteln Sie, ob aufgrund von Compliance-Anforderungen getrennte Netzwerke erforderlich sind. 
    +  Legen Sie VPCs so groß wie möglich an. Der VPC-CIDR-Block, der anfänglich Ihrer VPC zugewiesen war, kann nicht geändert oder gelöscht werden. Sie können der VPC jedoch zusätzliche nicht überlappende CIDR-Blöcke hinzufügen. Dies kann jedoch zu einer Fragmentierung der Adressbereiche führen. 
    +  Legen Sie VPCs so groß wie möglich an. Der VPC-CIDR-Block, der anfänglich Ihrer VPC zugewiesen war, kann nicht geändert oder gelöscht werden. Sie können der VPC jedoch zusätzliche nicht überlappende CIDR-Blöcke hinzufügen. Dies kann jedoch zu einer Fragmentierung der Adressbereiche führen. 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud-Konnektivitätsoptionen – Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Hochverfügbare Netzwerkkonnektivität zwischen mehreren Rechenzentren](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Multi-VPC-Konnektivität in einer Region](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 

 **Relevante Videos:** 
+  [AWS re:Invent 2018: Erweitertes VPC-Design und neue Funktionen für Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway-Referenzarchitekturen für verschiedene VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP04 Vorziehen von Nabe-und-Speiche-Topologien gegenüber M-zu-N-Netzen
<a name="rel_planning_network_topology_prefer_hub_and_spoke"></a>

 Wenn mehr als zwei Netzwerkadressbereiche (z. B. VPCs und On-Premises-Netzwerke) über VPC-Peering, AWS Direct Connect oder VPN verbunden sind, verwenden Sie ein Nabe-und-Speiche-Modell, wie es von AWS Transit Gateway bereitgestellt wird. 

 Wenn Sie nur zwei solche Netzwerke haben, können Sie sie einfach miteinander verbinden, doch wenn die Anzahl der Netzwerke zunimmt, ist die Komplexität derart vernetzter Verbindungen nicht mehr tragbar. AWS Transit Gateway bietet ein einfach zu wartendes Nabe-zu-Speiche-Modell, das die Weiterleitung des Datenverkehrs über mehrere Netzwerke ermöglicht. 

![\[Diagramm: Keine Verwendung von AWS Transit Gateway\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)


![\[Diagramm zur Verwendung von AWS Transit Gateway\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)


 **Gängige Antimuster:** 
+  Verbinden von mehr als zwei VPCs mit VPC-Peering. 
+  Es werden mehrere BGP-Sitzungen für jede VPC eingerichtet, um Konnektivität für mehrere Virtual Private Clouds (VPCs) in mehreren AWS-Regionen herzustellen. 

 **Vorteile der Einführung dieser bewährten Methode:** Mit der zunehmenden Anzahl der Netzwerke wird die Komplexität solcher verflochtenen Verbindungen immer größer. AWS Transit Gateway bietet ein einfach zu wartendes Nabe-und-Speiche-Modell, das die Weiterleitung des Datenverkehrs über mehrere Netzwerke ermöglicht. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Ziehen Sie Nabe-und-Speiche-Topologien gegenüber M-zu-N-Netzen vor. Wenn mehr als zwei Netzwerkadressbereiche (VPCs, On-Premises-Netzwerke) über VPC-Peering, AWS Direct Connect oder VPN verbunden sind, verwenden Sie ein Nabe-und-Speiche-Modell, wie es von AWS Transit Gateway bereitgestellt wird. 
  +  Bei nur zwei derartigen Netzwerken können Sie sie einfach miteinander verbinden, doch mit der zunehmenden Anzahl der Netzwerke wird die Komplexität solcher verflochtenen Verbindungen immer größer. AWS Transit Gateway bietet ein einfach zu wartendes Nabe-und-Speiche-Modell, das die Weiterleitung des Datenverkehrs über mehrere Netzwerke ermöglicht. 
    +  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Hochverfügbare Netzwerkkonnektivität zwischen mehreren Rechenzentren](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [VPC-Endpunkte und VPC-Endpunktservices (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Was ist ein Transit-Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

 **Relevante Videos:** 
+  [AWS re:Invent 2018: Erweitertes VPC-Design und neue Funktionen für Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway-Referenzarchitekturen für verschiedene VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP05 Erzwingen von sich nicht überschneidenden privaten IP-Adressbereichen in allen privaten Adressbereichen, in denen eine Verbindung besteht
<a name="rel_planning_network_topology_non_overlap_ip"></a>

 Die IP-Adressbereiche Ihrer VPCs dürfen sich nicht überschneiden, wenn sie per Peering oder über VPN verbunden sind. Ebenso müssen Sie IP-Adresskonflikte zwischen einer VPC und lokalen Umgebungen oder anderen verwendeten Cloud-Anbietern vermeiden. Sie müssen bei Bedarf auch die Möglichkeit haben, private IP-Adressbereiche zuzuweisen. 

 Ein IP-Adressenverwaltungssystem (IPAM) kann dabei helfen. Im AWS Marketplace stehen mehrere IPAMs zur Verfügung. 

 **Gängige Antimuster:** 
+  Verwenden Sie denselben IP-Bereich in Ihrer VPC wie im lokalen Netzwerk oder in Ihrem Unternehmensnetzwerk. 
+  Keine Verfolgung von IP-Bereichen von VPCs, die zur Bereitstellung der Workloads verwendet werden. 

 **Vorteile der Einführung dieser bewährten Methode:** Mit der aktiven Planung des Netzwerks stellten Sie sicher, dass dieselbe IP-Adresse in miteinander verbunden Netzwerken nicht mehrmals vorkommt. So wird verhindert, dass Routing-Probleme in Teilen der Workload auftreten, die die verschiedenen Anwendungen verwenden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Überwachen und verwalten Sie die CIDR-Nutzung. Bewerten Sie die potenzielle Nutzung in AWS, fügen Sie vorhandenen VPCs CIDR-Bereiche hinzu und erstellen Sie neue VPCs, um das geplante Wachstum abzudecken. 
  +  Ermitteln Sie den aktuellen CIDR-Umfang (z. B. VPCs, Subnetze). 
    +  Erfassen Sie über die Service-API den aktuellen CIDR-Umfang. 
  +  Erfassen Sie die aktuelle Subnetzauslastung. 
    +  Ermitteln Sie über die Service-API die in jeder Region pro VPC vorhandenen Subnetze. 
      +  [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) 
    +  Zeichnen Sie die aktuelle Auslastung auf. 
    +  Prüfen Sie, ob sich IP-Bereiche überschneiden. 
    +  Berechnen Sie die freie Kapazität. 
    +  Identifizieren Sie sich überschneidende IP-Bereiche. Sie können wahlweise zu einem neuen Adressbereich migrieren oder NAT-Appliances (Network and Port Translation) aus AWS Marketplace verwenden, wenn Sie die sich überschneidenden Bereiche verbinden müssen. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [APN-Partner: Partner, die Sie bei der Planung Ihres Netzwerks unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace für Netzwerkinfrastruktur](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud-Konnektivitätsoptionen – Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Hochverfügbare Netzwerkkonnektivität zwischen mehreren Rechenzentren](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Was ist Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Was ist IPAM? ](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 

 **Ähnliche Videos:** 
+  [AWS re:Invent 2018: Erweitertes VPC-Design und neue Funktionen für Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway-Referenzarchitekturen für verschiedene VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# Workload-Architektur
<a name="a-workload-architecture"></a>

**Topics**
+ [ZUV 3 Wie entwerfen Sie Ihre Workload-Service-Architektur?](w2aac19b9b7b5.md)
+ [ZUV 4 Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle vermieden werden?](w2aac19b9b7b7.md)
+ [ZUV 5 Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle abgemildert oder bewältigt werden?](w2aac19b9b7b9.md)

# ZUV 3 Wie entwerfen Sie Ihre Workload-Service-Architektur?
<a name="w2aac19b9b7b5"></a>

Erstellen Sie hoch skalierbare und zuverlässige Workloads mithilfe einer serviceorientierten Architektur (SOA) oder einer Microservices-Architektur. Eine serviceorientierte Architektur (SOA) hat zum Ziel, Softwarekomponenten über Service-Schnittstellen wiederverwendbar zu machen. Die Microservices-Architektur geht noch weiter, um Komponenten kleiner und einfacher zu machen.

**Topics**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Bereitstellen von Serviceverträgen pro API](rel_service_architecture_api_contracts.md)

# REL03-BP01 Segmentierung Ihres Workloads
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 Die Workload-Segmentierung ist wichtig, wenn es um die Festlegung der Resilienzanforderungen Ihrer Anwendung geht. Eine monolithische Architektur sollte vermieden werden, wann immer möglich. Stattdessen sollten Sie sorgfältig überlegen, welche Anwendungskomponenten in Microservices aufgeteilt werden können. Abhängig von den Anforderungen Ihrer Anwendung könnte es sich im Endergebnis um eine Kombination aus einer serviceorientierten Architektur (SOA) und Microservices handeln, wenn dies möglich ist. Workloads, die zustandslos sein können, können eher als Microservices bereitgestellt werden. 

 **Gewünschtes Ergebnis:** Workloads sollten unterstützbar, skalierbar und so lose miteinander verbunden sein wie möglich. 

 Wiegen Sie bei Entscheidungen zur Segmentierung von Workloads die Vorteile und die Komplexitäten miteinander ab. Was für ein neues Produkt richtig ist, das gerade auf dem Markt eingeführt wird, unterscheidet sich von den Anforderungen eines Workloads, der von Anfang an skalierbar sein muss. Bei einem Faktorwechsel für einen vorhandenen Monolith müssen Sie berücksichtigen, wie gut dieser aufgeteilt und in zustandslose Anwendungen transformiert werden kann. Die Aufteilung von Services in kleinere Teile ermöglicht kleinen, klar definierten Teams, diese weiterzuentwickeln und zu verwalten. Kleinere Services können jedoch Komplexitäten wie eine möglicherweise erhöhte Latenz, ein komplexeres Debugging und einen erhöhten operativen Aufwand einführen. 

 **Typische Anti-Muster:** 
+  Der [Microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) ist eine Situation, in der die einzelnen Komponenten so stark voneinander abhängig werden, dass der Ausfall einer einzigen Komponente einen wesentlich größeren Ausfall bewirkt. Das bedeutet, dass die Komponenten so starr und anfällig wie ein Monolith sind. 

 **Vorteile der Einrichtung dieser Best Practice:** 
+  Spezifischere Segmente führen zu einer größeren Agilität, zu organisatorischer Flexibilität und zu Skalierbarkeit. 
+  Die Auswirkungen von Service-Unterbrechungen werden reduziert. 
+  Die einzelnen Komponenten einer Anwendung besitzen möglicherweise unterschiedliche Anforderungen an die Verfügbarkeit, die von einer stärkeren Segmentierung besser unterstützt werden können. 
+  Die Verantwortlichkeiten der Teams, die den Workload unterstützen, sind klar definiert. 

 **Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Wählen Sie Ihren Architekturtyp basierend auf der Segmentierung Ihres Workloads aus. Wählen Sie eine serviceorientierte Architektur (SOA) oder eine Microservices-Architektur aus. (In seltenen Fällen ist möglicherweise auch eine monolithische Architektur geeignet.) Auch wenn Sie mit einer monolithischen Architektur beginnen möchten, müssen Sie sicherstellen, dass diese modular ist und zu einer SOA oder zu Microservices weiterentwickeln werden kann, wenn Ihr Produkt aufgrund der zunehmenden Einführung durch Benutzer skaliert wird. SOA und Microservices ermöglichen eine kleinteiligere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. Es gibt jedoch auch Nachteile, die besonders bei der Bereitstellung einer Microservice-Architektur berücksichtigt werden sollten. 

 Aufgrund ihrer verteilten Computing-Architektur kann es schwieriger sein, die Latenzanforderungen von Benutzern zu erfüllen. Außerdem sind das Debugging und die Nachverfolgung von Benutzerinteraktionen komplexer. Zur Lösung dieses Problems können Sie AWS X-Ray verwenden. Ein weiterer Effekt ist die erhöhte operative Komplexität, da die Anzahl der von Ihnen verwalteten Anwendungen zunimmt. In der Folge müssen Sie eine größere Zahl voneinander unabhängiger Komponenten bereitstellen. 

![\[Diagramm mit einem Vergleich von monolithischen, serviceorientierten und Microservice-Architekturen\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)


## Implementierungsschritte
<a name="implementation-steps"></a>
+  Ermitteln Sie die richtige Architektur für den Faktorwechsel oder die Entwicklung Ihrer Anwendung. SOA und Microservices bieten eine jeweils kleinere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. SOA kann ein guter Kompromiss für das Erreichen einer kleineren Segmentierung sein, während die Komplexität von Microservices zum Teil vermieden wird. Weitere Informationen finden Sie in [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html). 
+  Wenn Ihre Workload für sie zugänglich ist und Ihre Organisation sie unterstützen kann, sollten Sie eine Microservices-Architektur verwenden, um die beste Agilität und Zuverlässigkeit zu erzielen. Weitere Informationen finden Sie in [Implementieren von Microservices in AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  Sie sollten das Muster mit der Bezeichnung [*Strangler Fig* („Würgefeige“) verwenden,](https://martinfowler.com/bliki/StranglerFigApplication.html) um einen Faktorwechsel für einen Monolithen durchzuführen, bei dem Sie diesen in kleinere Komponenten aufteilen. Dies umfasst die schrittweise Ersetzung spezifischer Anwendungskomponenten durch neue Anwendungen und Services. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) dient als Ausgangspunkt für den inkrementellen Faktorwechsel. Weitere Informationen finden Sie in [Nahtlose Integration ältere On-Premises-Workloads unter Anwendung eines Strangler-Fig-Musters](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/). 
+  Die Implementierung von Microservices erfordert möglicherweise einen Mechanismus für die Entdeckung von Services, damit diese verteilten Services miteinander kommunizieren können. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) kann mit serviceorientierten Architekturen verwendet werden, um eine zuverlässige Erkennung von Services und den Zugriff auf sie zu unterstützen. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) kann für die dynamische, DNS-basierte Serviceerkennung verwendet werden. 
+  Wenn Sie von einem Monolithen zur SOA migrieren, kann [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) helfen, als Service-Bus die Lücke zu überbrücken, wenn Sie ältere Anwendungen in der Cloud neu entwerfen.
+  Im Fall vorhandener Monolithen mit einer einzigen, geteilten Datenbank müssen Sie entscheiden, wie Sie die Daten neu in kleineren Segmenten organisieren. Dabei kann es sich um Geschäftsbereiche, Zugriffsmuster oder Datenstrukturen handeln. An diesem Punkt des Faktorwechsel-Prozesses sollten Sie entscheiden, ob Sie eine relationale oder eine nicht relationale (NoSQL) Datenbank verwenden. Weitere Informationen finden Sie in [Von SQL zu NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html). 

 **Aufwand für den Implementierungsplan:** Hoch 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren](rel_service_architecture_business_domains.md) 

 **Zugehörige Dokumente:** 
+  [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [Was ist eine serviceorientierte Architektur?](https://aws.amazon.com/what-is/service-oriented-architecture/) 
+  [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html) 
+  [Microservices in AWS](https://aws.amazon.com/microservices/) 
+  [Was ist AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 

 **Zugehörige Beispiele:** 
+  [Workshop für die iterative App-Modernisierung](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro) 

 **Zugehörige Videos:** 
+  [Kompetenz mit Microservices in AWS](https://www.youtube.com/watch?v=otADkIyugzY) 

# REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren
<a name="rel_service_architecture_business_domains"></a>

 Eine serviceorientierte Architektur (SOA) entwickelt Services mit genau abgegrenzten Funktionen, die von Geschäftsanforderungen definiert werden. Microservices verwenden Domänenmodelle und begrenzten Kontext, um dies weiter einzuschränken, sodass jeder Service nur eine Aufgabe erledigt. Wenn Sie sich auf bestimmte Funktionen konzentrieren, können Sie die Zuverlässigkeitsanforderungen verschiedener Services differenzieren und Investitionen genauer ausrichten. Ein präzises Geschäftsproblem und ein kleines Team, das mit jedem Service verbunden ist, ermöglichen auch eine einfachere Skalierung der Organisation. 

 Beim Entwerfen einer Microservice-Architektur ist es hilfreich, das Domain-Driven Design (DDD) zu verwenden, um das Geschäftsproblem mithilfe von Entitäten zu modellieren. Für die Website Amazon.com können Entitäten beispielsweise Pakete, Zustellung, Zeitplan, Preise, Rabatte und Währung enthalten. Anschließend wird das Modell mit [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)weiter in kleinere Modelle unterteilt, wobei Entities mit ähnlichen Funktionen und Attributen in Gruppen sortiert werden. Beim Beispiel des Amazon.com-Pakets wären Lieferung und Zeitplan Teil des Versandkontexts, während Preise, Rabatte und Währung Teil des Preiskontexts sind. Wenn das Modell in Kontexte unterteilt ist, entsteht eine Vorlage für die Begrenzung von Microservices. 

![\[Modellvorlage für die Begrenzung von Microservices\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/building-services.png)


 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Entwerfen Sie Ihre Workload basierend auf Ihren Unternehmensdomänen und deren jeweiliger Funktionalität. Wenn Sie sich auf bestimmte Funktionen konzentrieren, können Sie die Zuverlässigkeitsanforderungen verschiedener Services differenzieren und Investitionen genauer ausrichten. Ein präzises Geschäftsproblem und ein kleines Team, das mit jedem Service verbunden ist, ermöglichen auch eine einfachere Skalierung der Organisation. 
  +  Führen Sie eine Domänenanalyse durch, um Ihrer Workload ein domänengesteuertes Design (DDD) zuzuordnen. Anschließend können Sie einen Architekturtyp auswählen, der die Anforderungen Ihrer Workload erfüllt. 
    +  [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
    +  [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
    +  [„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans („Domänengesteuertes Design: Bewältigung der Komplexität im Herzen der Software“)](https://www.amazon.com/gp/product/0321125215) 
    +  [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+ Zerlegen Sie Ihre Services in kleinstmögliche funktionale Einheiten. Mit der Microservices-Architektur können Sie Ihre Workload in Komponenten mit minimaler Funktionalität aufteilen, um Skalierung und Agilität der Organisation zu ermöglichen. 
  +  Definieren Sie die API für die Workload und ihre Designziele, Limits und sonstigen Nutzungsanforderungen. 
    +  Definieren Sie die API. 
      +  Lassen Sie in der API-Definition Raum für Wachstum und weitere Parameter. 
    +  Definieren Sie die gewünschten Verfügbarkeiten. 
      + Sie können für Ihre API mehrere Designziele für unterschiedliche Funktionen haben.
    +  Limits festlegen 
      +  Definieren Sie mithilfe von Tests die Limits Ihrer Workload-Funktionen. 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans („Domänengesteuertes Design: Bewältigung der Komplexität im Herzen der Software“)](https://www.amazon.com/gp/product/0321125215) 
+  [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+  [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html) 
+  [Microservices in AWS](https://aws.amazon.com/microservices/) 

# REL03-BP03 Bereitstellen von Serviceverträgen pro API
<a name="rel_service_architecture_api_contracts"></a>

 Serviceverträge sind dokumentierte Vereinbarungen zur Service-Integration zwischen Teams und enthalten eine maschinenlesbare API-Definition, Ratenlimits und Leistungserwartungen. Eine Versionsverwaltungs-Strategie ermöglicht es Ihren Clients, die vorhandene API weiter zu verwenden und ihre Anwendungen auf die neuere API zu migrieren, wenn sie bereit sind. Die Bereitstellung kann jederzeit erfolgen, solange der Vertrag nicht verletzt wird. Das Serviceanbieterteam kann den Technologie-Stack seiner Wahl verwenden, um den API-Vertrag zu erfüllen. Ebenso kann der Service-Verbraucher seine eigene Technologie verwenden. 

 Microservices nutzen das Konzept einer serviceorientierten Architektur (SOA) und erstellen Services mit minimalem Funktionsumfang. Jeder Service veröffentlicht eine API und Designziele, Limits und andere Überlegungen zur Nutzung des Services. Damit entsteht ein *Vertrag* mit aufrufenden Anwendungen. Dies bietet die folgenden drei Vorteile: 
+  Der Service muss eine Lösung für ein konkretes Geschäftsproblem bieten und verfügt über ein kleines Team, das Eigentümer des Geschäftsproblems ist. Dieser Ansatz ermöglicht eine bessere unternehmerische Skalierung. 
+  Das Team kann jederzeit Bereitstellungen durchführen, solange es seine API- und weitere vertragsbasierte Anforderungen erfüllt. 
+  Das Team kann einen beliebigen Technologie-Stack verwenden, solange es seine API- und weitere vertragsbasierte Anforderungen erfüllt. 

 Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern erleichtert, APIs in jeder Größenordnung zu erstellen, zu veröffentlichen, zu warten, zu überwachen und zu sichern. API Gateway übernimmt alle Aufgaben, die mit der Annahme und Verarbeitung von mitunter Hunderttausenden gleichzeitigen API-Aufrufen verbunden sind. Hierzu zählen die Verwaltung des Datenverkehrs, die Autorisierung, die Zugriffskontrolle, die Überwachung sowie die API-Versionsverwaltung. Mit der OpenAPI-Spezifikation (OAS), früher als Swagger-Spezifikation bezeichnet, können Sie Ihren API-Vertrag definieren und in API Gateway importieren. Mit API Gateway können Sie die APIs versionieren und bereitstellen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Stellen Sie Serviceverträge pro API bereit. Serviceverträge sind dokumentierte Vereinbarungen zur Service-Integration zwischen Teams und enthalten eine maschinenlesbare API-Definition, Ratenlimits und Leistungserwartungen. 
  +  [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
    +  Eine Versioning-Strategie ermöglicht es Clients, die vorhandene API weiter zu verwenden und ihre Anwendungen auf die neuere API zu migrieren, wenn sie bereit sind. 
    +  Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern leicht macht, APIs beliebiger Größe zu erstellen. Mit der OpenAPI-Spezifikation (OAS), früher als Swagger-Spezifikation bezeichnet, können Sie Ihren API-Vertrag definieren und in API Gateway importieren. Mit API Gateway können Sie die APIs versionieren und bereitstellen. 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html) 
+  [Microservices in AWS](https://aws.amazon.com/microservices/) 

# ZUV 4 Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle vermieden werden?
<a name="w2aac19b9b7b7"></a>

Verteilte Systeme nutzen Kommunikationsnetzwerke, um Komponenten wie Server oder Services miteinander zu verbinden. Ihre Workload muss trotz Datenverlust oder höherer Latenz in diesen Netzwerken zuverlässig ausgeführt werden. Komponenten des verteilten Systems müssen so funktionieren, dass sie keine negativen Auswirkungen auf andere Komponenten oder die Workload haben. Diese bewährten Methoden verhindern Ausfälle und verbessern die mittlere Zeit zwischen Ausfällen (MTBF).

**Topics**
+ [REL04-BP01 Bestimmen, welches verteilte System erforderlich ist](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementieren lose gekoppelter Abhängigkeiten](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Konstante Ausführung](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Festlegen aller Reaktionen als idempotent](rel_prevent_interaction_failure_idempotent.md)

# REL04-BP01 Bestimmen, welches verteilte System erforderlich ist
<a name="rel_prevent_interaction_failure_identify"></a>

 Harte verteilte Echtzeitsysteme erfordern synchrone und schnelle Antworten, während bei weichen Echtzeitsystemen ein großzügigeres Zeitfenster von Minuten (oder mehr) für Antworten besteht. Offline-Systeme verarbeiten Antworten über Stapelverarbeitung oder asynchrone Verarbeitung. Harte verteilte Echtzeitsysteme haben die strengsten Zuverlässigkeitsanforderungen. 

 Die schwierigsten [Herausforderungen mit verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) gelten für die harten verteilten Echtzeitsysteme, die auch als Anfrage-/Antwortservices bezeichnet werden. Die Schwierigkeiten entstehen dadurch, dass Anfragen unvorhersehbar eingehen und schnelle Antworten ausgegeben werden müssen (z. B. weil der Kunde aktiv auf die Antwort wartet). Beispiele sind Frontend-Webserver, die Auftragspipeline, Kreditkartentransaktionen, jede AWS-API und Telefonie. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Bestimmen Sie, welches verteilte System erforderlich ist. Zu den Herausforderungen verteilter Systeme gehörten die Latenz, die Skalierung, das Verständnis von Netzwerk-APIs, das Marshalling und Unmarshalling von Daten sowie die Komplexität von Algorithmen wie Paxos. Angesichts des zunehmenden Wachstums und Verteilungsgrads von Systemen werden theoretische Edge-Fälle zu regelmäßigen Ereignissen. 
  +  [Die Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
    +  In Echtzeit verteilte Systeme erfordern synchrone und schnelle Antworten. 
    +  Bei weichen Echtzeitsystemen besteht ein großzügigeres Zeitfenster von Minuten (oder mehr) für Antworten. 
    +  Offline-Systeme verarbeiten Antworten über Stapelverarbeitung oder asynchrone Verarbeitung. 
    +  Harte verteilte Echtzeitsysteme haben die strengsten Zuverlässigkeitsanforderungen. 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [Die Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+  [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Was ist Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 

 **Relevante Videos:** 
+  [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E) 

# REL04-BP02 Implementieren lose gekoppelter Abhängigkeiten
<a name="rel_prevent_interaction_failure_loosely_coupled_system"></a>

 Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität. 

 Wenn Änderungen an einer Komponente bewirken, dass andere abhängige Komponenten ebenfalls geändert werden, sind sie *eng* gekoppelt. *Die lose* Kopplung unterbricht diese Abhängigkeit, sodass abhängige Komponenten nur die versionierte und veröffentlichte Schnittstelle kennen müssen. Die Implementierung einer losen Kopplung zwischen Abhängigkeiten isoliert einen Ausfall. So wird verhindert, dass er sich auf andere Komponenten auswirkt. 

 Die lose Kopplung ermöglicht Ihnen, einer Komponente zusätzlichen Code oder Funktionen hinzuzufügen und gleichzeitig das Risiko für Komponenten zu minimieren, die von ihr abhängig sind. Außerdem wird die Skalierbarkeit verbessert, da Sie die zugrunde liegende Implementierung der Abhängigkeit aufskalieren oder sogar ändern können. 

 Um die Ausfallsicherheit durch lose Kopplung weiter zu verbessern, legen Sie Komponenten-Interaktionen nach Möglichkeit als asynchron fest. Dieses Modell eignet sich für jede Interaktion, bei der keine sofortige Antwort benötigt wird, sondern die Bestätigung ausreicht, dass eine Anfrage registriert wurde. Es umfasst eine Komponente, die Ereignisse generiert, und eine andere Komponente, die sie konsumiert. Die beiden Komponenten lassen sich nicht durch direkte Punkt-zu-Punkt-Interaktion integrieren, sondern in der Regel über eine temporäre, robuste Speicherschicht, z. B. eine SQS-Warteschlange oder eine Streaming-Datenplattform wie Amazon Kinesis oder AWS Step Functions. 

![\[Diagramm: Abhängigkeiten etwa zwischen Warteschlangensystemen und Load Balancer sind lose gekoppelt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)


 Amazon SQS-Warteschlangen und Elastic Load Balancers sind nur zwei Möglichkeiten, um eine Zwischenschicht für lose Kopplung hinzuzufügen. Ereignisgesteuerte Architekturen können auch in der AWS Cloud mithilfe von Amazon EventBridge erstellt werden, was Clients (Ereignisproduzenten) von den Services abstrahieren kann, auf die sie sich verlassen (Ereignisverbraucher). Amazon Simple Notification Service (Amazon SNS) ist eine effektive Lösung, wenn Sie Push-basiertes M-zu-N-Messaging mit hohem Durchsatz benötigen. Mithilfe von Amazon SNS-Themen können Ihre Publisher-Systeme Nachrichten zur parallelen Verarbeitung an eine große Anzahl von Abonnenten-Endpunkten senden. 

 Warteschlangen bieten zwar mehrere Vorteile, doch Anfragen, die älter als ein Schwellenwert sind (oft Sekunden), sollten in den meisten harten Echtzeitsystemen als veraltet betrachtet (der Client hat aufgegeben und wartet nicht mehr auf eine Antwort) und nicht verarbeitet werden. Auf diese Weise können stattdessen neuere (und wahrscheinlich noch gültige Anfragen) verarbeitet werden. 

 **Gängige Antimuster:** 
+  Bereitstellen eines Singletons im Rahmen einer Workload. 
+  APIs werden zwischen Workload-Ebenen direkt aufgerufen, ohne Möglichkeit eines Failovers oder einer asynchronen Verarbeitung der Anfrage. 

 **Vorteile der Einführung dieser bewährten Methode:** Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität. Fehler in einer Komponente sind von anderen isoliert. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Implementieren Sie lose gekoppelte Abhängigkeiten. Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität. 
  +  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
  +  [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
  +  [Was ist Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 
    +  Mit Amazon EventBridge können Sie ereignisgesteuerte Architekturen entwickeln, die lose verkoppelt und verteilt sind. 
      +  [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
    +  Wenn Änderungen für eine Komponente Änderungen für andere Komponenten auslöst, die von ihr abhängig sind, sind sie eng verkoppelt. Die lose Kopplung hebt diese Abhängigkeit auf, sodass abhängige Komponenten nur die versionierte und veröffentlichte Schnittstelle kennen müssen. 
    +  Gestalten Sie die Interaktionen zwischen Komponenten möglichst als asynchrone Interaktionen. Dieses Modell ist für Interaktionen geeignet, die keine sofortigen Reaktionen erfordern und für die die Bestätigung der Registrierung einer Anfrage ausreichend ist. 
      +  [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304) (Skalierbare serverlose ereignisgesteuerte Anwendungen, die Amazon SQS und Lambda nutzen)](https://youtu.be/2rikdPIFc_Q) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [Die Amazon Builders' Library: Herausforderungen für verteilte Systeme](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+  [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Was ist Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 

 **Relevante Videos:** 
+  [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E) 
+  [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304) (Skalierbare serverlose ereignisgesteuerte Anwendungen, die Amazon SQS und Lambda nutzen)](https://youtu.be/2rikdPIFc_Q) 

# REL04-BP03 Konstante Ausführung
<a name="rel_prevent_interaction_failure_constant_work"></a>

 Bei größeren, schnellen Lastveränderungen können Systeme ausfallen. Wenn Ihre Workload beispielsweise eine Zustandsprüfung ausführt, die den Zustand vieler tausend Server überwacht, sollte sie jedes Mal die gleiche Nutzlast senden (einen vollständigen Snapshot des aktuellen Status). Unabhängig davon, ob keine Server oder alle Server ausfallen, führt das System für die Zustandsprüfung die Aufgaben stetig und ohne große, schnelle Änderungen aus. 

 Wenn das Zustandsprüfungssystem beispielsweise 100 000 Server überwacht, ist die Last darauf angesichts der normalerweise geringen Serverausfallrate nominal. Wenn jedoch ein großes Ereignis die Hälfte dieser Server fehlerhaft macht, wäre das Zustandsprüfungssystem überfordert, wenn es versucht, Benachrichtigungssysteme zu aktualisieren und den Status an seine Clients zu kommunizieren. Stattdessen sollte das Zustandsprüfungssystem jedes Mal den vollständigen Snapshot des aktuellen Status senden. 100 000 Server-Zustände, die jeweils durch ein Bit dargestellt werden, entsprächen nur eine Nutzlast von 12,5 KB. Unabhängig davon, ob keine oder alle Server ausfallen – das System für die Zustandsprüfung erledigt seine Arbeit konstant und große, schnelle Änderungen stellen keine Bedrohung für die Systemstabilität dar. Auf diese Weise führt Amazon Route 53 Zustandsprüfungen für Endpunkte (wie z. B. IP-Adressen) durch, um zu ermitteln, wie Endbenutzer an diese weitergeleitet werden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Führen Sie Aufgaben konstant aus, sodass auch bei großen, schnellen Lastveränderungen keine Fehler auf Systemen auftreten. 
+  Implementieren Sie lose gekoppelte Abhängigkeiten. Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität. 
  +  [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
  +  [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über große und kleine Systeme übernimmt ARC337 (umfasst konstante Ausführung)](https://youtu.be/O8xLxNje30M?t=2482) 
    +  Beispiel: Zustandsprüfungssystem, das 100.000 Server überwacht: Entwickeln Sie die Workloads so, dass die Nutzlastgrößen unabhängig von der Anzahl der Erfolge oder Ausfälle konstant bleiben. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [Die Amazon Builders' Library: Herausforderungen für verteilte Systeme](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 

 **Ähnliche Videos:** 
+  [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über große und kleine Systeme übernimmt ARC337 (umfasst konstante Ausführung)](https://youtu.be/O8xLxNje30M?t=2482) 
+  [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E) 

# REL04-BP04 Festlegen aller Reaktionen als idempotent
<a name="rel_prevent_interaction_failure_idempotent"></a>

 Ein idempotenter Service garantiert, dass jede Anfrage genau einmal abgeschlossen wird. Das bedeutet, dass das Senden mehrerer identischer Anfragen den gleichen Effekt hat wie das Senden einer einzelnen Anfrage. Ein idempotenter Service erleichtert es einem Client, Wiederholungen zu implementieren. So muss nicht befürchtet werden, dass eine Anfrage fälschlicherweise mehrfach verarbeitet wird. Zu diesem Zweck können Clients API-Anfragen mit einem Idempotenz-Token ausgeben. Das gleiche Token wird verwendet, wenn die Anfrage wiederholt wird. Eine idempotente Service-API gibt mithilfe des Tokens eine Antwort zurück, die identisch mit der Antwort ist, die beim ersten Abschluss der Anfrage zurückgegeben wurde. 

 In einem verteilten System ist es einfach, eine Aktion höchstens einmal (der Client stellt nur eine Anforderung) oder mindestens einmal (Anforderung so lange, bis der Client erfolgreich ist) durchzuführen. Es ist jedoch schwer zu gewährleisten, dass eine Aktion idempotent ist, was bedeutet, dass sie *genau* einmal ausgeführt wird, sodass das Erstellen mehrerer identischer Anfragen den gleichen Effekt hat wie das Erstellen einer einzelnen Anfrage. Durch die Verwendung von idempotenten Tokens in APIs können Services einmal oder mehrmals eine sich verändernde Anfrage erhalten, ohne dass doppelte Datensätze erstellt werden oder sonstige Probleme entstehen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Legen Sie alle Reaktionen als idempotent fest. Ein idempotenter Service garantiert, dass jede Anfrage genau einmal abgeschlossen wird. Das bedeutet, dass das Senden mehrerer identischer Anfragen den gleichen Effekt hat wie das Senden einer einzelnen Anfrage. 
  +  Clients können API-Anfragen mit einem Idempotenz-Token ausgeben. Das gleiche Token wird bei einer Wiederholung der Anfrage verwendet. Eine idempotente Service-API gibt mithilfe des Tokens eine Antwort zurück, die identisch mit der Antwort ist, die beim ersten Abschluss der Anfrage zurückgegeben wurde. 
    +  [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [Die Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 

 **Ähnliche Videos:** 
+  [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E) 

# ZUV 5 Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle abgemildert oder bewältigt werden?
<a name="w2aac19b9b7b9"></a>

Verteilte Systeme nutzen Kommunikationsnetzwerke, um Komponenten (wie Server oder Services) miteinander zu verbinden. Ihre Workload muss trotz Datenverlust oder höherer Latenz in diesen Netzwerken zuverlässig ausgeführt werden. Komponenten des verteilten Systems müssen so funktionieren, dass sie keine negativen Auswirkungen auf andere Komponenten oder die Workload haben. Mit den folgenden bewährten Methoden können Workloads Belastungen oder Ausfällen standhalten, schneller wiederhergestellt werden und die Auswirkungen solcher Beeinträchtigungen verringern. Das Ergebnis ist eine verbesserte mittlere Reparaturzeit (MTTR).

**Topics**
+ [REL05-BP01 Implementieren einer ordnungsgemäßen Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Drosselung von Anfragen](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Steuern und Einschränken von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Schnelles Scheitern und Begrenzen von Warteschlangen](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Festlegen von Client-Zeitüberschreitungen](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Erstellen zustandsloser Anwendungen](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementieren von Nothebeln](rel_mitigate_interaction_failure_emergency_levers.md)

# REL05-BP01 Implementieren einer ordnungsgemäßen Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern
<a name="rel_mitigate_interaction_failure_graceful_degradation"></a>

 Wenn die Abhängigkeiten einer Komponente fehlerhaft sind, kann die Komponente selbst weiterhin funktionieren, wenn auch in eingeschränkter Weise. Wenn beispielsweise ein Abhängigkeitsaufruf fehlschlägt, erfolgt ein Failover auf eine vordefinierte statische Antwort. 

 Ziehen Sie einen Service B in Betracht, der von Service A aufgerufen wird und wiederum Service C aufruft. 

![\[Diagramm: Service C schlägt fehl, wenn er von Service B aufgerufen wird. Service B gibt eine schlechtere Antwort an Service A zurück.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)


 Wenn Service B Service C aufruft, hat er eine Fehlermeldung oder eine Zeitüberschreitung von ihm erhalten. Service B gibt ohne Antwort von Service C (und den darin enthaltenen Daten) stattdessen zurück, was möglich ist. Dies kann der letzte zwischengespeicherte Wert sein oder Service B kann eine vordefinierte statische Antwort für den Wert ersetzen, den er von Service C erhalten hätte. Er kann dann eine verminderte Antwort an seinen Aufrufer, Service A zurückgeben. Ohne diese statische Antwort würde der Fehler in Service C durch Service B zu Service A kaskadieren, was zu einem Verlust der Verfügbarkeit führt. 

 Gemäß dem multiplikativen Faktor in der Verfügbarkeitsgleichung für harte Abhängigkeiten (siehe [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)) wirkt sich jeder Rückgang der Verfügbarkeit von C erheblich auf die effektive Verfügbarkeit von B aus. Durch die Rückgabe des statischen Antwortservice B wird der Fehler in C verringert und lässt die Verfügbarkeit von Service C wie eine hundertprozentige Verfügbarkeit aussehen (vorausgesetzt, dass er die statische Antwort unter Fehlerbedingungen zuverlässig zurückgibt). Beachten Sie, dass die statische Antwort eine einfache Alternative zur Rückgabe eines Fehlers darstellt und kein Versuch ist, die Antwort mit anderen Mitteln neu zu berechnen. Solche Versuche mit einem völlig anderen Mechanismus, um dasselbe Ergebnis zu erzielen, werden als Fallback-Verhalten bezeichnet und sind ein zu vermeidendes Antimuster. 

 Ein weiteres Beispiel für eine ordnungsgemäße Verschlechterung ist der *Schaltkreisunterbrecher*. Wiederholungsstrategien sollten verwendet werden, wenn der Fehler vorübergehend ist. Wenn dies nicht der Fall ist und der Vorgang wahrscheinlich fehlschlägt, verhindert der Unterbrecher, dass der Client eine Anfrage ausführt, die wahrscheinlich fehlschlägt. Wenn die Anfragen normal verarbeitet werden, wird der Unterbrecher geschlossen, und die Anfragen laufen durch. Wenn das Remote-System Fehler zurückgibt oder eine hohe Latenz aufweist, wird der Unterbrecher geöffnet und die Abhängigkeit wird ignoriert oder die Ergebnisse werden durch einfachere aber weniger umfassende Antworten ersetzt (was einfach ein Antwort-Cache sein kann). Das System versucht regelmäßig, die Abhängigkeit aufzurufen, um zu ermitteln, ob sie wiederhergestellt wurde. In diesem Fall wird der Unterbrecher geschlossen. 

![\[Diagramm: Schutzschalter im offenen und geschlossenen Zustand\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)


 Zusätzlich zu den im Diagramm gezeigten Zuständen "Geschlossen" und "Offen" kann der Unterbrecher nach einem konfigurierbaren Zeitraum im offenen Zustand in "Halboffen" übergehen. In diesem Zustand versucht er in regelmäßigen Abständen, den Service mit einer viel geringeren Rate als normal aufzurufen. Auf diese Weise wird der Zustand des Service überprüft. Nach einigen Erfolgen im halb geöffneten Zustand wechselt der Unterbrecher zu "closed" und die Anfragen werden normal fortgesetzt. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Implementieren Sie eine ordnungsgemäße Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern. Wenn die Abhängigkeiten einer Komponente fehlerhaft sind, kann die Komponente selbst weiterhin funktionieren, wenn auch in eingeschränkter Weise. Wenn beispielsweise ein Abhängigkeitsaufruf fehlschlägt, erfolgt ein Failover auf eine vordefinierte statische Antwort. 
  +  Durch Rückgabe einer statischen Antwort grenzt die Workload Fehler in ihren Abhängigkeiten ein. 
    +  [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) 
  +  Erkennen Sie, wann eine Wiederholungsoperation wahrscheinlich fehlschlägt, und verhindern Sie mit dem Unterbrecher die Wiederholung fehlgeschlagener Aufrufe durch den Client. 
    +  [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [CircuitBreaker (Zusammenfassung des Circuit Breaker aus dem Buch „Release It\$1“)](https://martinfowler.com/bliki/CircuitBreaker.html) 
+  [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Michael Nygard, „Release It\$1“ Design and Deploy Production-Ready Software“](https://pragprog.com/titles/mnee2/release-it-second-edition/) 
+  [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Relevante Videos:** 
+  [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **Ä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) 

# REL05-BP02 Drosselung von Anfragen
<a name="rel_mitigate_interaction_failure_throttle_requests"></a>

 Die Drosselung von Anfragen ist ein Abschwächungsmuster, um auf einen unerwarteten Anstieg der Nachfrage zu reagieren. Einige Anfragen werden berücksichtigt, doch solche, die über ein definiertes Limit hinausgehen, werden abgelehnt. Zudem wird eine entsprechende Meldung über deren Drosselung zurückgegeben. Dabei wird erwartet, dass Clients die Anfragen abbrechen oder es mit einer langsameren Rate erneut versuchen. 

 Ihre Services sollten so konzipiert werden, dass jeder Knoten und jede Zelle eine bekannte Anzahl von Anfragen verarbeiten kann. Diese Kapazität kann mit Lasttests erreicht werden. Anschließend müssen Sie die Eingangsrate von Anfragen verfolgen, und wenn die vorübergehende Eingangsrate dieses Limit überschreitet, muss aus der entsprechenden Antwort hervorgehen, dass die Anfrage gedrosselt wurde. Damit kann der Benutzer es bei einem anderen Knoten oder einer anderen Zelle, der/die ggf. über Kapazität verfügt, erneut versuchen. Amazon API Gateway bietet Methoden zum Drosseln von Anfragen. Amazon SQS und Amazon Kinesis können Anfragen puffern, die Anfragerate glätten und die Notwendigkeit einer Drosselung für asynchrone Anfragen verringern. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Drosseln Sie Anfragen. Hierbei handelt es sich um ein Abmilderungsmuster, mit dem auf einen unerwarteten Anstieg der Nachfrage reagiert werden kann. Einige Anfragen werden berücksichtigt, doch solche, die über ein definiertes Limit hinausgehen, werden abgelehnt. Zudem wird eine entsprechende Meldung über deren Drosselung zurückgegeben. Dabei wird erwartet, dass Clients die Anfragen abbrechen oder es mit einer langsameren Rate erneut versuchen. 
  +  Nutzen Sie Amazon API Gateway 
    +  [Drosseln Sie API-Anfragen, um einen höheren Durchsatz zu erzielen.](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+  [Drosseln Sie API-Anfragen, um einen höheren Durchsatz zu erzielen.](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 

 **Relevante Videos:** 
+  [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

# REL05-BP03 Steuern und Einschränken von Wiederholungsaufrufen
<a name="rel_mitigate_interaction_failure_limit_retries"></a>

 Verwenden Sie ein exponentielles Backoff, um Aufrufe nach zunehmend längeren Intervallen zu wiederholen. Nutzen Sie Jitter, um die Wiederholungsintervalle zu randomisieren, und legen Sie ein Limit für die Zahl der Wiederholungen fest. 

 Typische Komponenten in einem verteilten Softwaresystem sind Server, Load Balancer, Datenbanken und DNS-Server. Im Betrieb und bei Ausfällen kann jede dieser Komponenten mit dem Generieren von Fehlern beginnen. Die Standardmethode für den Umgang mit Fehlern besteht darin, Wiederholungen auf Clientseite zu implementieren. Diese Methode erhöht die Zuverlässigkeit und Verfügbarkeit der Anwendung. In großem Umfang – und wenn Clients versuchen, den fehlgeschlagenen Vorgang zu wiederholen, sobald ein Fehler auftritt – kann das Netzwerk schnell mit neuen und nicht mehr aktiven Anfragen überfordert werden, wobei jede Anfrage um die Netzwerkbandbreite konkurriert. Dies kann zu einer *Wiederholungsflut* führen, die die Verfügbarkeit des Service reduziert. Dieses Muster setzt sich möglicherweise fort, bis ein vollständiger Systemausfall auftritt. 

 Um solche Szenarien zu vermeiden, sollten Backoff-Algorithmen wie das gängige *exponentielle Backoff* verwendet werden. Algorithmen für exponentielles Backoff verringern schrittweise die Rate, mit der Wiederholungen durchgeführt werden, und verhindern dadurch Netzwerküberlastungen. 

 Viele SDKs und Softwarebibliotheken, auch die von AWS, implementieren eine Version dieser Algorithmen. Sie sollten jedoch **nie davon ausgehen, dass ein Backoff-Algorithmus vorhanden ist. Dies muss stets im Voraus getestet und überprüft werden.** 

 Ein einfaches Backoff alleine reicht nicht aus, da in verteilten Systemen alle Clients gleichzeitig einen Backoff durchführen und Anhäufungen von Wiederholungsaufrufen erstellen können. Marc Brooker erklärt in seinem Blogbeitrag [Exponentielles Backoff und Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), wie die Funktion „wait()“ im exponentiellen Backoff geändert werden kann, um Wiederholungsaufruf-Cluster zu verhindern. Die Lösung besteht darin, *Jitter* der Funktion „wait()“ hinzuzufügen. Um einen zu langen Wiederholungsversuch zu vermeiden, sollten Implementierungen das Backoff auf einen maximalen Wert begrenzen. 

 Schließlich ist es wichtig, eine *maximale Anzahl von Wiederholungen* oder die verstrichene Zeit zu konfigurieren, nach der Wiederholversuche einfach fehlschlagen. AWS SDKs implementieren dies als konfigurierbaren Standard. Für Services, die sich weiter unten im Stack befinden, kann ein maximales Wiederholungslimit von null oder eins das Risiko begrenzen und ist dennoch wirksam, da Wiederholungen an Services delegiert werden, die sich höher im Stack befinden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Steuern und begrenzen Sie Wiederholungsaufrufe. Verwenden Sie ein exponentielles Backoff, um Aufrufe nach zunehmend längeren Intervallen zu wiederholen. Nutzen Sie Jitter, um die Wiederholungsintervalle zu randomisieren, und legen Sie ein Limit für die Zahl der Wiederholungen fest. 
  +  [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
    + Mit Amazon SKDs werden Wiederholungen und exponentielles Backoff standardmäßig implementiert. Implementieren Sie in die Abhängigkeitsebene zum Aufrufen Ihrer eigenen abhängigen Services eine ähnliche Logik. Legen Sie entsprechend Ihrem Anwendungsfall Zeitüberschreitungen fest und geben Sie an, wann Wiederholversuche gestoppt werden sollen.

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Relevante Videos:** 
+  [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

# REL05-BP04 Schnelles Scheitern und Begrenzen von Warteschlangen
<a name="rel_mitigate_interaction_failure_fail_fast"></a>

 Wenn eine Workload auf eine Anfrage nicht erfolgreich antworten kann, sollte sie per Fail-Fast beendet werden. So können Ressourcen freigegeben werden, die einer Anfrage zugeordnet sind, und der Service kann entlastet werden, wenn die Ressourcen zur Neige gehen. Wenn die Workload erfolgreich antworten kann, aber die Rate der Anfragen zu hoch ist, sollten Sie die Anfragen mithilfe einer Warteschlange puffern. Lassen Sie jedoch keine langen Warteschlangen zu. Sie können dazu führen, dass veraltete Anfragen verarbeitet werden, die der Client bereits aufgegeben hat. 

 Diese bewährte Methode gilt für den Server oder den Empfänger der Anfrage. 

 Beachten Sie, dass Warteschlangen auf mehreren Ebenen eines Systems erstellt werden können und die Möglichkeit einer schnellen Wiederherstellung möglicherweise erheblich beeinträchtigt wird, da ältere veraltete Anfragen (die keine Antwort mehr benötigen) vor neueren Anfragen verarbeitet werden. Machen Sie sich mit den Orten vertraut, an denen Warteschlangen vorhanden sind. Sie verbergen sich häufig in Workflows oder in Daten, die in einer Datenbank aufgezeichnet werden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Implementieren Sie schnelles Scheitern und begrenzen Sie Warteschlangen. Wenn eine Workload auf eine Anfrage nicht erfolgreich antworten kann, sollte sie per schnellem Scheitern beendet werden. So können Ressourcen freigegeben werden, die einer Anfrage zugeordnet sind, und der Service kann entlastet werden, wenn die Ressourcen zur Neige gehen. Wenn die Workload erfolgreich antworten kann, aber die Rate der Anfragen zu hoch ist, sollten Sie die Anfragen mithilfe einer Warteschlange puffern. Lassen Sie jedoch keine langen Warteschlangen zu. Sie können dazu führen, dass veraltete Anfragen verarbeitet werden, die der Client bereits aufgegeben hat. 
  +  Implementieren Sie schnelles Scheitern bei hoher Belastung eines Service. 
    +  [Schnell scheitern](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) 
  +  Begrenzen Sie Warteschlagen. Wenn in einem warteschlangenbasierten System die Verarbeitung gestoppt wird, aber weiterhin Nachrichten eintreffen, kann ein großer Rückstand an unverarbeiteten Nachrichten entstehen, was die Verarbeitungszeit erhöht. Die Verarbeitung kann so spät abgeschlossen werden, dass die Ergebnisse nicht mehr nützlich sind. Dies führt zur Beeinträchtigung der Verfügbarkeit, die mit der Warteschlange eigentlich aufrecht erhalten werden sollte. 
    +  [Die Amazon Builders' Library: Vermeiden von nicht mehr aufzuholenden Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Schnell scheitern](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) 
+  [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Ähnliche Videos:** 
+  [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

# REL05-BP05 Festlegen von Client-Zeitüberschreitungen
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

 Legen Sie Zeitbeschränkungen entsprechend fest, überprüfen Sie sie systematisch und verlassen Sie sich nicht auf Standardwerte, da diese in der Regel zu hoch eingestellt sind. 

 Diese bewährte Methode gilt für den Client oder den Absender der Anfrage. 

 Legen Sie sowohl eine Zeitbeschränkung für Verbindungen als auch eine für Anforderungen für jeden Remote-Aufruf und in der Regel für jeden Prozess-übergreifenden Aufruf fest. Viele Frameworks bieten integrierte Zeitbeschränkungsfunktionen, deren Standardwerte jedoch oft unendlich oder zu hoch sind. Ein zu hoher Wert reduziert die Nützlichkeit der Zeitbeschränkung, da Ressourcen weiterhin verbraucht werden, während der Client auf das Einsetzen der Zeitbeschränkung wartet. Ein zu niedriger Wert kann zu erhöhtem Datenverkehr im Backend und zu erhöhter Latenz führen, da zu viele Anfragen wiederholt werden. In einigen Fällen kann dies zu vollständigen Ausfällen führen, da alle Anfragen wiederholt werden. 

 Weitere Informationen dazu, wie Amazon Zeitüberschreitungen, Wiederholungen und Backoff mit Jitter verwendet, finden Sie in der [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card). 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Legen Sie sowohl eine Zeitbeschränkung für Verbindungen als auch eine für Anforderungen für jeden Remote-Aufruf und in der Regel für jeden Prozess-übergreifenden Aufruf fest. Viele Frameworks bieten integrierte Zeitbeschränkungsfunktionen, deren Standardwerte jedoch oft unendlich oder zu hoch sind. Ein zu hoher Wert reduziert die Nützlichkeit der Zeitbeschränkung, da Ressourcen weiterhin verbraucht werden, während der Client auf das Einsetzen der Zeitbeschränkung wartet. Ein zu niedriger Wert kann zu erhöhtem Datenverkehr im Backend und zu erhöhter Latenz führen, da zu viele Anfragen wiederholt werden. In einigen Fällen kann dies zu vollständigen Ausfällen führen, da alle Anfragen wiederholt werden. 
  +  [AWS SDK: Wiederholungen und Zeitüberschreitungen](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [AWS SDK: Wiederholungen und Zeitüberschreitungen](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Relevante Videos:** 
+  [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

# REL05-BP06 Erstellen zustandsloser Anwendungen
<a name="rel_mitigate_interaction_failure_stateless"></a>

 Services sollten entweder keinen Zustand erfordern oder ihn so auslagern, dass zwischen verschiedenen Client-Anfragen keine Abhängigkeit von lokal gespeicherten Daten auf der Festplatte und im Arbeitsspeicher besteht. Auf diese Weise können Server nach Belieben ersetzt werden, ohne dass dies Auswirkungen auf die Verfügbarkeit hat. Amazon ElastiCache oder Amazon DynamoDB sind gute Ziele für den ausgelagerte Zustand. 

![\[In dieser zustandslosen Webanwendung wird der Sitzungsstatus in Amazon ElastiCache ausgelagert.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)


 Wenn Benutzer oder Services mit einer Anwendung interagieren, führen sie häufig eine Reihe von Interaktionen aus, die eine Sitzung bilden. Bei einer Sitzung handelt es sich um eindeutige Daten für Benutzer, die zwischen Anfragen bestehen bleiben, während sie die Anwendung verwenden. Eine zustandslose Anwendung ist eine Anwendung, die keine Informationen zu früheren Interaktionen benötigt und keine Sitzungsinformationen speichert. 

 Sobald eine Anwendung als zustandslos entwickelt wurde, können Sie serverlose Compute-Services wie AWS Lambda oder AWS Fargate verwenden. 

 Neben dem Serverersatz besteht ein weiterer Vorteil zustandsloser Anwendungen darin, dass sie horizontal skaliert werden können, da alle verfügbaren Compute-Ressourcen (z. B. EC2-Instances und AWS Lambda-Funktionen) jede Anfrage bearbeiten können. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Erstellen Sie zustandslose Anwendungen. Zustandslose Anwendungen ermöglichen eine horizontale Skalierung und sind gegenüber dem Ausfall eines einzelnen Knotens tolerant. 
  +  Entfernen Sie Zustände, die tatsächlich in Anfrageparametern gespeichert werden können. 
  +  Nachdem Sie untersucht haben, ob der Zustand erforderlich ist, verschieben Sie die gesamte Zustandsverfolgung in einen ausfallsicheren Multizonen-Cache oder Datenspeicher wie Amazon ElastiCache, Amazon RDS, Amazon DynamoDB oder in die verteilte Datenlösung eines Drittanbieters. Speichern Sie nicht verlagerbare Zustände in ausfallsicheren Datenspeichern. 
    +  Manche Daten (wie Cookies) können in Headern oder Abfrageparametern übergeben werden. 
    +  Entfernen Sie Zustände, die sich schnell in Anfragen übergeben lassen. 
    +  Einige Daten sind möglicherweise nicht für jede Anfrage erforderlich, sondern können bei Bedarf abgerufen werden. 
    +  Entfernen Sie asynchron abrufbare Daten. 
    +  Wählen Sie einen Datenspeicher, der die Anforderungen eines erforderlichen Zustands erfüllt. 
    +  Ziehen Sie für nichtrelationale Daten eine NoSQL-Datenbank in Erwägung. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 

# REL05-BP07 Implementieren von Nothebeln
<a name="rel_mitigate_interaction_failure_emergency_levers"></a>

 Nothebel sind schnelle Prozesse, die die Auswirkungen auf die Verfügbarkeit Ihrer Workload mindern können. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Implementieren von Nothebeln. Hierbei handelt es sich um schnelle Prozesse, die die Auswirkungen auf die Verfügbarkeit Ihrer Workload mindern können. Sie können ausgeführt werden, wenn keine Ursache vorliegt. Ein idealer Nothebel reduziert die kognitive Belastung der Resolver auf null, indem er vollständig deterministische Aktivierungs- und Deaktivierungskriterien bereitstellt. Hebel müssen oft manuell ausgeführt werden, können aber auch automatisiert werden. 
  +  Beispiele für Nothebel: 
    +  Blockieren des gesamten Roboterdatenverkehrs 
    +  Anbieten von statischen Seiten anstelle von dynamischen Seiten 
    +  Reduzieren der Häufigkeit von Aufrufen für eine Abhängigkeit 
    +  Drosselung der Aufrufe von Abhängigkeiten 
  +  Tipps zur Implementierung und Verwendung von Nothebeln 
    +  Wenn die Hebel aktiviert sind, sollten Sie WENIGER machen, nicht mehr. 
    +  Halten Sie die Dinge einfach, vermeiden Sie bimodales Verhalten. 
    +  Testen Sie die Hebel regelmäßig. 
  +  Nachfolgend finden Sie Beispiele für Aktionen, die KEINE Nothebel sind: 
    +  Kapazität hinzufügen 
    +  Servicebesitzer von Clients anrufen, die von Ihrem Service abhängig sind, und sie bitten, Aufrufe zu reduzieren 
    +  Code ändern und freigeben 

# Änderungsverwaltung
<a name="a-change-management"></a>

**Topics**
+ [ZUV 6 Was ist bei der Überwachung von Workload-Ressourcen zu beachten?](w2aac19b9b9b5.md)
+ [ZUV 7 Wie lässt sich der Workload so gestalten, dass er sich an Bedarfsänderungen anpasst?](w2aac19b9b9b7.md)
+ [ZUV 8 Wie implementieren Sie Änderungen?](w2aac19b9b9b9.md)

# ZUV 6 Was ist bei der Überwachung von Workload-Ressourcen zu beachten?
<a name="w2aac19b9b9b5"></a>

Protokolle und Metriken sind wertvolle Tools, um einen Einblick in den Zustand Ihrer Workloads zu gewinnen. Sie können Ihre Workload so konfigurieren, dass Protokolle und Metriken überwacht und bei Über- oder Unterschreiten von Schwellenwerten oder wichtigen Ereignissen Benachrichtigungen gesendet werden. Dank der Überwachung kann die Workload erkennen, wenn Schwellenwerte für eine niedrige Leistung unterschritten werden oder Ausfälle auftreten, sodass als Reaktion drauf eine automatische Wiederherstellung erfolgen kann.

**Topics**
+ [REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatisieren von Antworten (Verarbeitung und Benachrichtigung in Echtzeit)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Analysen](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Regelmäßiges Durchführen von Prüfungen](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System](rel_monitor_aws_resources_end_to_end.md)

# REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)
<a name="rel_monitor_aws_resources_monitor_resources"></a>

 Überwachen Sie die Komponenten der Workload mit Amazon CloudWatch oder Tools von Drittanbietern. Überwachen Sie AWS-Services mit dem AWS Health Dashboard. 

 Alle Komponenten Ihrer Workload sollten überwacht werden, einschließlich Frontend, Geschäftslogik und Speicherstufen. Definieren Sie Schlüsselmetriken, beschreiben Sie, wie Sie diese gegebenenfalls aus Protokollen extrahieren, und legen Sie Schwellenwerte für das Auslösen entsprechender Alarmereignisse fest. Stellen Sie sicher, dass die Metriken für die wichtigen Leistungskennzahlen (KPIs) Ihrer Workload relevant sind und verwenden Sie Metriken und Protokolle, um frühe Warnzeichen einer Serviceverschlechterung zu identifizieren. Beispielsweise kann eine mit Geschäftsergebnissen zusammenhängende Metrik wie etwa die Anzahl der pro Minute erfolgreich verarbeiteten Bestellungen schneller auf Workload-Probleme hinweisen als eine technische Metrik wie etwa die CPU-Auslastung. Verwenden Sie das AWS Health Dashboard für eine personalisierte Ansicht der Leistung und Verfügbarkeit der AWS-Services, die Ihren AWS-Ressourcen zugrunde liegen. 

 Die Überwachung in der Cloud bietet neue Möglichkeiten. Die meisten Cloudanbieter haben anpassbare Hooks entwickelt und können Einblicke liefern, mit denen Sie mehrere Ebenen Ihrer Workload überwachen können. AWS-Services wie Amazon CloudWatch wenden statistische und Machine-Learning-Algorithmen an, um Metriken von Systemen und Anwendungen kontinuierlich zu analysieren, normale Basiswerte zu erkennen und Oberflächenanomalien anhand eines minimalen Benutzereingriffs aufzudecken. Algorithmen zur Erkennung von Anomalien berücksichtigen saisonale Schwankungen und Trendänderungen von Metriken. 

 AWS stellt zahlreiche Überwachungs- und Protokollinformationen bereit, die genutzt werden können, um workload-spezifische Metriken und Bedarfsänderungsprozesse zu definieren und Machine-Learning-Verfahren unabhängig von der ML-Erfahrung einzuführen. 

 Zudem können Sie auch all Ihre externen Endpunkte überwachen, um sicherzustellen, dass diese von Ihrer Basisimplementierung unabhängig sind. Diese aktive Überwachung kann anhand von synthetischen Transaktionen erfolgen (auch *Benutzer-Canaries*genannt, jedoch nicht zu verwechseln mit Canary-Bereitstellungen). Diese führen regelmäßig eine Reihe gängiger Aufgaben aus, die mit Aktionen übereinstimmen, die von Clients der Workload durchgeführt werden. Diese Aufgaben sollten nicht zu lang sein und Sie sollten darauf achten, Ihre Workload beim Testen nicht zu überlasten. Mit Amazon CloudWatch Synthetics können Sie [synthetische Canaries erstellen,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) um Ihre Endpunkte und APIs zu überwachen. Sie können die synthetischen Canary-Client-Knoten auch mit der AWS X-Ray-Konsole kombinieren, um zu bestimmen, bei welchen synthetischen Canaries im ausgewählten Zeitraum Probleme mit Fehlern, Störungen oder Drosselungsraten auftreten. 

 **Gewünschtes Ergebnis:** 

 Erfassen und Nutzen kritischer Metriken aus allen Komponenten der Workload, um die Workload-Zuverlässigkeit und eine optimale Benutzererfahrung sicherzustellen. Zu erkennen, dass eine Workload keine Geschäftsergebnisse erzielt, ermöglicht es Ihnen, schnell einen Systemausfall zu deklarieren und das System nach einem Vorfall wiederherzustellen. 

 **Gängige Antimuster:** 
+  Es werden nur externe Schnittstellen zur Workload überwacht. 
+  Es werden keine workload-spezifischen Metriken erzeugt und Sie verlassen sich nur auf Metriken, die Ihnen von den AWS-Services, die Ihre Workload verwendet, bereitgestellt werden. 
+  Es werden nur technische Metriken in Ihrer Workload verwendet und es werden keinerlei Metriken im Zusammenhang mit nicht-technischen KPIs, zu denen die Workload beiträgt, überwacht. 
+  Sie verlassen sich auf den Produktionsdatenverkehr und einfache Zustandsprüfungen für die Überwachung und Bewertung des Workload-Status. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Überwachung aller Ebenen Ihrer Workload können Sie Probleme in den darin enthaltenen Komponenten schneller vorhersehen und beheben. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

1.  **Aktivieren Sie die Protokollierung, wann immer verfügbar.** Von allen Workload-Komponenten sollten Überwachungsdaten erzielt werden. Aktivieren Sie eine zusätzliche Protokollierung, wie etwa S3 Access Logs, und ermöglichen Sie es Ihrer Workload, die workload-spezifischen Daten zu protokollieren. Erfassen Sie Metriken für die Durchschnittswerte zu CPU, Netzwerk-E/A und Laufwerk-E/A von Services wie Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling und Amazon EMR. Unter [AWS-Services, die CloudWatch-Metriken veröffentlichen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) finden Sie eine Liste an AWS-Services, die Metriken in CloudWatch veröffentlichen. 

1.  **Sehen Sie sich alle Standardmetriken an, um mehr über mögliche Datenerfassungslücken zu erfahren.** Jeder Service generiert Standardmetriken. Durch die Erfassung von Standardmetriken erhalten Sie ein besseres Verständnis über die Abhängigkeiten zwischen Workload-Komponenten und darüber, wie die Komponentenzuverlässigkeit und -leistung die Workload beeinträchtigen. Sie können auch [Ihre eigenen Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) in CloudWatch unter Verwendung der AWS CLI oder einer API erstellen und veröffentlichen. Dies 

1.  **Bewerten Sie alle Metriken, um zu entscheiden, für welche eine Warnmeldung für jeden AWS-Service in Ihrer Workload eingerichtet werden soll.** Sie können eine Metriken-Untergruppe auswählen, die eine höhere Auswirkung auf die Workload-Zuverlässigkeit hat. Wenn Sie sich auf kritische Metriken und Schwellenwerte konzentrieren, können Sie die Anzahl an [Warnmeldungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) genauer definieren und so Falschmeldungen reduzieren. 

1.  **Definieren Sie Warnungen und den Wiederherstellungsprozess für Ihre Workload nach dem Auslösen der Warnmeldung.** Das Definieren von Warnmeldungen ermöglicht es Ihnen, schnell zu benachrichtigen, zu eskalieren und die für die Wiederherstellung nach einem Vorfall erforderlichen Schritte durchzuführen, um so Ihren festgelegten Recovery Time Objective (RTO) zu erfüllen. Sie können [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) für das Aufrufen von automatisierten Workflows und die Initiierung von Wiederherstellungsverfahren basierend auf definierten Schwellenwerten verwenden. 

1.  **Erfahren Sie mehr über die Verwendung von synthetischen Transaktionen für das Erfassen relevanter Daten zum Workload-Status.** Die synthetische Überwachung folgt denselben Routen und führt dieselben Aktionen aus wie ein Kunde. Dadurch haben Sie die Möglichkeit, die Kundenerfahrung kontinuierlich zu überprüfen, selbst, wenn Sie keinen Kundendatenverkehr auf Ihren Workloads haben. Durch die Verwendung von [synthetischen Transaktionen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)können Sie Probleme erkennen, bevor Ihre Kunden dies tun. 

## Ressourcen
<a name="resources"></a>

 **Relevante bewährte Methoden:** 
+ [REL11-BP03 Automatisieren der Reparatur auf allen Ebenen](rel_withstand_component_failures_auto_healing_system.md)

 **Relevante Dokumente:** 
+  [Getting started with your AWS Health Dashboard – Your account health (Erste Schritte mit Ihrem AWS Health-Dashboard – Der Zustand Ihres Kontos)](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) 
+  [AWS-Services, die CloudWatch-Metriken veröffentlichen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Zugriffsprotokolle für Ihren Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) 
+  [Zugriffsprotokolle für Ihre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html) 
+  [Zugriff auf Amazon CloudWatch Logs für AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html) 
+  [Protokollierung von Amazon S3-Serverzugriffen](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) 
+  [Aktivieren Sie Zugriffsprotokolle für Ihren Classic Load Balancer.](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html) 
+  [Exportieren von Protokolldaten zu Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [Installieren des CloudWatch-Agenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) 
+  [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Verwenden von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Verwenden von Amazon CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  [Verwenden von Synthetic Monitoring](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Was sind Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 

   **Benutzerhandbücher:** 
+  [Erstellen eines Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) 
+  [Überwachen von Arbeitsspeicher- und Datenträgermetriken für Amazon EC2 Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 
+  [Verwenden von CloudWatch Logs mit Container-Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [VPC Flow Logs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) 
+  [Was ist Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Was ist AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **Ähnliche Blogs:** 
+  [Debugging mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 

 **Ähnliche Beispiele und Workshops:** 
+  [AWS Well-Architected Labs: Operational Excellence - Dependency Monitoring (AWS Well-Architected Labs: Operative Exzellenz – Überwachung von Abhängigkeiten)](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Workshop zur Beobachtbarkeit](https://catalog.workshops.aws/observability/en-US) 

# REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)
<a name="rel_monitor_aws_resources_notification_aggregation"></a>

 Speichern Sie Protokolldaten und wenden Sie gegebenenfalls Filter an, um Metriken zu berechnen. Dazu gehören z. B. die Anzahl eines bestimmten Protokollereignisses oder die Latenz, die aus den Zeitstempeln des Protokollereignisses berechnet wird. 

 Amazon CloudWatch und Amazon S3 dienen als primäre Aggregierungs- und Speicherebenen. Bei einigen Services wie AWS Auto Scaling und Elastic Load Balancing werden Standardkennzahlen für die CPU-Last oder die durchschnittliche Anfragelatenz eines Clusters oder einer Instance bereitgestellt. Für Streaming-Services wie VPC Flow Logs und AWS CloudTrail werden Ereignisdaten an CloudWatch Logs weitergeleitet und Sie müssen Filter definieren und anwenden, um Metriken aus diesen Ereignisdaten zu extrahieren. Auf diese Weise erhalten Sie Zeitreihendaten, die als Eingaben für CloudWatch-Alarme dienen können, die Sie zum Auslösen von Warnungen definieren. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Definieren und berechnen Sie Metriken (Aggregierung). Speichern Sie Protokolldaten und wenden Sie gegebenenfalls Filter an, um Metriken zu berechnen. Dazu gehören z. B. die Anzahl eines bestimmten Protokollereignisses oder die Latenz, die aus den Zeitstempeln des Protokollereignisses berechnet wird. 
  +  Metrikfilter definieren die Begriffe und Muster, die in Protokolldaten zu suchen sind, wenn diese an CloudWatch Logs gesendet werden. CloudWatch Logs verwendet diese Metrikfilter, um Protokolldaten in numerische CloudWatch-Metriken umzuwandeln, die Sie grafisch darstellen oder für die Sie einen Alarm einrichten können. 
    +  [Suchen und Filtern von Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
  +  Verwenden Sie einen vertrauenswürdigen Drittanbieter für die Protokollaggregierung. 
    +  Befolgen Sie die Anweisungen des Drittanbieters. Die meisten Produkte von Drittanbietern lassen sich in CloudWatch und Amazon S3 integrieren. 
  +  Einige AWS-Services können Protokolle direkt in Amazon S3 veröffentlichen. Wenn die Speicherung von Protokollen in Amazon S3 die wichtigste Anforderung ist, kann der Protokoll-Service die Protokolle direkt an Amazon S3 senden, ohne dass eine zusätzliche Infrastruktur eingerichtet werden muss. 
    +  [Senden von Protokollen direkt an Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon CloudWatch Logs Insights-Beispielabfragen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Debugging mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/) 
+  [Suchen und Filtern von Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
+  [Senden von Protokollen direkt an Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)
<a name="rel_monitor_aws_resources_notification_monitor"></a>

 Sorgen Sie dafür, dass bei wichtigen Ereignissen die entsprechenden Organisationen benachrichtigt werden. 

 Warnungen können an Amazon Simple Notification Service (Amazon SNS)-Themen gesendet und anschließend an eine beliebige Anzahl von Abonnenten weitergeleitet werden. Beispiel: Amazon SNS kann Warnungen an einen E-Mail-Alias weiterleiten, sodass das technische Personal reagieren kann. 

 **Gängige Antimuster:** 
+  Alarme werden mit einem zu niedrigen Schwellenwert konfiguriert, wodurch zu viele Benachrichtigungen gesendet werden. 
+  Keine Archivierung von Alarmen für künftige Untersuchungen. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch Benachrichtigungen zu Ereignissen (auch solche, auf die reagiert werden kann und die sich automatisch lösen lassen) können Sie Ereignisse aufzeichnen und sie unter Umständen in Zukunft anders behandeln. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Führen Sie Verarbeitung und Alarme in Echtzeit aus. Sorgen Sie dafür, dass bei wichtigen Ereignissen die entsprechenden Organisationen benachrichtigt werden. 
  +  Amazon CloudWatch-Dashboards sind anpassbare Startseiten in der CloudWatch-Konsole für die Überwachung Ihrer Ressourcen in einer einzigen Ansicht, auch wenn sie über verschiedene Regionen verteilt sind. 
    +  [Verwenden von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
  +  Lassen Sie einen Alarm auslösen, wenn die Metrik einen Grenzwert überschreitet. 
    +  [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Verwenden von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Verwenden von Amazon CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 

# REL06-BP04 Automatisieren von Antworten (Verarbeitung und Benachrichtigung in Echtzeit)
<a name="rel_monitor_aws_resources_automate_response_monitor"></a>

 Automatisieren Sie bei Erkennung von Ereignissen die erforderlichen Maßnahmen, wie etwa den Austausch fehlerhafter Komponenten. 

 Alarme können AWS Auto Scaling-Ereignisse auslösen, sodass Cluster auf Bedarfsänderungen reagieren können. Warnungen können an Amazon Simple Queue Service (Amazon SQS) gesendet werden, das als Integrationspunkt für Ticketsysteme externer Anbieter dienen kann. Auch AWS Lambda kann Warnungen abonnieren und Benutzern so ein asynchrones serverloses Modell bereitstellen, das dynamisch auf Änderungen reagiert. AWS Config überwacht und zeichnet Ihre AWS-Ressourcenkonfigurationen kontinuierlich auf und kann [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) auslösen, um Probleme zu beheben. 

 Amazon DevOps Guru kann Anwendungsressourcen automatisch auf anormale Verhaltensweisen überwachen und gezielte Empfehlungen für eine schnellere Problemidentifizierung und Fehlerbehebung bereitstellen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Verwenden Sie Amazon DevOps Guru, um automatisierte Aktionen auszuführen. Amazon DevOps Guru kann Anwendungsressourcen automatisch auf anormale Verhaltensweisen überwachen und gezielte Empfehlungen für eine schnellere Problemidentifizierung und Fehlerbehebung bereitstellen. 
  +  [Was ist Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  Verwenden Sie AWS Systems Manager, um automatisierte Aktionen auszuführen. AWS Config überwacht und zeichnet Ihre AWS-Ressourcenkonfigurationen kontinuierlich auf und kann zur Behebung von Problemen AWS Systems Manager Automation auslösen. 
  +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  Erstellen und verwenden Sie Systems-Manager-Automation-Dokumente. Darin sind die Maßnahmen definiert, die Systems Manager in den verwalteten Instances und anderen AWS-Ressourcen durchführt, wenn ein Automatisierungslauf ausgeführt wird. 
    +  [Arbeiten mit Automation-Dokumenten (Playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+  Amazon CloudWatch sendet Änderungsereignisse für den Alarmstatus an Amazon EventBridge. Erstellen Sie EventBridge-Regeln zur Automatisierung von Antworten. 
  +  [Erstellen einer EventBridge-Regel, die durch ein Ereignis aus einer AWS-Ressource ausgelöst wird](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) 
+  Erstellen Sie einen Plan für die Automatisierung von Antworten und führen Sie ihn aus. 
  +  Inventarisieren Sie alle Verfahren zur Reaktion auf Warnungen. Sie müssen die Reaktionen auf Warnungen planen, bevor Sie die Aufgaben nach Rang einstufen. 
  +  Inventarisieren Sie alle Aufgaben mit spezifischen Maßnahmen, die durchgeführt werden müssen. Die meisten dieser Maßnahmen sind in Runbooks dokumentiert. Sie müssen außerdem über Playbooks für Warnungen zu unerwarteten Ereignissen verfügen. 
  +  Suchen Sie in den Runbooks und Playbooks nach allen automatisierbaren Maßnahmen. Wenn eine Maßnahme definiert werden kann, lässt sie sich in der Regel auch automatisieren. 
  +  Ordnen Sie zunächst die fehleranfälligen oder zeitaufwändigen Aktivitäten in einer Rangfolge ein. Es ist äußerst nützlich, Fehlerquellen zu entfernen und die Zeit bis zur Lösung zu verkürzen. 
  +  Erstellen Sie einen Plan, um die Automatisierung abzuschließen. Verwalten Sie einen aktiven Plan zur Automatisierung und aktualisieren Sie die Automatisierung. 
  +  Untersuchen Sie die manuellen Anforderungen auf Automatisierungsmöglichkeiten. Hinterfragen Sie Ihren manuellen Prozess und suchen Sie nach Automatisierungsmöglichkeiten. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Erstellen einer EventBridge-Regel, die durch ein Ereignis aus einer AWS-Ressource ausgelöst wird](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) 
+  [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Was ist Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Arbeiten mit Automation-Dokumenten (Playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 

# REL06-BP05 Analysen
<a name="rel_monitor_aws_resources_storage_analytics"></a>

 Erfassen Sie Protokolldateien und Metrikverläufe und analysieren Sie diese, um allgemeine Trends zu erkennen und Workload-Einblicke zu erhalten. 

 Amazon CloudWatch Logs Insights unterstützt eine [einfache und dennoch leistungsstarke Abfragesprache,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) mit der Sie Protokolldaten analysieren können. Amazon CloudWatch Logs unterstützt auch Abonnements, mit denen Daten nahtlos nach Amazon S3 fließen können, wo Sie sie nutzen oder Amazon Athena verwenden können, um die Daten abzufragen. Abfragen für eine große Auswahl von Formaten werden ebenfalls unterstütz. Unter [Unterstützte SerDes- und Datenformate](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) im Amazon Athena-Benutzerhandbuch finden Sie weitere Informationen dazu. Für die Analyse riesiger Protokolldateisätze können Sie einen Amazon EMR-Cluster ausführen, um Analysen im Petabyte-Bereich auszuführen. 

 Es gibt es eine Reihe von Werkzeugen von AWS-Partnern und externen Anbietern, die Aggregierung, Verarbeitung, Speicherung und Analyse ermöglichen. Dazu gehören u. a. die Tools New Relic, Splunk, Loggly, Logstash, CloudHealth und Nagios. Die Generierung außerhalb von System- und Anwendungsprotokollen weicht jedoch bei jedem Cloud-Anbieter und häufig sogar bei den einzelnen Services ab. 

 Ein häufig übersehener Teil des Überwachungsprozesses ist die Datenverwaltung. Sie müssen Aufbewahrungsanforderungen für die Überwachung von Daten definieren und anschließend entsprechende Lebenszyklusrichtlinien anwenden. Amazon S3 unterstützt die Lebenszyklusverwaltung auf der Ebene von S3-Buckets. Diese Lebenszyklusverwaltung kann auf unterschiedliche Weise auf verschiedene Pfade im Bucket angewendet werden. Gegen Ende des Lebenszyklus können Sie die Daten zur Langzeitspeicherung an Amazon Glacier weiterleiten und nach Ablauf der Aufbewahrungsperiode die Speicherung beenden. Die S3 Intelligent-Tiering-Speicherklasse wurde entwickelt, um die Kosten zu optimieren. Daten werden automatisch in die kostengünstigste Zugriffsstufe verschoben, ohne Auswirkungen auf die Leistung oder höheren Betriebsaufwand. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Mit CloudWatch Logs Insights können Sie Protokolldaten in Amazon CloudWatch Logs interaktiv durchsuchen und analysieren. 
  +  [Analysieren von Protokolldaten mit CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
  +  [Amazon CloudWatch Logs Insights-Beispielabfragen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 
+  Verwenden Sie Amazon CloudWatch Logs, um Protokolle an Amazon S3 zu senden, wo Sie sie nutzen oder Amazon Athena verwenden können, um die Abfrage der Daten nutzen können. 
  +  [Wie analysiere ich meine Amazon S3-Serverzugriffsprotokolle mit Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
    +  Erstellen Sie eine S3-Lebenszyklusrichtlinie für Ihren Bucket mit den Serverzugriffsprotokollen. Konfigurieren Sie die Richtlinie so, dass Protokolldateien regelmäßig entfernt werden. Dies reduziert die Datenmenge, die Athena für die einzelnen Abfragen analysiert. 
      +  [Wie erstelle ich eine Lebenszyklusrichtlinie für einen S3-Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Amazon CloudWatch Logs Insights-Beispielabfragen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Analysieren von Protokolldaten mit CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [Debugging mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Wie erstelle ich eine Lebenszyklusrichtlinie für einen S3-Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 
+  [Wie analysiere ich meine Amazon S3-Serverzugriffsprotokolle mit Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
+  [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP06 Regelmäßiges Durchführen von Prüfungen
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 Prüfen Sie regelmäßig, wie die Workload-Überwachung implementiert ist, und aktualisieren Sie sie auf Grundlage wichtiger Ereignisse und Änderungen. 

 Eine effektive Überwachung basiert auf wichtigen Geschäftsmetriken. Stellen Sie sicher, dass diese Metriken in Ihrer Workload berücksichtigt werden, wenn sich geschäftliche Prioritäten ändern. 

 Durch die Prüfung Ihrer Überwachung stellen Sie sicher, dass Sie wissen, wann eine Anwendung die eigenen Verfügbarkeitsziele erfüllt. Für die Durchführung von Ursachenanalysen ist es erforderlich, bei Ausfällen ermitteln zu können, was passiert ist. AWS bietet Services, mit denen Sie den Status Ihrer Services während eines Vorfalls nachverfolgen können. 
+  **Amazon CloudWatch Logs:** Sie können Ihre Protokolle in diesem Service speichern und die Inhalte überprüfen. 
+  **Amazon CloudWatch Logs Insights**: Ein vollständig verwalteter Service, mit dem Sie umfangreiche Protokolle innerhalb von Sekunden analysieren können. Es bietet Ihnen schnelle, interaktive Abfragen und Visualisierungen.  
+  **AWS Config:** Sie können sehen, welche AWS-Infrastruktur zu verschiedenen Zeitpunkten verwendet wurde. 
+  **AWS CloudTrail:** Mit diesem Service können Sie erkennen, welche AWS-APIs zu welchem Zeitpunkt und durch welchen Prinzipal aufgerufen wurden. 

 Bei AWS werden wöchentliche Meetings abgehalten, um [die Produktionsleistung zu prüfen](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) und Erkenntnisse mit anderen Teams zu teilen. Da es so viele Teams in AWS gibt, haben wir [Das Rad](https://aws.amazon.com/blogs/opensource/the-wheel/) entwickelt, um zufällig eine zu überprüfende Workload auszuwählen. Der Aufbau einer Struktur mit regelmäßigen Überprüfungen der betrieblichen Leistung und mit Wissensaustausch verbessert Ihre Fähigkeit, höhere Leistungen bei Ihren Betriebsteams zu erzielen. 

 **Gängige Antimuster:** 
+  Es werden nur Standardmetriken erfasst. 
+  Es wird eine Überwachungsstrategie festgelegt, aber nie überprüft. 
+  Bei Bereitstellung größerer Änderungen wird die Überwachung nicht erörtert. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die regelmäßige Prüfung der Überwachung können Sie mögliche Probleme vorhersehen, statt nur zu reagieren, wenn ein Problem tatsächlich auftritt. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Erstellen Sie mehrere Dashboards für die Workload. Ein übergeordnetes Dashboard mit den wichtigsten Geschäftsmetriken ist unverzichtbar. Es sollte zudem die technischen Metriken enthalten, die Sie für den prognostizierten Zustand der Workload bei variabler Nutzung als die relevantesten eingestuft haben. Dashboards für verschiedene Anwendungsebenen und Abhängigkeiten, die untersucht werden können, sind ebenfalls empfehlenswert. 
  +  [Verwenden von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  Planen und prüfen Sie die Workload-Dashboards regelmäßig. Führen Sie regelmäßige Untersuchungen der Dashboards durch. Was die Gründlichkeit der Untersuchungen angeht, sind unterschiedliche Intervalle denkbar. 
  +  Spüren Sie Trends in den Metriken auf. Vergleichen Sie die Metrikwerte mit Werten aus der Vergangenheit, um Trends zu erkennen, die darauf hinweisen könnten, dass etwas untersucht werden muss. Beispiele hierfür: ansteigende Latenz, Nachlassen der primären Geschäftsfunktion und zunehmende Anzahl von Reaktionen auf Fehler. 
  +  Spüren Sie Ausreißer/Anomalien in den Metriken auf. Ausreißer sind anhand von Durchschnitts- oder Mittelwerten oder Anomalien nicht unbedingt erkennbar. Sehen Sie sich die höchsten und niedrigsten Werte in einem bestimmten Zeitraum an und untersuchen Sie die Ursachen für die extremen Werte. Beseitigen Sie nach und nach die Ursachen und legen Sie dabei einen engeren Maßstab für die Definition von Extremwerten an. So können Sie die Beständigkeit der Workload-Leistung weiter erhöhen. 
  +  Spüren Sie plötzliche Änderungen im Verhalten auf. Eine plötzliche Veränderung in der Menge oder Richtung einer Metrik kann auf eine Änderung in der Anwendung hindeuten. Sie kann aber auch ein Hinweis auf externe Faktoren sein, für deren Verfolgung Sie möglicherweise weitere Metriken hinzufügen müssen. 

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+  [Amazon CloudWatch Logs Insights-Beispielabfragen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Debugging mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Verwenden von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 

# REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System
<a name="rel_monitor_aws_resources_end_to_end"></a>

 Verwenden Sie AWS X-Ray oder Tools von Drittanbietern, damit Entwickler verteilte Systeme einfacher analysieren und debuggen können, um Einblicke in die Leistung der Anwendungen und der zugrunde liegenden Services zu erhalten. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Überwachen Sie die gesamte Nachverfolgung von Anfragen im System. AWS X-Ray ist ein Service, der Daten zu Anfragen erfasst, die von Ihrer Anwendung verarbeitet werden. Zudem stellt er Tools bereit, mit denen Sie diese Daten anzeigen, filtern und auswerten können, um Probleme und Verbesserungsmöglichkeiten zu ermitteln. Sie können für jede nachverfolgte Anfrage an die Anwendung detaillierte Informationen zu Anfrage und Antwort anzeigen. Informationen zu Aufrufen, die Ihre Anwendung für nachgelagerte AWS-Ressourcen, Microservices, Datenbanken und Web-APIs ausführt, werden ebenfalls aufgeführt. 
  +  [Was ist AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
  +  [Debugging mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Debugging mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/) 
+  [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Verwenden von Synthetic Monitoring](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Was ist AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

# ZUV 7 Wie lässt sich der Workload so gestalten, dass er sich an Bedarfsänderungen anpasst?
<a name="w2aac19b9b9b7"></a>

Eine skalierbare Workload bietet die Elastizität, Ressourcen automatisch entsprechend dem aktuellen Bedarf hinzuzufügen oder zu entfernen.

**Topics**
+ [REL07-BP01 Automatisches Abrufen und Skalieren von Ressourcen:](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Abrufen von Ressourcen bei Erkennen einer Beeinträchtigung einer Workload](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Abrufen von Ressourcen bei Feststellung, dass für eine Workload mehr Ressourcen benötigt werden](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Durchführen von Lasttests für die Workload](rel_adapt_to_changes_load_tested_adapt.md)

# REL07-BP01 Automatisches Abrufen und Skalieren von Ressourcen:
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 Wenn Sie beeinträchtigte Ressourcen ersetzen oder Ihre Workload skalieren, können Sie den Prozess mithilfe von verwalteten AWS-Services wie Amazon S3 und AWS Auto Scaling automatisieren. Sie können die Skalierung auch mit Tools von Drittanbietern und AWS SDKs automatisieren. 

 Zu den verwalteten AWS-Services gehören Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate und Amazon Route 53. 

 Mit AWS Auto Scaling können Sie beeinträchtigte Instances erkennen und ersetzen. Außerdem können Sie Skalierungspläne für Ressourcen erstellen, unter anderem für [Amazon EC2](https://aws.amazon.com/ec2/) -Instances und Spot-Flotten, [Amazon ECS](https://aws.amazon.com/ecs/) -Aufgaben, [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) -Tabellen und -Indizes sowie für [Amazon Aurora](https://aws.amazon.com/aurora/) -Replicas. 

 Bei der Skalierung von EC2-Instances sollten Sie mehrere Availability Zones nutzen (mindestens drei) und Kapazität hinzufügen oder entfernen, um ein Gleichgewicht über diese Availability Zones hinweg zu gewährleisten. ECS-Aufgaben oder Kubernetes-Pods (bei Verwendung von Amazon Elastic Kubernetes Service) sollten ebenfalls über mehrere Availability Zones hinweg verteilt werden. 

 Bei Verwendung von AWS Lambda werden Instances automatisch skaliert. Jedes Mal, wenn eine Ereignisbenachrichtigung für Ihre Funktion eingeht, ermittelt AWS Lambda schnell freie Kapazität innerhalb seiner Compute-Flotte und führt Ihren Code bis zur zugeteilten Gleichzeitigkeit aus. Sie müssen sicherstellen, dass die erforderliche Gleichzeitigkeit auf dem spezifischen Lambda und in Ihrem Service Quotas konfiguriert ist. 

 Amazon S3 wird automatisch skaliert, um hohe Anfrageraten zu verarbeiten. Beispielsweise kann Ihre Anwendung mindestens 3 500 PUT/COPY/POST/DELETE- oder 5 500 GET/HEAD-Anfragen pro Sekunde pro Präfix in einem Bucket erreichen. Für die Anzahl der Präfixe in einem Bucket gibt es keine Beschränkungen. Sie können Ihre Lese- oder Schreibleistung erhöhen, indem Sie Lesevorgänge parallelisieren. Wenn Sie beispielsweise 10 Präfixe in einem Amazon S3-Bucket erstellen, können Sie die Leseleistung auf 55 000 Leseanfragen pro Sekunde skalieren, um die Lesevorgänge zu parallelisieren. 

 Konfigurieren und nutzen Sie Amazon CloudFront oder ein vertrauenswürdiges Content Delivery Network (CDN). Ein CDN kann Antwortzeiten für Endbenutzer verkürzen und Anfragen für Inhalte aus dem Cache verarbeiten. Dadurch wird die Notwendigkeit zur Skalierung Ihrer Workload verringert. 

 **Gängige Antimuster:** 
+  Es werden Auto-Scaling-Gruppen für die automatisierte Reparatur implementiert, aber keine Elastizität. 
+  Als Reaktion auf stark ansteigenden Datenverkehr wird automatisch skaliert. 
+  Es werden hochgradig zustandsbehaftete Anwendungen bereitgestellt, wodurch die Option der Elastizität entfällt. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Automatisierung entfällt die Gefahr manueller Fehler bei der Bereitstellung und Außerbetriebnahme von Ressourcen. Durch die Automatisierung entfällt das Risiko von Kostenüberschreitungen und Dienstverweigerungen (Denial of Service) aufgrund der langsamen Reaktion auf Bedürfnisse bezüglich der Bereitstellung oder Außerbetriebnahme von Ressourcen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Konfigurieren und nutzen Sie AWS Auto Scaling. Hiermit erfolgt eine Überwachung der Anwendungen und eine automatische Anpassung der Kapazität, um eine stabile, vorhersehbare Leistung zu möglichst niedrigen Kosten aufrechtzuerhalten. Mit AWS Auto Scaling lässt sich die Anwendungsskalierung für mehrere Ressourcen in mehreren Services einrichten. 
  +  [Was ist AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
    +  Konfigurieren Sie Auto Scaling nach Bedarf in Ihren Amazon EC2-Instances und Spot-Flotten, Amazon ECS-Aufgaben, Amazon DynamoDB-Tabellen und -Indizes, Amazon Aurora-Replikaten und AWS Marketplace-Appliances. 
      +  [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
        +  Legen Sie über die Service-API Alarme, Skalierungsrichtlinien sowie Aufwärm- und Abkühlungszeiten fest. 
+  Nutzen Sie Elastic Load Balancing. Load Balancer können die Last nach Pfaden oder Netzwerkkonnektivität verteilen. 
  +  [Was ist Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
    +  Application Load Balancers kann Lasten nach Pfaden verteilen. 
      +  [Was ist ein Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
        +  Konfigurieren Sie einen Application Load Balancer, um Datenverkehr basierend auf dem Pfad unter dem Domänennamen auf verschiedene Workloads zu verteilen. 
        +  Mit Application Load Balancers können Sie Lasten entsprechend dem AWS Auto Scaling verteilen, um den Bedarf zu verwalten. 
          +  [Nutzen eines Load Balancer mit einer Auto-Scaling-Gruppe](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
    +  Network Load Balancer können Lasten nach Verbindungen verteilen. 
      +  [Was ist ein Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
        +  Konfigurieren Sie einen Network Load Balancer, um Datenverkehr auf verschiedene Workloads mit TCP zu verteilen oder einen konstanten Satz von IP-Adressen für die Workload festzulegen. 
        +  Mit Network Load Balancern können Sie Lasten entsprechend dem AWS Auto Scaling verteilen, um den Bedarf zu verwalten. 
+  Nutzen Sie einen hochverfügbaren DNS-Anbieter. Mithilfe von DNS-Namen können Ihre Benutzer anstelle von IP-Adressen Namen eingeben, um auf Ihre Workloads zuzugreifen. Diese Informationen werden innerhalb einer definierten Reichweite (meist weltweit) für Benutzer der Workload verteilt. 
  +  Nutzen Sie Amazon Route 53 oder einen vertrauenswürdigen DNS-Anbieter. 
    +  [Was ist Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  Mit Route 53 können Sie Ihre CloudFront-Verteilungen und Load Balancer verwalten. 
    +  Ermitteln Sie die zu verwaltenden Domänen und Subdomänen. 
    +  Erstellen Sie entsprechende Datensätze mithilfe von ALIAS- oder CNAME-Datensätzen. 
      +  [Arbeiten mit Datensätzen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 
+  Nutzen Sie das globale AWS-Netzwerk, um den Pfad von den Benutzern zu Ihren Anwendungen zu optimieren. AWS Global Accelerator überwacht kontinuierlich den Zustand der Anwendungsendpunkte und leitet den Datenverkehr in weniger als 30 Sekunden an fehlerfreie Endpunkte um. 
  +  Bei AWS Global Accelerator handelt es sich um einen Service, der die Verfügbarkeit und Leistung der Anwendungen bei lokalen oder weltweiten Benutzern verbessert. Er stellt statische IP-Adressen bereit, die als fester Einstiegspunkt zu den Anwendungsendpunkten in einer einzelnen oder in mehreren AWS-Regionen fungieren, z. B. Application Load Balancers, Network Load Balancer oder Amazon EC2-Instances. 
    +  [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  Konfigurieren und nutzen Sie Amazon CloudFront oder ein vertrauenswürdiges Content Delivery Network (CDN). Ein Content Delivery Network kann Antwortzeiten für Endbenutzer verkürzen und Anfragen für Inhalte verarbeiten, die zu einer unnötigen Skalierung Ihrer Workloads führen könnten. 
  +  [Was ist Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
    +  Konfigurieren Sie Amazon CloudFront-Verteilungen für Ihre Workloads oder verwenden Sie das CDN eines Drittanbieters. 
      +  Sie können festlegen, dass die Workloads nur über CloudFront zugänglich sind. Legen Sie hierfür die IP-Bereiche für CloudFront in den Sicherheitsgruppen oder Zugriffsrichtlinien der Endpunkte fest. 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Ihnen beim Erstellen automatisierter Datenverarbeitungslösungen helfen können](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) 
+  [AWS Auto Scaling: Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: Für Auto Scaling geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Nutzen eines Load Balancer mit einer Auto-Scaling-Gruppe](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
+  [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Was ist Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [Was ist AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
+  [Was ist Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) 
+  [Was ist Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Was ist Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [Was ist ein Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [Was ist ein Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Arbeiten mit Datensätzen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 

# REL07-BP02 Abrufen von Ressourcen bei Erkennen einer Beeinträchtigung einer Workload
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 Skalieren Sie Ressourcen bei Bedarf reaktiv, wenn die Verfügbarkeit beeinträchtigt ist, um die Verfügbarkeit der Workload wiederherzustellen. 

 Sie müssen zunächst Zustandsprüfungen und die Kriterien für diese Prüfungen konfigurieren, um anzugeben, wann die Verfügbarkeit durch fehlende Ressourcen beeinträchtigt wird. Dann können Sie entweder das entsprechende Personal informieren, die Ressource manuell zu skalieren, oder Sie lösen die Automatisierung aus, damit die Skalierung automatisch erfolgt. 

 Die Skalierung kann manuell an Ihre Workload angepasst werden, z. B. indem Sie die Anzahl der EC2-Instances in einer Auto-Scaling-Gruppe ändern oder den Durchsatz einer DynamoDB-Tabelle über die AWS-Managementkonsole oder AWS CLI. Nach Möglichkeit sollten Sie jedoch die Automatisierung verwenden (siehe **Automatisiertes Abrufen oder Skalieren von Ressourcen**). 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Rufen Sie Ressourcen bei der Erkennung einer Beeinträchtigung einer Workload ab. Skalieren Sie Ressourcen bei Bedarf reaktiv, wenn die Verfügbarkeit beeinträchtigt ist, um die Verfügbarkeit der Workload wiederherzustellen. 
  +  Nutzen Sie Skalierungspläne, bei denen es sich um die Kernkomponente von AWS Auto Scaling handelt, um eine Reihe von Anweisungen für das Skalieren Ihrer Ressourcen zu konfigurieren. Wenn Sie mit AWS CloudFormation arbeiten oder AWS-Ressourcen Tags hinzufügen, können Sie pro Anwendung Skalierungspläne für verschiedenen Ressourcengruppen einrichten. AWS Auto Scaling bietet Empfehlungen für an jede Ressource angepasste Skalierungsstrategien. Nachdem Sie einen Skalierungsplan erstellt haben, kombiniert AWS Auto Scaling zur Unterstützung Ihrer Skalierungsstrategie Methoden für die dynamische und prädiktive Skalierung. 
    +  [AWS Auto Scaling: Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
  +  Mit Amazon EC2 Auto Scaling können Sie sicherstellen, dass Ihnen die richtige Anzahl von Amazon EC2-Instances zur Verfügung steht, um die Anwendungslast zu bewältigen. Sie erstellen Sammlungen von EC2-Instances, die als Auto-Scaling-Gruppen bezeichnet werden. In jeder Auto-Scaling-Gruppe können Sie die Mindestanzahl von Instances angeben. Amazon EC2 Auto Scaling stellt dann sicher, dass die Gruppe diese Größe nie unterschreitet. In jeder Auto-Scaling-Gruppe können Sie die maximale Anzahl von Instances angeben. Amazon EC2 Auto Scaling stellt dann sicher, dass die Gruppe diese Größe nie überschreitet. 
    +  [Was ist Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
  +  Bei der automatischen Skalierung von Amazon DynamoDB wird der AWS-Application-Auto-Scaling-Service genutzt, um die bereitgestellte Durchsatzkapazität in Ihrem Auftrag dynamisch an die Muster des tatsächlichen Datenverkehrs anzupassen. So kann eine Tabelle oder ein globaler Sekundärindex die bereitgestellte Lese- und Schreibkapazität erhöhen, um einen plötzlichen Anstieg des Datenverkehrs ohne Drosselung zu bewältigen. 
    +  [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Ihnen beim Erstellen automatisierter Datenverarbeitungslösungen helfen können](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) 
+  [AWS Auto Scaling: Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: Für Auto Scaling geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Was ist Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP03 Abrufen von Ressourcen bei Feststellung, dass für eine Workload mehr Ressourcen benötigt werden
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 Skalieren Sie Ressourcen proaktiv, um den Bedarf zu erfüllen und Auswirkungen auf die Verfügbarkeit zu vermeiden. 

 Viele AWS-Services werden automatisch dem Bedarf entsprechend skaliert. Wenn Sie Amazon EC2-Instances oder Amazon ECS-Cluster verwenden, können Sie die automatische Skalierung dieser Instances auf der Grundlage von Nutzungsmetriken konfigurieren, die dem Bedarf Ihrer Workload entsprechen. Für Amazon EC2 können Sie die durchschnittliche CPU-Auslastung, die Anzahl der Load Balancer-Anfragen oder die Netzwerkbandbreite verwenden, um EC2-Instances zu skalieren. Für Amazon ECS können Sie die durchschnittliche CPU-Auslastung, die Anzahl der Load-Balancer-Anfragen und die Speichernutzung verwenden, um ECS-Aufgaben auf- oder abzuskalieren. Mit Target Auto Scaling auf AWS fungiert der Autoscaler wie ein Haushaltsthermostat, der Ressourcen hinzufügt oder entfernt, um den von Ihnen angegebenen Zielwert (z. B. 70 % CPU-Auslastung) beizubehalten. 

 AWS Auto Scaling kann auch [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)durchführen. Dabei wird Machine Learning verwendet, um die bisherige Workload jeder Ressource zu analysieren und regelmäßig die zukünftige Last für die nächsten zwei Tage zu prognostizieren. 

 Das Gesetz von Little hilft beim Berechnen der Anzahl von Compute-Instances, die Sie benötigen (EC2-Instances, gleichzeitige Lambda-Funktionen usw.). 

 *L* = *λW* 

 L = Anzahl der Instances (oder mittlere Gleichzeitigkeit im System) 

 λ = mittlere Rate des Eingangs von Anfragen (Anfrage/Sekunde) 

 W = mittlere Zeit, die jede Anfrage im System verbringt (Sekunden) 

 Wenn beispielsweise bei 100 RPS die Verarbeitung jeder Anfrage 0,5 Sekunden dauert, benötigen Sie 50 Instances, um mit dem Bedarf Schritt zu halten. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Rufen Sie Ressourcen ab, wenn Sie feststellen, dass für eine Workload mehr Ressourcen benötigt werden. Skalieren Sie Ressourcen proaktiv, um den Bedarf zu erfüllen und Auswirkungen auf die Verfügbarkeit zu vermeiden. 
  +  Berechnen Sie, wie viele Rechenressourcen Sie benötigen (Gleichzeitigkeit der Datenverarbeitung), um eine bestimmte Anfragerate zu verarbeiten. 
    +  [Berichte über das Gesetz von Little](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
  +  Wenn Sie über ein Verlaufsmuster für die Nutzung verfügen, richten Sie die geplante Skalierung für Amazon EC2 ein. 
    +  [Geplante Skalierung für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
  +  Verwenden Sie die vorausschauende Skalierung von AWS. 
    +  [Prädiktive Skalierung für EC2, unterstützt von Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [AWS Auto Scaling: Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: Für Auto Scaling geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Prädiktive Skalierung für EC2, unterstützt von Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Geplante Skalierung für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+  [Berichte über das Gesetz von Little](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
+  [Was ist Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP04 Durchführen von Lasttests für die Workload
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 Messen Sie anhand von Lasttests, ob die Skalierung den Workload-Anforderungen gerecht wird. 

 Es ist wichtig, regelmäßige Lasttests durchzuführen. Mit diesen Tests können Sie die Belastungsgrenze Ihrer Workload ermitteln und deren Leistung prüfen. AWS erleichtert das Einrichten temporärer Testumgebungen, die den Umfang Ihrer Produktions-Workload modellieren. Sie können in der Cloud bei Bedarf eine Testumgebung in Produktionsgröße einrichten, Ihre Tests abschließen und die Ressourcen dann wieder stilllegen. Weil Sie für die Testumgebung nur dann zahlen, wenn sie genutzt wird, können Sie Ihre Live-Umgebung zu einem Bruchteil der Kosten testen, die Sie an einem lokalen Standort hätten. 

 Lasttests in der Produktion sollten auch im Rahmen von Ernstfallübungen durchgeführt werden, bei denen das Produktionssystem in einem Zeitraum mit geringer Kundennutzung stark belastet wird. Alle Mitarbeiter sollten an dieser Übung beteiligt sein, die Ergebnisse gemeinsam interpretieren und auftretende Probleme beheben. 

 **Gängige Antimuster:** 
+  Es werden Lasttests für Bereitstellungen durchgeführt, die nicht mit der Konfiguration der Produktionsumgebung übereinstimmen. 
+  Lasttests werden nur für einzelne Teile, nicht aber für die gesamte Workload durchgeführt. 
+  Es werden Lasttests mit einer Teilmenge von Anfragen durchgeführt, aber nicht mit einer repräsentativen Gruppe tatsächlicher Anfragen. 
+  Es werden Lasttests mit einem kleinen Sicherheitsfaktor durchgeführt, der über der erwarteten Last liegt. 

 **Vorteile der Einführung dieser bewährten Methode:** Sie wissen, welche Komponenten in der Architektur unter Last ausfallen, und können die zu überwachenden Metriken festlegen, die rechtzeitig auf die Annäherung an die Belastungsgrenze hinweisen, damit Sie das Problem beheben und entsprechende Auswirkungen vermeiden können. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Bestimmen Sie anhand von Lasttests, welcher Aspekt der Workload angeben soll, dass Kapazität hinzugefügt oder entfernt werden muss. Bei Lasttests sollte ein repräsentativer Datenverkehr zum Einsatz kommen, der dem in der Produktion ähnelt. Erhöhen Sie unter Beobachtung der instrumentierten Metriken die Last, um zu bestimmen, welche Metrik angibt, wann Ressourcen hinzugefügt oder entfernt werden müssen. 
  +  [Verteilte Lasttests auf AWS: Simulation Tausender verbundener Benutzer](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  Ermitteln Sie die Zusammensetzung von Anfragen. Möglicherweise haben Sie unterschiedliche Zusammensetzungen von Anfragen. Daher sollten Sie sich bei der Ermittlung der Zusammensetzung des Datenverkehrs verschiedene Zeiträume ansehen. 
    +  Implementieren Sie einen Lasttreiber. Zum Implementieren eines Lasttreibers können Sie Software mit eigenem Code, Open-Source-Software oder kommerzielle Software verwenden. 
    +  Führen Sie Lasttests zunächst mit geringer Kapazität durch. Schon bei der Erhöhung der Last für eine Einheit mit geringerer Kapazität, etwa einer einzelnen Instance oder einem einzelnen Container, stellen Sie unmittelbare Auswirkungen fest. 
    +  Führen Sie Lasttests mit größerer Kapazität durch. Bei einer verteilten Last sehen die Auswirkungen anders aus. Daher müssen Sie bei Tests Bedingungen herstellen, die der Produktionsumgebung möglichst nahekommen. 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Verteilte Lasttests auf AWS: Simulation Tausender verbundener Benutzer](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 

# ZUV 8 Wie implementieren Sie Änderungen?
<a name="w2aac19b9b9b9"></a>

Kontrollierte Änderungen sind erforderlich, um neue Funktionen bereitzustellen und um sicherzustellen, dass die Workloads und die Betriebsumgebung bekannte Software ausführen und auf vorhersagbare Weise durch Patches aktualisiert oder ersetzt werden können. Wenn diese Änderungen nicht kontrolliert stattfinden, ist es schwierig, ihre Auswirkungen vorherzusagen oder daraus entstehende Probleme zu beheben. 

**Topics**
+ [REL08-BP01 Verwenden von Runbooks für Standardaktivitäten wie die Bereitstellung](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Integrieren von Funktionstests in die Bereitstellung](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Integrieren von Ausfallsicherheitstests in die Bereitstellung](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Bereitstellung mit einer unveränderlichen Infrastruktur](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Automatisieren von Änderungen](rel_tracking_change_management_automated_changemgmt.md)

# REL08-BP01 Verwenden von Runbooks für Standardaktivitäten wie die Bereitstellung
<a name="rel_tracking_change_management_planned_changemgmt"></a>

 Runbooks sind vordefinierte Verfahren, die ein bestimmtes Ergebnis verfolgen. Verwenden Sie Runbooks, um Standardaktivitäten manuell oder automatisch durchzuführen. Beispiele für solche Aktivitäten sind etwa die Bereitstellung und das Patchen einer Workload oder das Vornehmen von DNS-Änderungen. 

 Sie können z. B. Prozesse einrichten, [um bei Bereitstellungen die Rollback-Sicherheit zu gewährleisten](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Wenn Sie eine Bereitstellung ohne Unterbrechung für Ihre Kunden zurücksetzen können, steigert das die Zuverlässigkeit Ihres Service. 

 Für Runbook-Verfahren sollten Sie mit einem gültigen, effektiven manuellen Prozess beginnen, diesen in Code implementieren und ggf. die automatische Ausführung auslösen. 

 Selbst bei anspruchsvollen Workloads mit umfassender Automatisierung sind Runbooks nützlich, um [Ernstfallübungen auszuführen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) oder strenge Berichterstellungs- und Auditing-Anforderungen zu erfüllen. 

 Playbooks werden als Reaktion auf bestimmte Vorfälle verwendet und mit Runbooks sollen bestimmte Ergebnisse erzielt werden. Häufig werden Runbooks für Routineaktivitäten genutzt, während Playbooks für die Reaktion auf außerplanmäßige Ereignisse verwendet werden. 

 **Gängige Antimuster:** 
+  Durchführen ungeplanter Änderungen an der Konfiguration in der Produktion. 
+  Überspringen von Schritten in Ihrem Plan, um schneller bereitzustellen, was dann jedoch zum Fehlschlagen der Bereitstellung führt. 
+  Vornehmen von Änderungen, ohne die Umkehrung der Änderung zu testen. 

 **Vorteile der Einführung dieser bewährten Methode:** Die effektive Änderungsplanung erhöht Ihre Fähigkeit, die Änderung erfolgreich auszuführen, da Sie sich über alle betroffenen Systeme bewusst sind. Die Validierung Ihrer Änderungen in Testumgebungen erhöht Ihre Sicherheit. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Unterstützen Sie konsistente und schnelle Reaktionen auf gut bekannte Ereignisse, indem Sie Verfahren in Runbooks dokumentieren. 
  +  [AWS-Well-Architected-Framework: Konzepte: Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  Verwenden Sie zur Definition Ihrer Infrastruktur den Grundsatz „Infrastructure as Code“. Wenn Sie Ihre Infrastruktur mit AWS CloudFormation oder dem vertrauenswürdigen Tool eines Drittanbieters definieren, können Sie Änderungen mithilfe einer Versionskontrollsoftware versionieren und nachverfolgen. 
  +  Nutzen Sie zur Definition Ihrer Infrastruktur AWS CloudFormation (oder das vertrauenswürdige Tool eines Drittanbieters). 
    +  [Was ist AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
  +  Erstellen Sie unter Anwendung guter Grundsätze für das Softwaredesign Vorlagen, die getrennt und entkoppelt sind. 
    +  Ermitteln Sie die für die Implementierung erforderlichen Berechtigungen, Vorlagen und zuständigen Parteien. 
      + [ Zugriffssteuerung mit AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
    +  Verwenden Sie zur Versionskontrolle eine Quellkontrolle wie AWS CodeCommit oder das vertrauenswürdige Tool eines Drittanbieters. 
      +  [Was ist AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Sie beim Erstellen automatisierter Bereitstellungslösungen unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [AWS Marketplace: Produkte zur Automatisierung Ihrer Bereitstellungen](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [AWS-Well-Architected-Framework: Konzepte: Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  [Was ist AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [Was ist AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

   **Ähnliche Beispiele:** 
+  [Automating operations with Playbooks and Runbooks (Vorgänge mit Playbooks und Runbooks automatisieren)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL08-BP02 Integrieren von Funktionstests in die Bereitstellung
<a name="rel_tracking_change_management_functional_testing"></a>

 Funktionstests werden im Rahmen der automatisierten Bereitstellung ausgeführt. Wenn die Erfolgskriterien nicht erfüllt sind, wird die Pipeline angehalten oder rückgängig gemacht. 

 Diese Tests werden in einer Vorproduktionsumgebung ausgeführt, die vor der Produktion in der Pipeline bereitgestellt wird. Idealerweise erfolgt dies im Rahmen einer Bereitstellungspipeline. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Integrieren Sie Funktionstests in Ihre Bereitstellung. Funktionstests werden im Rahmen der automatisierten Bereitstellung ausgeführt. Wenn die Erfolgskriterien nicht erfüllt sind, wird die Pipeline angehalten oder rückgängig gemacht. 
  +  Rufen Sie AWS CodeBuild während der „Testaktion“ Ihrer in AWS CodePipeline modellierten Software-Release-Pipelines auf. Mit dieser Funktion können Sie ganz einfach verschiedene Tests für Ihren Code ausführen, z. B. Komponententests, statische Code-Analysen und Integrationstests. 
    +  [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/) 
  +  Verwenden Sie AWS Marketplace-Lösungen, um als Teil Ihrer Softwarebereitstellungs-Pipeline automatisierte Tests auszuführen. 
    +  [Automatisierung von Softwaretests](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [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/) 
+  [Automatisierung von Softwaretests](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 
+  [Was ist AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 

# REL08-BP03 Integrieren von Ausfallsicherheitstests in die Bereitstellung
<a name="rel_tracking_change_management_resiliency_testing"></a>

 Ausfallsicherheitstests (unter Anwendung der [Grundlagen des Chaos-Engineering](https://principlesofchaos.org/)) werden als Teil der automatisierten Bereitstellungs-Pipeline in einer Vorproduktionsumgebung ausgeführt. 

 Diese Tests werden in einer Vorproduktionsumgebung in der Pipeline bereitgestellt und ausgeführt. Sie sollten auch in der Produktion ausgeführt werden, aber im Rahmen von [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays). 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Integrieren Sie Ausfallsicherheitstests in Ihre Bereitstellung. Verwenden Sie Chaos-Engineering, die Disziplin des Experimentierens an einer Workload, um Vertrauen in die Fähigkeit der Workload aufzubauen, turbulente Bedingungen in der Produktion zu bewältigen. 
  +  Ausfallsicherheitstests schleusen Fehler oder die Verschlechterung von Ressourcen ein, um zu bewerten, ob Ihre Workload mit der vorgesehenen Resilienz reagiert. 
    +  [Well-Architected Lab: Level 300: Testen auf Resilienz von EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 
  +  Diese Tests können regelmäßig für automatisierte Bereitstellungs-Pipelines in Vorproduktionsumgebungen ausgeführt werden. 
  +  Sie sollten auch in der Produktion als Teil geplanter Ernstfallübungen ausgeführt werden. 
  +  Entwickeln Sie unter Verwendung von Grundsätzen des Chaos-Engineering Hypothesen zur Leistung Ihrer Workload bei verschiedenen Beeinträchtigungen. Testen Sie dann Ihre Hypothesen mithilfe von Resilienztests. 
    +  [Grundlagen des Chaos-Engineering](https://principlesofchaos.org/) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Grundlagen des Chaos-Engineering](https://principlesofchaos.org/) 
+  [Was ist AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 

 **Ähnliche Beispiele:** 
+  [Well-Architected Lab: Level 300: Testen auf Resilienz von EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 

# REL08-BP04 Bereitstellung mit einer unveränderlichen Infrastruktur
<a name="rel_tracking_change_management_immutable_infrastructure"></a>

 Eine unveränderliche Infrastruktur sieht vor, dass Updates, Sicherheits-Patches oder Konfigurationsänderungen nicht direkt in Produktions-Workloads durchgeführt werden. Wenn eine Änderung erforderlich ist, wird die Architektur auf einer neuen Infrastruktur eingerichtet und für die Produktion bereitgestellt. 

 Die häufigste Implementierung des unveränderlichen Infrastrukturparadigmas ist der ***unveränderlicher Server.***. Wenn ein Update erforderlich ist oder Fehler behoben werden müssen, werden neue Server bereitgestellt, statt die bereits verwendeten Server zu aktualisieren. Statt sich also über SSH beim Server anzumelden und die Softwareversion zu aktualisieren, beginnt jede Änderung in der Anwendung mit einer Push-Verteilung der Software an das Code-Repository, z. B. git push. Da Änderungen in einer unveränderlichen Infrastruktur nicht zulässig sind, ist Ihnen der Status des bereitgestellten Systems immer bekannt. Unveränderliche Infrastrukturen sind grundsätzlich konsistenter, zuverlässiger und berechenbarer und vereinfachen viele Aspekte der Softwareentwicklung und des Betriebs. 

 Verwenden Sie eine Canary- oder Blue/Green-Bereitstellung, wenn Sie Anwendungen in unveränderlichen Infrastrukturen bereitstellen. 

 [https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) wird eine kleine Anzahl Ihrer Kunden zur neuen Version weitergeleitet, die in der Regel auf einer einzelnen Service-Instance (dem Canary) ausgeführt wird. Anschließend überprüfen Sie sämtliche Verhaltensänderungen oder Fehler, die generiert werden. Sie können Datenverkehr aus der Canary-Umgebung entfernen, wenn kritische Probleme auftreten, und die Benutzer auf die vorherige Version zurücksetzen. Wenn die Bereitstellung erfolgreich verläuft, können Sie das gewünschte Tempo beibehalten und die Änderungen auf Fehler überwachen, bis der Bereitstellungsvorgang vollständig abgeschlossen ist. Sie können AWS CodeDeploy mit einer Bereitstellungskonfiguration konfigurieren, die eine Canary-Bereitstellung ermöglicht. 

 [https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) verhalten sich ähnlich wie Canary-Bereitstellungen. Allerdings wird die vollständige Flotte der Anwendung parallel bereitgestellt. Sie können Ihre Bereitstellungen über die zwei Stacks (blau und grün) alternieren. Auch hier können Sie Datenverkehr an die neue Version senden und einen Failback auf die alte Version durchführen, wenn bei der Bereitstellung Probleme auftreten. Normalerweise wird der gesamte Datenverkehr auf einmal umgeschaltet. Sie können Ihren Datenverkehr aber auch auf die Versionen verteilen, um die Einführung der neuen Version mithilfe der gewichteten DNS-Routing-Funktionen von Amazon Route 53 durchzuführen. Sie können AWS CodeDeploy und AWS Elastic Beanstalk mit einer Bereitstellungskonfiguration konfigurieren, die eine Blau/Grün-Bereitstellung ermöglicht. 

![\[Diagramm: Blau/Grün-Bereitstellung mit AWS Elastic Beanstalk und Amazon Route 53\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)


 Vorteile einer unveränderlichen Infrastruktur: 
+  **Reduzierung der Konfigurationsabweichungen:** Wenn Sie Server häufig mit bekannten, versionsgesteuerten und Basiskonfigurationen austauschen, wird die Infrastruktur **in einen bekannten Zustand zurückgesetzt.** Dadurch werden Konfigurationsabweichungen vermieden. 
+  **Vereinfachte Bereitstellungen**: Bereitstellungen werden vereinfacht, da sie keine Upgrades unterstützen müssen. Upgrades sind einfach neue Bereitstellungen. 
+  **Zuverlässige atomare Bereitstellungen:** Bereitstellungen werden entweder erfolgreich abgeschlossen oder es werden keine Änderungen vorgenommen. Das erhöht die Zuverlässigkeit des Bereitstellungsprozesses. 
+  **Sicherere Bereitstellungen mit schnellen Rollback- und Wiederherstellungsprozessen:** Bereitstellungen sind sicherer, da die vorherige funktionierende Version nicht geändert wird. Sie können einen Rollback zur vorherigen Version durchführen, wenn Fehler erkannt werden. 
+  **Konsistente Test- und Debugging-Umgebungen:** Da alle Server dasselbe Image verwenden, gibt es keine Unterschiede zwischen Umgebungen. Ein Build wird in mehreren Umgebungen bereitgestellt. So werden außerdem inkonsistente Umgebungen verhindert und das Testen und Debuggen wird vereinfacht. 
+  **Erhöhte Skalierbarkeit:** Da Server ein Basis-Image verwenden, konsistent und wiederholbar sind, ist die automatische Skalierung sehr einfach. 
+  **Vereinfachte Toolkette**: Die Toolkette ist vereinfacht, da Sie für die Verwaltung von Produktionssoftware-Upgrades keine Konfigurationsmanagement-Tools mehr benötigen. Auf Servern sind keine zusätzlichen Tools oder Agents installiert. Änderungen werden am Basis-Image vorgenommen, getestet und bereitgestellt. 
+  **Erhöhte Sicherheit:** Wenn Sie alle Änderungen an den Servern ablehnen, können Sie SSH auf Instances deaktivieren und Schlüssel entfernen. Dadurch wird der Angriffsvektor reduziert und die Sicherheitslage Ihres Unternehmens verbessert. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Stellen Sie eine unveränderliche Infrastruktur bereit. Eine unveränderliche Infrastruktur ist ein Modell, bei dem Updates, Sicherheits-Patches oder Konfigurationsänderungen nicht *direkt* in Produktions-Workloads durchgeführt werden. Wenn eine Änderung erforderlich ist, wird eine neue Version der Architektur entwickelt und in der Produktion bereitgestellt. 
  +  [Übersicht über eine Blue/Green-Bereitstellung](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green) 
  +  [Schrittweise Bereitstellung von Serverless-Anwendungen](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) 
  +  [Unveränderliche Infrastruktur: Zuverlässigkeit, Konsistenz und Vertrauen durch Unveränderlichkeit](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23) 
  +  [Canary-Release](https://martinfowler.com/bliki/CanaryRelease.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [Canary-Release](https://martinfowler.com/bliki/CanaryRelease.html) 
+  [Schrittweise Bereitstellung von Serverless-Anwendungen](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) 
+  [Unveränderliche Infrastruktur: Zuverlässigkeit, Konsistenz und Vertrauen durch Unveränderlichkeit](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23) 
+  [Übersicht über eine Blue/Green-Bereitstellung](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green) 
+  [Die Amazon Builders' Library: Rollback-Sicherheit bei Bereitstellungen gewährleisten](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 

# REL08-BP05 Automatisieren von Änderungen
<a name="rel_tracking_change_management_automated_changemgmt"></a>

 Bereitstellungen und Patches werden automatisiert, um negative Auswirkungen zu vermeiden. 

 Änderungen an Produktionssystemen gehören in vielen Unternehmen zu den größten Risikofaktoren. Neben den geschäftlichen Problemen, die durch die Software behoben werden, betrachten wir Bereitstellungen als vorrangiges Problem, das es zu lösen gilt. Heutzutage bedeutet das, wenn immer möglich und sinnvoll, Vorgänge zu automatisieren. Dazu gehören Tests und die Bereitstellung von Änderungen, das Hinzufügen oder Entfernen von Kapazität und das Migrieren von Daten. Mit AWS CodePipeline können Sie die erforderlichen Schritte für die Freigabe Ihrer Workload verwalten. Dies umfasst einen Bereitstellungsstatus in AWS CodeDeploy, um die Bereitstellung von Anwendungscode für Amazon EC2-Instances, On-Premise-Instances, serverlose Lambda-Funktionen oder Amazon ECS-Services zu automatisieren. 

**Empfehlung**  
 Obwohl die gängige Meinung vorherrscht, dass es sinnvoll ist, Menschen bei den komplexesten betrieblichen Abläufen in die Vorgänge zu integrieren, empfehlen wir, die komplexesten Abläufe aus genau diesem Grund zu automatisieren. 

 **Gängige Antimuster:** 
+  Manuelles Durchführen von Änderungen. 
+  Überspringen von Schritten in Ihrer Automatisierung durch Notfallarbeitsabläufe. 
+  Entspricht nicht Ihren Plänen. 

 **Vorteile der Einführung dieser bewährten Methode:** Die Verwendung der Automatisierung zum Bereitstellen aller Änderungen verringert das Risiko menschlicher Fehler und ermöglicht die Durchführung von Tests vor Produktionsänderung, um sicherzustellen, dass Ihre Pläne vollständig sind. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Automatisieren Sie Ihre Bereitstellungs-Pipeline. Mit Bereitstellungs-Pipelines können Sie Tests und die Entdeckung von Anomalien automatisieren und die Pipeline an einem bestimmten Schritt vor der Bereitstellung in der Produktion anhalten oder eine Änderung automatisch zurückführen. 
  +  [Die Amazon Builders' Library: Rollback-Sicherheit bei Bereitstellungen gewährleisten](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
  +  [Die Amazon Builders' Library: Schneller mit kontinuierlicher Bereitstellung](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
    +  Verwenden Sie AWS CodePipeline oder das vertrauenswürdige Produkt eines Drittanbieters), um Ihre Pipelines zu definieren und auszuführen. 
      +  Legen Sie fest, dass die Pipeline startet, sobald in Ihrem Code-Repository eine Änderung festgeschrieben wird. 
        +  [Was ist AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
      +  Verwenden Sie Amazon Simple Notification Service (Amazon SNS) und Amazon Simple Email Service (Amazon SES), um Benachrichtigungen bezüglich Pipeline-Problemen zu senden, oder integrieren Sie diese in ein Team-Chat-Tool wie Amazon Chime. 
        +  [Was ist Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
        +  [Was ist Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
        +  [Was ist Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html) 
        +  [Automatisieren Sie Chat-Nachrichten mit Webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 

## Ressourcen
<a name="resources"></a>

 **Relevante Dokumente:** 
+  [APN-Partner: Partner, die Sie beim Erstellen automatisierter Bereitstellungslösungen unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [AWS Marketplace: Produkte zur Automatisierung Ihrer Bereitstellungen](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [Automatisieren Sie Chat-Nachrichten mit Webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 
+  [Die Amazon Builders' Library: Rollback-Sicherheit bei Bereitstellungen gewährleisten](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
+  [Die Amazon Builders' Library: Schneller mit kontinuierlicher Bereitstellung](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
+  [Was ist AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
+  [Was ist CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [Was ist Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
+  [Was ist Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 

 **Relevante Videos:** 
+  [AWS Summit 2019: CI/CD on AWS (AWS Summit 2019: CI/CD auf AWS)](https://youtu.be/tQcF6SqWCoY) 

# Fehlerverwaltung
<a name="a-failure-management"></a>

**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?
<a name="w2aac19b9c11b5"></a>

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
<a name="rel_backing_up_data_identified_backups_data"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **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
<a name="rel_backing_up_data_secured_backups_data"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_backing_up_data_automated_backups_data"></a>

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
<a name="implementation-guidance"></a>

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
<a name="resources"></a>

 **Ä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
<a name="rel_backing_up_data_periodic_recovery_testing_data"></a>

 Ü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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **Ä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?
<a name="w2aac19b9c11b7"></a>

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
<a name="rel_fault_isolation_multiaz_region_system"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **Ä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
<a name="rel_fault_isolation_select_location"></a>

## Gewünschtes Ergebnis
<a name="desired-outcome"></a>

 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
<a name="common-anti-patterns"></a>
+  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:
<a name="benefits-of-establishing-this-best-practice"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **Ä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
<a name="rel_fault_isolation_single_az_system"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **Ä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
<a name="rel_fault_isolation_use_bulkhead"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **Ä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?
<a name="w2aac19b9c11b9"></a>

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
<a name="rel_withstand_component_failures_monitoring_health"></a>

 Ü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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_withstand_component_failures_failover2good"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_withstand_component_failures_auto_healing_system"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_withstand_component_failures_avoid_control_plane"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_withstand_component_failures_static_stability"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_withstand_component_failures_notifications_sent_system"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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?
<a name="w2aac19b9c11c11"></a>

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:
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_testing_resiliency_rca_resiliency"></a>

 Ü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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_testing_resiliency_test_functional"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_testing_resiliency_test_non_functional"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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?
<a name="w2aac19b9c11c13"></a>

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:
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-worksheet"></a>

 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. 

<a name="worksheet"></a>![\[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
<a name="resources"></a>

 **Ä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
<a name="rel_planning_for_recovery_disaster_recovery"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **Ä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:
<a name="rel_planning_for_recovery_dr_tested"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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:
<a name="rel_planning_for_recovery_config_drift"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_planning_for_recovery_auto_recovery"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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)