# REL 10. Wie wird die Fehlerisolierung zum Schützen der Workload verwendet?
Die Fehlerisolierung begrenzt die Auswirkungen eines Komponenten- oder Systemausfalls auf eine definierte Grenze. Bei ordnungsgemäßer Isolierung sind Komponenten außerhalb der Grenze nicht vom Ausfall betroffen. Wenn Sie Ihren Workload über mehrere Fehlerisolierungsgrenzen hinweg ausführen, kann er anfälliger für Ausfälle werden.
**Topics**
+ [REL10-BP01 Bereitstellen des Workloads an mehreren Standorten](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP03 Automatisierte Wiederherstellung für Komponenten, die auf einen einzelnen Standort beschränkt sind](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Verwenden von Bulkhead-Architekturen, um den Umfang von Beeinträchtigungen zu begrenzen](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Bereitstellen des Workloads an mehreren Standorten
Verteilen Sie die Workload-Daten und -Ressourcen über mehrere Availability Zones oder ggf. über mehrere AWS-Regionen.
Ein grundlegendes Prinzip für das Servicedesign in AWS ist die Vermeidung von Single Points of Failure, einschließlich der zugrunde liegenden physischen Infrastruktur. AWS bietet Cloud-Computing-Ressourcen und -Services weltweit an mehreren geographischen Standorten, den sogenannten [Regionen](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Jede Region ist physisch und logisch unabhängig und besteht aus drei oder mehr [Availability Zones (AZs)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html). Availability Zones liegen geographisch nahe beieinander, sind jedoch physisch voneinander getrennt und isoliert. Wenn Sie Ihre Workloads auf Availability Zones und Regionen verteilen, minimieren Sie das Risiko von Bedrohungen wie Bränden, Überschwemmungen, wetterbedingten Katastrophen, Erdbeben und menschlichem Versagen.
Entwickeln Sie eine Standortstrategie, um eine hohe Verfügbarkeit zu gewährleisten, die für Ihre Workloads geeignet ist.
**Gewünschtes Ergebnis:** Produktionsworkloads werden auf mehrere Availability Zones (AZs) oder Regionen verteilt, um Fehlertoleranz und Hochverfügbarkeit zu erreichen.
**Typische Anti-Muster:**
+ Ihr Produktionsworkload ist nur in einer einzelnen Availability Zone vorhanden.
+ Sie implementieren eine Architektur mit mehreren Regionen, wenn eine Multi-AZ-Architektur die geschäftlichen Anforderungen erfüllen würde.
+ Ihre Bereitstellungen oder Daten werden desynchronisiert, was zu Konfigurationsabweichungen oder unzureichend replizierten Daten führt.
+ Sie berücksichtigen nicht die Abhängigkeiten zwischen Anwendungskomponenten, wenn sich die Anforderungen an Ausfallsicherheit und mehrere Standorte zwischen diesen Komponenten unterscheiden.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Ihre Workloads sind widerstandsfähiger gegen Vorfälle wie Strom- oder Umgebungssteuerungsausfälle, Naturkatastrophen, Upstream-Serviceausfälle oder Netzwerkprobleme, die sich auf eine AZ oder eine ganze Region auswirken.
+ Sie können auf einen größeren Bestand an Amazon-EC2-Instances zugreifen und die Wahrscheinlichkeit von InsufficientCapacityExceptions (ICE) verringern, wenn Sie bestimmte EC2-Instance-Typen starten.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Hoch
## Implementierungsleitfaden
Stellen Sie alle Produktionsworkloads in mindestens zwei Availability Zones (AZs) in einer Region bereit und führen Sie diese dort aus.
**Verwenden mehrerer Availability Zones**
Availability Zones sind Standorte für das Hosting von Ressourcen, die physisch voneinander getrennt sind, um korrelierte Ausfälle aufgrund von Risiken wie Bränden, Überschwemmungen und Tornados zu vermeiden. Jede Availability Zone verfügt über eine unabhängige physische Infrastruktur, einschließlich Stromversorgungsanschlüssen, Notstromquellen, mechanischen Services und Netzwerkkonnektivität. Dadurch bleiben Fehler in einer dieser Komponenten nur auf die betroffene Availability Zone beschränkt. Wenn beispielsweise aufgrund eines AZ-weiten Vorfalls EC2-Instances in der betroffenen Availability Zone nicht verfügbar sind, bleiben Ihre Instances in einer anderen Availability Zone weiterhin verfügbar.
Obwohl die Availability Zones in derselben AWS-Region physisch voneinander getrennt sind, sind sie einander nah genug, um Netzwerke mit hohem Durchsatz und niedriger Latenz (einstellige Millisekundenbeträge) bereitzustellen. Sie können Daten für die meisten Workloads synchron zwischen Availability Zones replizieren, ohne den Benutzerkomfort wesentlich zu beeinträchtigen. So können Sie Availability Zones in einer Aktiv/Aktiv- oder Aktiv/Standby-Konfiguration nutzen.
Die gesamte mit Ihren Workloads verbundene Computingleistung sollte auf mehrere Availability Zones verteilt werden. Dazu gehören [Amazon-EC2-Instances](https://aws.amazon.com/ec2/), [AWS Fargate](https://aws.amazon.com/fargate/)-Aufgaben und VPC-verbundene [AWS Lambda](https://aws.amazon.com/lambda/)-Funktionen. AWS-Computingservices, darunter [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) und [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), bieten Ihnen Möglichkeiten, Computingleistung in Availability Zones zu starten und zu verwalten. Konfigurieren Sie diese so, dass die Computingleistung bei Bedarf in einer anderen Availability Zone automatisch ersetzt wird, um die Verfügbarkeit aufrechtzuerhalten. Um Datenverkehr an verfügbare Availability Zones weiterzuleiten, platzieren Sie einen Load Balancer vor Ihrem Computer, z. B. einen Application Load Balancer oder Network Load Balancer. AWS Load Balancer können den Datenverkehr im Falle einer Beeinträchtigung der Availability Zone auf verfügbare Instances umleiten.
Sie sollten auch Daten für Ihre Workloads replizieren und sie in mehreren Availability Zones verfügbar machen. Einige AWS-verwaltete Datenservices wie [Amazon S3](https://aws.amazon.com/s3/) [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), [Amazon Aurora](https://aws.amazon.com/aurora/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/) und [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) replizieren Daten standardmäßig in mehreren Availability Zones und bieten Widerstand gegen Beeinträchtigungen der Availability Zone. Bei anderen AWS-verwalteten Datenservices wie [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) und [Amazon ElastiCache](https://aws.amazon.com/elasticache/) müssen Sie die Multi-AZ-Replikation aktivieren. Nach der Aktivierung erkennen diese Services automatisch eine Beeinträchtigung der Availability Zone, leiten Anfragen an eine verfügbare Availability Zone weiter und replizieren Daten nach Bedarf nach der Wiederherstellung ohne Kundeneingriff erneut. Machen Sie sich mit dem Benutzerhandbuch für jeden von Ihnen verwendeten AWS-verwalteten Datenservice vertraut, um sich mit den Multi-AZ-Funktionen, Verhaltensweisen und Abläufen auszukennen.
Wenn Sie selbstverwalteten Speicher wie [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/)-Volumes oder Amazon-EC2-Instance-Speicher verwenden, müssen Sie die Multi-AZ-Replikation selbst verwalten.
![\[Diagramm mit 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/latest/framework/images/multi-tier-architecture.png)
**Verwenden von mehreren AWS-Regionen**
Wenn Sie über Workloads verfügen, die extreme Widerstandsfähigkeit erfordern (z. B. kritische Infrastrukturen, gesundheitsbezogene Anwendungen oder Services mit strengen kundenspezifischen oder gesetzlich vorgeschriebenen Verfügbarkeitsanforderungen), benötigen Sie möglicherweise zusätzliche Verfügbarkeit, die über das hinausgeht, was eine einzelne AWS-Region bieten kann. In diesem Fall sollten Sie Ihre Workloads auf mindestens zwei AWS-Regionen verteilen und dort ausführen (vorausgesetzt, dass Ihre Anforderungen an die Datenresidenz dies zulassen).
AWS-Regionen befinden sich in verschiedenen geographischen Regionen der Welt und auf mehreren Kontinenten. AWS-Regionen verfügen über eine noch stärkere physische Trennung und Isolierung als Availability Zones allein. AWS-Services, mit wenigen Ausnahmen, nutzen dieses Konzept, um völlig unabhängig zwischen verschiedenen Regionen zu operieren (auch bekannt als *Regionalservices*). Ein Ausfall eines Services in einer AWS-Region soll den Services in einer anderen Region nicht beeinträchtigen.
Wenn Sie Ihre Workloads in mehreren Regionen betreiben, sollten Sie zusätzliche Anforderungen berücksichtigen. Da Ressourcen in verschiedenen Regionen voneinander getrennt und unabhängig voneinander sind, müssen Sie die Komponenten Ihrer Workloads in jeder Region duplizieren. Dazu gehören neben Rechen- und Datenservices auch grundlegende Infrastrukturen wie VPCs.
**HINWEIS:** Wenn Sie ein multiregionales Design in Betracht ziehen, stellen Sie sicher, dass Ihre Workloads in einer einzigen Region ausgeführt werden können. Wenn Sie Abhängigkeiten zwischen Regionen erstellen, in denen eine Komponente in einer Region auf Services oder Komponenten in einer anderen Region angewiesen ist, könnt dies das Ausfallrisiko erhöhen und die Zuverlässigkeit erheblich beeinträchtigen.
Um multiregionale Bereitstellungen zu vereinfachen und die Konsistenz aufrechtzuerhalten, kann [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) Ihre gesamte AWS-Infrastruktur über mehrere Regionen hinweg replizieren. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) kann auch Konfigurationsabweichungen erkennen und Sie informieren, wenn Ihre AWS-Ressourcen in einer Region nicht mehr synchron sind. Viele AWS-Services bieten die Replikation wichtiger Workload-Assets in mehreren Regionen. Beispielsweise kann [EC2 Image Builder](https://aws.amazon.com/image-builder/) Ihre EC2-Machine-Images (AMIs) nach jedem Build in jeder Region, die Sie verwenden, veröffentlichen. [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) kann Ihre Container-Images in Ihre ausgewählten Regionen replizieren.
Sie müssen Ihre Daten auch in jeder der von Ihnen ausgewählten Regionen replizieren. Viele AWS-verwaltete Datenservices bieten multiregionale Replikationsfunktionen, wie z. B. Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon RDS, Amazon Aurora Amazon Aurora, Amazon Redshift, Amazon Elastiache und Amazon EFS. [Globale Amazon DynamoDB-Tabellen](https://aws.amazon.com/dynamodb/global-tables/) akzeptieren Schreibvorgänge in jeder unterstützten Region und replizieren Daten zwischen allen Ihren anderen konfigurierten Regionen. Bei anderen Services müssen Sie eine primäre Region für Schreibvorgänge angeben, da andere Regionen schreibgeschützte Replikate enthalten. Informationen zu den einzelnen AWS-verwalteten Datenservices, die Ihre Workloads verwenden, finden Sie im zugehörigen Benutzer- und Entwicklerhandbuch, wo Sie mehr über die Funktionen und Einschränkungen für mehrere Regionen rfahren. Achten Sie besonders darauf, wohin Schreibvorgänge geleitet werden müssen, welche Transaktionsmöglichkeiten und Einschränkungen gelten, wie die Replikation durchgeführt wird, und wie die Synchronisation zwischen Regionen überwacht wird.
AWS bietet außerdem die Möglichkeit, den Anforderungsdatenverkehr mit großer Flexibilität an Ihre regionalen Bereitstellungen weiterzuleiten. Beispielsweise können Sie Ihre DNS-Datensätze mithilfe von [Amazon Route 53](https://aws.amazon.com/route53/) so konfigurieren, dass der Datenverkehr in die Region geleitet wird, die dem Benutzer am nächsten liegt. Alternativ können Sie Ihre DNS-Datensätze in einer Aktiv-/Standby-Konfiguration konfigurieren, in der Sie eine Region als primär festlegen und nur dann auf ein regionales Replikat zurückgreifen, wenn die primäre Region fehlerhaft wird. Sie können [Route 53-Zustandsprüfungen](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) so konfigurieren, dass sie fehlerhafte Endpunkte erkennen und einen automatischen Failover durchführen. Darüber hinaus können Sie [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) verwenden, um eine hochverfügbare Routing-Steuerung für die manuelle Umleitung von Datenverkehr nach Bedarf bereitzustellen.
Auch wenn Sie sich dafür entscheiden, aus Gründen der Hochverfügbarkeit nicht in mehreren Regionen zu operieren, sollten Sie mehrere Regionen als Teil Ihrer Notfallwiederherstellungsstrategie (DR) in Betracht ziehen. Wenn möglich, replizieren Sie die Infrastrukturkomponenten und Daten Ihrer Workloads in einer *Warm-Standby*- oder *Pilot-Light*-Konfiguration in einer sekundären Region. Dabei replizieren Sie die Basisinfrastruktur aus der primären Region wie VPCs, Auto-Scaling-Gruppen, Container-Orchestratoren und andere Komponenten, konfigurieren aber die Komponenten variabler Größe in der Standby-Region (wie die Anzahl der EC2-Instances und Datenbankreplikate) so, dass sie eine minimal funktionsfähige Größe haben. Sie sorgen auch für eine kontinuierliche Datenreplikation von der primären Region zur Standby-Region. Wenn ein Vorfall eintritt, können Sie die Ressourcen in der Standby-Region skalieren oder vergrößern und sie dann zur primären Region heraufstufen.
### Implementierungsschritte
1. Ermitteln Sie gemeinsam mit geschäftlichen Stakeholdern und Datenresidenzexperten die AWS-Regionen, die zum Hosten Ihrer Ressourcen und Daten verwendet werden können.
1. Bewerten Sie Ihre Workloads in Zusammenarbeit mit geschäftlichen und technischen Stakeholdern, um festzustellen, ob die Anforderungen an die Ausfallsicherheit durch einen Multi-AZ-Ansatz (einzelneAWS-Region) erfüllt werden können, oder ob ein multiregionaler Ansatz erforderlich ist (wenn mehrere Regionen zulässig sind). Die Verwendung mehrerer Regionen kann zu einer höheren Verfügbarkeit führen, jedoch auch zusätzliche Komplexität und Kosten mit sich bringen. Berücksichtigen Sie bei Ihrer Bewertung die folgenden Faktoren:
1. **Geschäftsziele und Kundenanforderungen**: Welche Ausfallzeiten sind zulässig, wenn in einer Availability Zone oder einer Region ein Vorfall eintritt, der sich auf Workloads auswirkt? Bewerten Sie Ihre Ziele für den Wiederherstellungspunkt wie in [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) beschrieben.
1. **Anforderungen an die Notfallwiederherstellung (DR)**: Gegen welche Art von potenziellen Notfällen möchten Sie sich versichern? Ziehen Sie die Möglichkeit eines Datenverlusts oder einer langfristigen Nichtverfügbarkeit in unterschiedlichen Ausprägungen in Betracht, von einer einzelnen Availability Zone bis hin zu einer ganzen Region. Wenn Sie Daten und Ressourcen über Availability Zones hinweg replizieren und in einer einzelnen Availability Zone ein länger dauernder Ausfall auftritt, können Sie den Service in einer anderen Availability Zone wiederherstellen. Wenn Sie Daten und Ressourcen regionsübergreifend replizieren, können Sie den Service in einer anderen Region wiederherstellen.
1. Stellen Sie Ihre Computingressourcen in mehreren Availability Zones bereit.
1. Erstellen Sie in Ihrer VPC mehrere Subnetze in verschiedenen Availability Zones. Konfigurieren Sie jedes Subnetz so, dass es groß genug ist, um die Ressourcen aufzunehmen, die zur Bewältigung des Workloads benötigt werden, auch bei einem Vorfall. Weitere Informationen finden Sie unter [REL02-BP03 Berücksichtigen von Erweiterung und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html).
1. Wenn Sie Amazon-EC2-Instances verwenden, verwenden Sie [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), um Ihre Instances zu verwalten. Geben Sie die Subnetze an, die Sie im vorherigen Schritt ausgewählt haben, als Sie Ihre Auto Scaling-Gruppen erstellt haben.
1. Wenn Sie AWS Fargate Compute für [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) oder [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html) verwenden, wählen Sie die Subnetze aus, die Sie im ersten Schritt ausgewählt haben, wenn Sie einen ECS-Service erstellen, eine ECS-Aufgabe starten oder ein [Fargate-Profil](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) für EKS erstellen.
1. Wenn Sie AWS Lambda-Funktionen verwenden, die in Ihrer VPC ausgeführt werden müssen, wählen Sie die Subnetze aus, die Sie im ersten Schritt bei der Erstellung der Lambda-Funktion ausgewählt haben. AWS Lambda verwaltet die Verfügbarkeit für alle Funktionen, die keine VPC-Konfiguration haben, automatisch für Sie.
1. Platzieren Sie Traffic Directors wie Load Balancer vor Ihren Computingressourcen. Wenn zonenübergreifendes Load Balancing aktiviert ist, erkennen [AWSAp plication Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) und [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html), wenn Ziele wie EC2-Instances und Container aufgrund einer Beeinträchtigung der Availability Zone nicht erreichbar sind, und leiten den Datenverkehr zu Zielen in intakten Availability Zones um. Wenn Sie das zonenübergreifende Load Balancing deaktivieren, verwenden Sie Amazon Application Recovery Controller (ARC), um die Zonenverschiebungsfunktion bereitzustellen. Wenn Sie einen Load Balancer eines Drittanbieters verwenden oder Ihre eigenen Load Balancer implementiert haben, konfigurieren Sie diese mit mehreren Front-Ends in verschiedenen Availability Zones.
1. Replizieren Sie die Daten Ihrer Workloads in mehrere Availability Zones.
1. Wenn Sie einen AWS-verwalteten Datenservice wie Amazon RDS, Amazon ElastiCache oder Amazon FSx verwenden, lesen Sie dessen Benutzerhandbuch, um mehr über seine Datenreplikations- und Ausfallsicherheitsfunktionen zu erfahren. Aktivieren Sie bei Bedarf AZ-übergreifende Replikation und Failover.
1. Wenn Sie AWS-verwaltete Speicherservices wie Amazon S3, Amazon EFS und Amazon FSx verwenden, vermeiden Sie die Verwendung von Single-AZ- oder One-Zone-Konfigurationen für Daten, die eine hohe Dauerhaftigkeit erfordern. Verwenden Sie für diese Services eine Multi-AZ-Konfiguration. Prüfen Sie im Benutzerhandbuch des jeweiligen Services, ob die Multi-AZ-Replikation standardmäßig aktiviert ist, oder ob Sie sie aktivieren müssen.
1. Wenn Sie eine selbstverwaltete Datenbank, eine Warteschlange oder einen anderen Speicherservice ausführen, organisieren Sie die Multi-AZ-Replikation gemäß den Anweisungen zu der Anwendung oder bewährten Methoden. Machen Sie sich mit den Failover-Verfahren für Ihre Anwendung vertraut.
1. Konfigurieren Sie Ihren DNS-Service so, dass er AZ-Beeinträchtigungen erkennt und den Datenverkehr in eine fehlerfreie Availability Zone umleitet. Amazon Route 53 kann dies automatisch tun, wenn es in Kombination mit Elastic Load Balancers verwendet wird. Route 53 kann auch mit Failover-Datensätzen konfiguriert werden, bei denen mithilfe von Integritätsprüfungen nur Anfragen mit fehlerfreien IP-Adressen beantwortet werden. Geben Sie für alle DNS-Datensätze, die für das Failover verwendet werden, einen kleinen TTL-Wert (Time to Live) an (z. B. 60 Sekunden oder weniger), um zu verhindern, dass das Zwischenspeichern von Einträgen die Wiederherstellung behindert (Route 53-Aliaseinträge stellen die entsprechenden TTLs für Sie bereit).
**Zusätzliche Schritte bei Verwendung mehrerer AWS-Regionen**
1. Replizieren Sie den gesamten Betriebssystem- (OS) und Anwendungscode, der von Ihren Workloads verwendet wird, in den ausgewählten Regionen. Replizieren Sie bei Bedarf Amazon Machine Images (AMIs), die von Ihren EC2-Instances verwendet werden, mithilfe von Lösungen wie Amazon EC2 Image Builder. Replizieren Sie Container-Images, die in Registern gespeichert sind, mithilfe von Lösungen wie der regionsübergreifenden Replikation in Amazon ECR. Aktivieren Sie die regionale Replikation für alle Amazon-S3-Buckets, die zum Speichern von Anwendungsressourcen verwendet werden.
1. Stellen Sie Ihre Computingressourcen und Konfigurationsmetadaten (z. B. als im AWS Systems Manager Parameter Store gespeicherte Parameter) in mehreren Regionen bereit. Verwenden Sie dieselben Verfahren, die in den vorherigen Schritten beschrieben wurden, replizieren Sie jedoch die Konfiguration für jede Region, die Sie für Ihre Workloads verwenden. Verwenden Sie Infrastructure-as-Code-Lösungen wie AWS CloudFormation, um beispielsweise die Konfigurationen in allen Regionen einheitlich zu reproduzieren. Wenn Sie eine sekundäre Region in einer Pilot-Light-Konfiguration für die Notfallwiederherstellung verwenden, können Sie die Anzahl Ihrer Computingressourcen auf einen Mindestwert reduzieren, um Kosten zu sparen, was die Zeit bis zur Wiederherstellung entsprechend verlängert.
1. Replizieren Sie Ihre Daten aus Ihrer primären Region in Ihre sekundären Regionen.
1. Globale Amazon DynamoDB-Tabellen stellen globale Replikate Ihrer Daten bereit, in die aus jeder unterstützten Region geschrieben werden kann. Bei anderen AWS-verwalteten Datenservices wie Amazon RDS, Amazon Aurora und Amazon Elasticache legen Sie eine primäre (Lese-/Schreib-) Region und Replikatregionen (schreibgeschützt) fest. Einzelheiten zur regionalen Replikation finden Sie in den Benutzer- und Entwicklerhandbüchern der jeweiligen Services.
1. Wenn Sie eine selbstverwaltete Datenbank verwenden, richten Sie die Replikation in mehreren Regionen gemäß den Anweisungen zur Anwendung oder zu den bewährten Methoden ein. Machen Sie sich mit den Failover-Verfahren für Ihre Anwendung vertraut.
1. Wenn Ihre Workloads AWS EventBridge verwenden, müssen Sie möglicherweise ausgewählte Ereignisse aus Ihrer primären Region an Ihre sekundären Regionen weiterleiten. Geben Sie dazu Ereignisbusse in Ihren sekundären Regionen als Ziele für übereinstimmende Ereignisse in Ihrer Hauptregion an.
1. Überlegen Sie, ob und in welchem Umfang Sie in allen Regionen identische Verschlüsselungsschlüssel verwenden möchten. Ein typischer Ansatz, der Sicherheit und Benutzerfreundlichkeit in Einklang bringt, ist die Verwendung von regionsspezifischen Schlüsseln für für die Region lokale Daten und Authentifizierung und die Verwendung von Schlüsseln mit globalem Geltungsbereich für die Verschlüsselung von Daten, die zwischen verschiedenen Regionen repliziert werden. [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) unterstützt Schlüssel für [mehrere Regionen](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html), um Schlüssel, die zwischen Regionen gemeinsam genutzt werden, sicher zu verteilen und zu schützen.
1. Ziehen Sie AWS Global Accelerator in Betracht, um die Verfügbarkeit Ihrer Anwendung zu verbessern, indem Sie den Datenverkehr in Regionen mit fehlerfreien Endpunkten umleiten.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL02-BP03 Berücksichtigen von Erweiterung und Verfügbarkeit bei der Zuweisung von IP-Adressen für Subnetze](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**Zugehörige Dokumente:**
+ [Globale AWS-Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Whitepaper: Grenzen der AWS-Fehlerisolierung](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Ausfallsicherheit in Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: Beispiel: Aufteilen von Instances über mehrere Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [So funktioniert EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Wie Amazon ECS Aufgaben auf Container-Instances platziert (einschließlich Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [Ausfallsicherheit in AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3: Überblick über das Replizieren von Objekten](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Replikation privater Images in Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [Globale Tabellen: Multiregionale Replikation mit DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Elasticache for Redis OSS: Replikation über AWS-Regionen hinweg mit globalen Datenspeichern](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Ausfallsicherheit in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Verwenden von Amazon Aurora Global Databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [AWS Global Accelerator – Entwicklerhandbuch](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Multiregionale Schlüssel in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: Konfiguration des DNS-Failovers](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Amazon Application Recovery Controller (ARC) – Entwicklerhandbuch](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Senden und Empfangen von Amazon-EventBridge-Ereignissen zwischen AWS-Regionen](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [Blogserie „Erstellen einer regionsübergreifenden Anwendung mit AWS-Services“](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Notfallwiederherstellung (DR)-Architektur 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/)
+ [Architektur für die Notfallwiederherstellung in AWS, Teil III: Pilot Light und Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**Zugehörige Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c)
# REL10-BP03 Automatisierte Wiederherstellung für Komponenten, die auf einen einzelnen Standort beschränkt sind
Wenn Komponenten der Workload nur in einer einzigen Availability Zone oder in einem On-Premises-Rechenzentrum ausgeführt werden können, implementieren Sie die Möglichkeit, die Workload innerhalb Ihrer definierten Wiederherstellungsziele komplett neu aufzusetzen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
Wenn die bewährte Methode zur Bereitstellung der Workload 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html) bereitstellen. 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 wird Ihr Cluster bei Amazon Redshift standardmäßig in einer zufällig ausgewählten Availability Zone innerhalb der ausgewählten AWS-Region bereitgestellt. Alle Knoten des Clusters werden in derselben Zone bereitgestellt.
Für zustandsbehaftete serverbasierte Workloads, die in einem On-Premises-Rechenzentrum bereitgestellt werden, können Sie AWS Elastic Disaster Recovery verwenden, um Ihre Workloads in AWS zu schützen. Wenn Sie bereits in AWS gehostet sind, können Sie Elastic Disaster Recovery verwenden, um Ihre Workload in einer alternativen Availability Zone oder Region zu schützen. Elastic Disaster Recovery verwendet eine kontinuierliche Replikation auf Block-Ebene in eine schlanke Staging-Area, um eine schnelle, zuverlässige Wiederherstellung von On-Premises-Anwendungen und cloudbasierten Anwendungen zu gewährleisten.
**Implementierungsschritte**
1. Implementieren Sie die 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 [Amazon EC2-Auto-Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 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.
+ Die Benutzerdaten der Startvorlage können zur Implementierung einer Automatisierung verwendet werden, die die meisten Workloads automatisch reparieren kann.
+ Verwenden Sie die automatische [Wiederherstellung von Amazon EC2-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 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.
+ Automatic Recovery sendet Benachrichtigungen zum Wiederherstellungsstatus an ein SNS-Thema, wenn der Instance-Fehler erkannt wird.
+ Verwenden Sie [Amazon EC2-Instance-Lebenszyklusereignisse](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) bzw. [Amazon ECS-Ereignisse](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) für die Automatisierung der Selbstreparatur, wenn die automatische Skalierung oder EC2-Wiederherstellung nicht verwendet werden kann.
+ Verwenden Sie die Ereignisse, um die Automatisierung der Reparatur der Komponente entsprechend der erforderlichen Prozesslogik aufzurufen.
+ Schützen Sie statusbehaftete Workloads, die auf einen einzelnen Standort beschränkt sind, mithilfe von [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html).
## Ressourcen
**Zugehörige Dokumente:**
+ [Amazon ECS-Ereignisse](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Lebenszyklus-Hooks bei Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Wiederherstellen der Instance.](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 Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP04 Verwenden von Bulkhead-Architekturen, um den Umfang von Beeinträchtigungen zu begrenzen
Implementieren Sie Bulkhead-Architekturen (zellenbasierte Architekturen), um die Auswirkungen von Fehlern innerhalb einer Workload auf eine begrenzte Anzahl von Komponenten zu beschränken.
**Gewünschtes Ergebnis:** Eine zellenbasierte Architektur verwendet mehrere isolierte Instances einer Workload, wobei jede Instance als Zelle bezeichnet wird. Jede Zelle ist unabhängig. Sie teilt ihren Status nicht mit anderen Zellen und bearbeitet eine Teilmenge der gesamten Workload-Anfragen. Dadurch werden die möglichen Auswirkungen eines Fehlers, z. B. eines fehlerhaften Software-Updates, auf eine einzelne Zelle und die von ihr verarbeiteten Anfragen reduziert. Wenn in einer Workload 10 Zellen für die Beantwortung von 100 Anfragen verwendet werden, sind bei einem Fehler 90 % der gesamten Anfragen nicht davon betroffen.
**Typische Anti-Muster:**
+ Es wird ein unbegrenztes Wachstum der Zellen zugelassen.
+ Code-Updates oder Bereitstellungen werden auf alle Zellen gleichzeitig angewandt.
+ Status oder Komponenten werden von den Zellen geteilt (mit Ausnahme der Router-Schicht).
+ Es werden komplexe Geschäfts- oder Routing-Logiken in die Routing-Schicht eingefügt.
+ Es gibt keine Minimierung der zellenübergreifenden Interaktionen.
**Vorteile der Nutzung dieser bewährten Methode:** Bei zellenbasierten Architekturen sind viele gängige Fehlertypen in der Zelle selbst enthalten, was eine zusätzliche Fehlerisolierung ermöglicht. Diese Fehlergrenzen können die Widerstandsfähigkeit gegenüber Fehlertypen erhöhen, die sonst schwer einzudämmen sind, wie z. B. erfolglose Codebereitstellungen oder Anfragen, die beschädigt sind oder einen bestimmten Fehlermodus aufrufen (auch bekannt als *Poison-Pill–Anfragen*).
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Auf einem Schiff sorgen Schotten dafür, dass eine Beschädigung des Rumpfes auf einen Teil des Schiffes beschränkt bleibt. In komplexen Systemen wird dieses Muster oft kopiert, um eine Fehlerisolierung zu ermöglichen. Fehlerisolierte Grenzen beschränken die Auswirkungen eines Fehlers innerhalb einer Workload auf eine begrenzte Anzahl von Komponenten. Komponenten außerhalb der Grenze sind von dem Ausfall nicht betroffen. Durch die Verwendung mehrerer fehlerisolierter Grenzen können Sie die Auswirkungen auf Ihre Workload einschränken. Bei AWS können Kunden mehrere Availability Zones und Regionen verwenden, um eine Fehlerisolierung zu gewährleisten. Das Konzept der Fehlerisolierung lässt sich jedoch auch auf die Architektur Ihrer Workload ausweiten.
Die gesamte Workload wird durch einen Partitionsschlüssel in Zellen unterteilt. Dieser Schlüssel muss mit der *Struktur* des Service übereinstimmen oder mit der natürlichen Art und Weise, wie die Workload eines Service mit minimalen zellenübergreifenden Interaktionen unterteilt werden kann. Beispiele für Partitionsschlüssel sind die ID des Kunden, die ID der Ressource oder jeder andere Parameter, der in den meisten API-Aufrufen leicht zugänglich ist. Eine Schicht für das Routing von Zellen verteilt Anfragen auf der Grundlage des Partitionsschlüssels an einzelne Zellen und präsentiert den Kunden einen einzigen Endpunkt.
![\[Diagramm einer zellenbasierten Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/framework/images/cell-based-architecture.png)
**Implementierungsschritte**
Bei der Entwicklung einer zellenbasierten Architektur sind mehrere Designüberlegungen zu berücksichtigen:
1. **Partitionsschlüssel**: Bei der Auswahl des Partitionsschlüssels sollten besondere Überlegungen angestellt werden.
+ Er sollte mit der Struktur des Service übereinstimmen oder mit der natürlichen Art und Weise, wie die Workload eines Service mit minimalen zellenübergreifenden Interaktionen unterteilt werden kann. Beispiele sind `customer ID` oder `resource ID`.
+ Der Partitionsschlüssel muss in allen Anfragen verfügbar sein – entweder direkt oder in einer Weise, die sich durch andere Parameter leicht deterministisch ableiten lässt.
1. **Persistente Zellenzuordnung**: Upstream-Services sollten während des gesamten Lebenszyklus ihrer Ressourcen nur mit einer einzelnen Zelle interagieren.
+ Je nach Workload kann eine Strategie zur Migration von Zellen erforderlich sein, um Daten von einer Zelle in eine andere zu migrieren. Ein mögliches Szenario, in dem eine Migration von Zellen erforderlich sein kann, ist, wenn ein bestimmter Benutzer oder eine bestimmte Ressource in Ihrer Workload zu groß wird und eine eigene Zelle benötigt.
+ Zellen sollten keinen Status und keine Komponenten gemeinsam nutzen.
+ Folglich sollten zellenübergreifende Interaktionen vermieden oder auf ein Minimum beschränkt werden, da diese Interaktionen Abhängigkeiten zwischen den Zellen schaffen und somit die Möglichkeiten zur Fehlerisolierung verringern.
1. **Router-Schicht**: Die Router-Schicht ist eine Komponente, die von Zellen gemeinsam genutzt wird, sodass nicht dieselbe Segmentierungsstrategie verfolgt werden kann wie bei Zellen.
+ Es wird empfohlen, dass die Routing-Schicht Anfragen auf einzelne Zellen verteilt, indem sie einen effizienten Algorithmus für die Zuordnung von Partitionen einsetzt – z. B. als die Kombination von kryptographischen Hash-Funktionen und einer modularen Arithmetik.
+ Um Auswirkungen auf mehrere Zellen zu vermeiden, muss die Routing-Schicht so einfach und horizontal skalierbar wie möglich bleiben, was den Verzicht auf eine komplexe Geschäftslogik innerhalb dieser Schicht erforderlich macht. Dies hat den zusätzlichen Nutzen, dass das erwartete Verhalten jederzeit leicht nachvollziehbar ist, was eine gründliche Testbarkeit ermöglicht. Wie Colm MacCárthaigh in [Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) erklärt, sorgen einfache Designs und Muster mit konstanter Ausführung für zuverlässige Systeme und verringern die Widerstandsfähigkeit gegen Fragilität.
1. **Zellgröße**: Für Zellen sollte eine maximale Größe festgelegt sein, die sie nicht überschreiten dürfen.
+ Die maximale Größe sollte durch gründliche Tests ermittelt werden – bis Sollbruchstellen erreicht und sichere operative Margen etabliert sind. Weitere Details zur Implementierung von Testverfahren finden Sie unter [REL07-BP04 Belastungstest Ihr Workload](rel_adapt_to_changes_load_tested_adapt.md).
+ Die gesamte Workload sollte durch Hinzufügen zusätzlicher Zellen wachsen, sodass die Workload mit der steigenden Nachfrage skalieren kann.
1. **Multi-AZ- oder multiregionale Strategien**: Zum Schutz vor unterschiedlichen Ausfall-Domains sollten mehrere Resilienzebenen genutzt werden.
+ 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. Wenn Sie eine Multi-Region-Strategie für Ihre Workload implementieren, ist sie 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. Weitere Details erhalten Sie unter [REL10-BP01 Bereitstellen des Workloads an mehreren Standorten](rel_fault_isolation_multiaz_region_system.md).
1. **Codebereitstellung**: Eine Strategie zur gestaffelten Codebereitstellung sollte der gleichzeitigen Bereitstellung von Codeänderungen in allen Zellen vorgezogen werden.
+ Auf diese Weise werden mögliche Fehler in mehreren Zellen aufgrund einer fehlerhaften Bereitstellung oder menschlichen Versagens minimiert. Weitere Informationen finden Sie unter [Automatisierung sicherer, vollautomatischer Bereitstellungen](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL07-BP04 Belastungstest Ihr Workload](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 Bereitstellen des Workloads an mehreren Standorten](rel_fault_isolation_multiaz_region_system.md)
**Zugehörige Dokumente:**
+ [ Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS und Segmentierung ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [ Workload-Isolation mit Shuffle Sharding ](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Automatisierung sicherer, vollautomatischer Bereitstellungen](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Zugehörige Videos:**
+ [AWS re:Invent 2018: Close Loops & Opening Minds: Wie man die Kontrolle über große und kleine Systeme übernimmt ](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (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)
+ [AWS Summit ANZ 2021 – Everything fails, all the time: Designing for resilience ](https://www.youtube.com/watch?v=wUzSeSfu1XA)