# REL 11. Wie können Sie Workloads so gestalten, dass sie Komponentenausfällen gegenüber resilient sind?
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-BP07 Architektur Ihres Produkts zur Erfüllung von Verfügbarkeitszielen und Uptime-SLAs (Service Level Agreements)](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler
Überwachen Sie den Zustand Ihres Workloads kontinuierlich, damit Sie und Ihre automatisierten Systeme auf Fehler oder Verschlechterungen aufmerksam werden, sobald diese auftreten. Ü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.
**Gewünschtes Ergebnis:** Wesentliche Komponenten eines Workloads werden unabhängig überwacht, um Fehler zu erkennen und anzuzeigen, wann und wo sie auftreten.
**Typische Anti-Muster:**
+ 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) zu erreichen.
+ Nur die kundenorientierten Schnittstellen des Workloads werden aktiv überwacht.
+ Es werden nur technische Metriken erfasst, keine Metriken für Geschäftsfunktionen.
+ Es gibt keine Metriken, die die Benutzererfahrung der Workload messen.
+ Es werden zu viele Überwachungen erstellt.
**Vorteile der Nutzung dieser bewährten Methode:** Mit einer angemessenen Überwachung auf allen Ebenen können Sie die Wiederherstellungszeit reduzieren, indem Sie die Zeit bis zur Erkennung verkürzen.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Identifizieren Sie alle Workloads, die für die Überwachung überprüft werden sollen. Sobald Sie alle zu überwachenden Komponenten des Workloads identifiziert haben, müssen Sie das Überwachungsintervall festlegen. Das Überwachungsintervall wirkt sich direkt darauf aus, wie schnell eine Wiederherstellung eingeleitet werden kann (abhängig davon, wie lange die Erkennung eines Fehlers dauert). Die Mittlere Zeit bis zur Erkennung ist die Zeitspanne zwischen dem Auftreten eines Fehlers und dem Beginn der Reparaturarbeiten. Die Liste der Services sollte umfassend und vollständig sein.
Die Überwachung muss alle Ebenen des Anwendungs-Stacks (inklusive Anwendung, Plattform, Infrastruktur und Netzwerk) abdecken.
Ihre Überwachungsstrategie sollte außerdem die Auswirkungen von *grauen Fehlern*berücksichtigen. Weitere Details zu grauen Fehlern finden Sie unter [ Graue Fehler](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) im Whitepaper „Advanced Multi-AZ Resilience Patterns“ (Erweiterte Multi-AZ Resilience-Muster).
### Implementierungsschritte
+ Ü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 Komponenten und verwaltete Services.
+ Bestimmen Sie, ob [eine detaillierte Überwachung für EC2-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) und [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) notwendig ist. Eine detaillierte Überwachung liefert Metriken in einminütigen Intervallen, die Standardüberwachung liefert Metriken in fünfminütigen Intervallen.
+ Bestimmen Sie, ob [eine erweiterte Überwachung](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) für RDS erforderlich ist. Die erweiterte Überwachung verwendet einen Agenten auf RDS-Instances, um nützliche Informationen über verschiedene Prozesse oder Threads zu erhalten.
+ Bestimmen Sie die Anforderungen an die Überwachung von kritischen Serverless-Komponenten für [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs), und alle Arten von [Load Balancern](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html)berücksichtigen.
+ Ermitteln Sie die Überwachungsanforderungen von Speicherkomponenten für [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html)und [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html).
+ Erstellen Sie [benutzerdefinierte Metriken,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) um geschäftliche Key Performance Indicators (KPIs) zu messen. Workloads implementieren wichtige geschäftliche Funktionen, die als KPIs verwendet werden sollten, um zu erkennen, wann ein indirektes Problem auftritt.
+ Überwachen Sie das Benutzererlebnis auf Fehler mithilfe von Benutzer-Canarys. [Tests für synthetische Transaktionen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (auch bekannt als Canary-Tests, aber nicht zu verwechseln mit Canary-Bereitstellungen), die das Kundenverhalten simulieren können, gehören zu den wichtigsten Testprozessen. Führen Sie diese Tests für Ihre Workload-Endpunkte konstant von verschiedenen Remote-Standorten aus.
+ Erstellen Sie [benutzerdefinierte Metriken,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) die das Benutzererlebnis nachverfolgen. Wenn Sie das Kundenerlebnis instrumentieren können, können Sie die Verschlechterung des Kundenerlebnisses feststellen.
+ [Legen Sie Alarme fest,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) um zu erkennen, wenn ein Teil Ihres Workloads nicht ordnungsgemäß funktioniert, und um anzuzeigen, wann die Ressourcen automatisch skaliert werden müssen. Alarme können visuell auf Dashboards angezeigt werden, Warnungen über Amazon SNS oder E-Mail versenden und mit Auto Scaling zusammenarbeiten, um Workload-Ressourcen hoch- oder herunterskalieren zu können.
+ Erstellen Sie [Dashboards,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 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.
+ Erstellen Sie [eine verteilte Tracing-Überwachung](https://aws.amazon.com/xray/faqs/) für Ihre Services. Mit der verteilten Überwachung können Sie nachvollziehen, wie Ihre Anwendung und die ihr zugrunde liegenden Services arbeiten, um die Ursache von Leistungsproblemen und Fehlern zu identifizieren und zu beheben.
+ Erstellen Sie Überwachungssysteme (mit [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) oder [X-Ray](https://aws.amazon.com/xray/faqs/)) Dashboards und einer Datenerfassung in einer eigenen Region und einem eigenen Konto.
+ Erstellen Sie eine Integration zur [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) Überwachung, um die Überwachung von AWS-Ressourcen zu ermöglichen, bei denen es zu Leistungseinbußen kommen könnte. Für geschäftskritische Workloads bietet diese Lösung Zugriff auf proaktive und Echtzeitbenachrichtigungen für AWS-Services.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [Definition der Verfügbarkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Zugehörige 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)
+ [Erweiterte Überwachung](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Überwachen ihrer Auto Scaling-Gruppe 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)
+ [Using Cross Region Cross Account CloudWatch Dashboards (Verwenden von konto- und regionenübergreifenden Amazon CloudWatch-Dashboards)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [Using Cross Region Cross Account X-Ray Tracing (Verwenden der konto- und regionenübergreifenden Amazon CloudWatch-Nachverfolgung)](https://aws.amazon.com/xray/faqs/)
+ [Verstehen der Verfügbarkeit](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
+ [Implementing Amazon Health Aware (AHA) (Implementierung von Amazon Health Aware (AHA))](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/)
**Zugehörige Videos:**
+ [Mitigating gray failures (Beheben von grauen Fehlern)](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**Zugehörige 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)
+ [Workshop zur Beobachtbarkeit: X-Ray erkunden](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**Zugehörige Tools:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 Failover zu fehlerfreien Ressourcen
Wenn ein Fehler bei einer Ressource auftritt, sollten intakte Ressourcen weiterhin Anfragen bedienen. Stellen Sie sicher, dass Sie bei Standortbeeinträchtigungen (z. B. Availability Zone oder AWS-Region) über Systeme verfügen, die einen Failover auf intakte Ressourcen an nicht beeinträchtigten Standorten ermöglichen.
Wenn Sie einen Service entwerfen, verteilen Sie die Last auf Ressourcen, Availability Zones oder Regionen. So kann der Fehler einer einzelnen Ressource oder eine Beeinträchtigung durch die Verlagerung des Datenverkehrs auf die verbleibenden intakten Ressourcen aufgefangen werden. Überlegen Sie, wie Services im Falle eines Fehlers erkannt und geroutet werden.
Entwerfen Sie Ihre Services mit Blick auf die Fehlerbehebung. Bei AWS konzipieren wir 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. 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.
Die Muster und Entwürfe, die den Failover ermöglichen, variieren für jeden AWS-Plattform-Service. Viele native verwaltete Services von AWS nutzen von Haus aus mehrere Availability Zones (wie Lambda oder API Gateway). Andere AWS-Services (wie EC2 und EKS) erfordern spezielle bewährte Methoden, um einen Failover von Ressourcen oder Datenspeichern über AZs hinweg zu unterstützen.
Es sollte eine Überwachung eingerichtet werden, um zu überprüfen, ob die Failover-Ressource in Ordnung ist, den Fortschritt der Failover-Ressourcen zu verfolgen und die Wiederherstellung von Geschäftsprozessen zu überwachen.
**Gewünschtes Ergebnis:** Die Systeme sind in der Lage, automatisch oder manuell neue Ressourcen zu verwenden, um sich von Störungen zu erholen.
**Typische Anti-Muster:**
+ Die Planung für Fehler ist nicht Teil der Planungs- und Designphase.
+ RTO und RPO sind nicht festgelegt.
+ Unzureichende Überwachung, um ausfallende Ressourcen zu erkennen.
+ Ordnungsgemäße Isolierung von fehlerhaften Domänen.
+ Multi-Region-Failover wird nicht berücksichtigt.
+ Die Erkennung von Fehlern ist bei der Entscheidung für einen Failover zu empfindlich oder zu aggressiv.
+ Failover-Design wird nicht getestet oder validiert.
+ Durchführen automatischer Reparaturen ohne die Benachrichtigung, dass eine Reparatur erforderlich war.
+ Fehlender Ausgleichszeitraum, um einen zu frühen Failover zu vermeiden.
**Vorteile der Nutzung dieser bewährten Methode:** Sie können widerstandsfähigere Systeme aufbauen, die auch bei Fehlern zuverlässig bleiben, indem sie ordnungsgemäß reduziert werden und sich schnell erholen.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
AWS-Services, wie z. B. [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) und [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)helfen, die Last auf Ressourcen und Availability Zones 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, die mehrere Regionen umfassen, sind Designs etwas komplizierter. Mit regionenübergreifenden Lesereplikaten können Sie beispielsweise Ihre Daten für mehrere AWS-Regionen bereitstellen. Der Failover ist jedoch immer noch erforderlich, um das Lesereplikat zum primären Endpunkt zu machen und den Datenverkehr auf den neuen Endpunkt zu lenken. Amazon Route 53, Route 53 ARC, CloudFront und AWS Global Accelerator können beim Routing des Datenverkehrs über AWS-Regionen helfen.
AWS-Services wie Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge oder Amazon DynamoDB werden von AWS automatisch in mehreren Availability Zones bereitgestellt. Im Falle eines Fehlers leiten diese AWS-Services den Datenverkehr automatisch an intakte Standorte um. Die Daten werden redundant in mehreren Availability Zones gespeichert und bleiben verfügbar.
Für Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS oder Amazon ECS ist Multi-AZ eine Konfigurationsoption. AWS kann den Datenverkehr zur intakten Instance umleiten, wenn ein Failover eingeleitet wird. Diese Failover-Aktion kann von AWS oder auf Wunsch des Kunden durchgeführt werden.
Für Amazon EC2-Instances, Amazon Redshift, Amazon ECS-Aufgaben oder Amazon EKS-Pods wählen Sie aus, in welchen Availability Zones sie bereitgestellt werden sollen. Für einige Designs bietet Elastic Load Balancing die Lösung, Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr in die intakten Zonen zu routen. Elastic Load Balancing kann den Datenverkehr auch zu Komponenten in Ihrem On-Premises-Rechenzentrum routen.
Für den Failover von Datenverkehr aus mehreren Regionen kann das Rerouting mit Amazon Route 53, ARC, AWS Global Accelerator, Route 53 Private DNS for VPCs oder CloudFront eine Möglichkeit bieten. Sie können Internetdomänen definieren und Routing-Richtlinien einschließlich Zustandsprüfungen zuweisen, um den Datenverkehr in intakte Regionen zu leiten. AWS Global Accelerator stellt statische IP-Adressen bereit, die als fester Einstiegspunkt für Ihre Anwendung fungieren und dann zu Endpunkten Ihrer Wahl in AWS-Regionen geroutet werden, wobei das globale Netzwerk von AWS anstelle des Internets für eine bessere Leistung und Zuverlässigkeit genutzt wird.
### Implementierungsschritte
+ Erstellen Sie Failover-Designs für alle entsprechenden Anwendungen und Services. Isolieren Sie jede Komponente der Architektur und erstellen Sie Failover-Designs, die das RTO und RPO für jede Komponente erfüllen.
+ Konfigurieren Sie weniger anspruchsvolle Umgebungen (wie Entwicklungs- oder Testumgebungen) mit allen Services, die für einen Failover-Plan erforderlich sind. Stellen Sie die Lösungen mit Infrastructure as Code (IaC) bereit, um die Reproduzierbarkeit sicherzustellen.
+ Konfigurieren Sie einen Wiederherstellungsstandort, z. B. eine zweite Region, um die Failover-Designs zu implementieren und zu testen. Falls erforderlich, können die Ressourcen für die Tests vorübergehend konfiguriert werden, um die zusätzlichen Kosten zu begrenzen.
+ Bestimmen Sie, welche Failover-Pläne durch AWS automatisiert sind, welche durch einen DevOps-Prozess automatisiert werden können und welche möglicherweise manuell sind. Dokumentieren und messen Sie die RTO- und RPO-Zeiten der einzelnen Services.
+ Erstellen Sie ein Failover-Playbook, das alle Schritte zum Failover jeder Ressource, Anwendung und jedes Services enthält.
+ Erstellen Sie ein Failback-Playbook, das alle Schritte zum Failback (mit Zeitangabe) für jede Ressource, jede Anwendung und jeden Service enthält.
+ Erstellen Sie einen Plan, um das Playbook zu initiieren und zu proben. Verwenden Sie Simulationen und Chaostests, um die Schritte des Playbooks und die Automatisierung zu testen.
+ Stellen Sie sicher, dass Sie bei einer Beeinträchtigung des Standorts (z. B. Availability Zone oder AWS-Region) über Systeme verfügen, die einen Failover auf intakte Ressourcen an nicht beeinträchtigten Standorten ermöglichen. Überprüfen Sie Kontingente, die automatische Skalierung und laufende Ressourcen vor dem Failover-Test.
## Ressourcen
**Zugehörige bewährte Methoden für Well-Architected:**
+ [REL13- Planen für DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 – Nutzen der Fehlerisolierung zum Schutz Ihres Workloads](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**Zugehörige Dokumente:**
+ [Einstellen von RTO- und RPO-Zielen](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Einrichten von ARC mit Application Load Balancers](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/)
+ [Failover mit gewichtetem Route 53-Routing](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)
+ [DR mit ARC](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 mit automatischer Skalierung](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [EC2-Bereitstellungen – Multi-AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-)
+ [ECS-Bereitstellungen – Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Datenverkehr umleiten mit ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda mit einem Application Load Balancer und Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [ACM-Replikation und -Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Parameter Store-Replikation und -Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [Regionsübergreifende ECR-Replikation und Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Konfigurieren der regionsübergreifenden Replikation von Secrets Manager](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [Aktivieren der regionsübergreifende Replikation für EFS und Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [Regionsübergreifende EFS-Replikation und Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [Netzwerk-Failover](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [S3-Endpunkt-Failover mit MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [Erstellen einer regionsübergreifenden Replikation für S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Failover-Region API Gateway mit ARC](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449)
+ [Failover mit Global Accelerator über mehrere Regionen](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [Failover mit DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
+ [Erstellen von Mechanismen für die Notfallwiederherstellung mit Amazon Route 53](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b)
**Zugehörige Beispiele:**
+ [Notfallwiederherstellung auf AWS](https://disaster-recovery.workshop.aws/en/)
+ [Elastische Notfallwiederherstellung auf AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 Automatisieren der Reparatur auf allen Ebenen
Verwenden Sie bei Erkennung eines Fehlers automatisierte Funktionen, um Maßnahmen zur Behebung durchzuführen. Beeinträchtigungen können automatisch durch interne Service-Mechanismen behoben werden. Es kann aber auch erforderlich sein, Ressourcen neu zu starten oder Abhilfemaßnahmen durchzuführen.
Für selbstverwaltete Anwendungen und regionenübergreifende Korrekturen können Wiederherstellungskonzepte und automatisierte Korrekturprozesse aus [bestehenden bewährten Methoden verwendet werden](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/).
Die Möglichkeit, eine Ressource neu zu starten oder zu entfernen, ist ein wichtiges Instrument zur Behebung von Fehlern. Eine bewährte Methode besteht darin, Services nach Möglichkeit zustandslos zu betreiben. Dies verhindert den Datenverlust oder den Verlust der Verfügbarkeit bei einem Neustart der Ressource. In der Cloud können Sie (und sollten Sie üblicherweise) die gesamte Ressource (z. B. eine Computing-Instance oder eine Serverless-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 bei Hardware, Software, Kommunikation und Betrieb auftreten.
Der Neustart oder Wiederholungsversuch gilt auch für Netzwerkanfragen. 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 Fähigkeit zum Neustart ist eine Funktion, die in wiederherstellungsorientierten Computing- und Hochverfügbarkeits-Cluster-Architekturen empfohlen wird.
**Gewünschtes Ergebnis:** Automatisierte Aktionen werden durchgeführt, um die Erkennung eines Fehlers zu beheben.
**Typische Anti-Muster:**
+ Bereitstellung von Ressourcen ohne automatische Skalierung.
+ 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.
+ Keine Automatisierung beim Failover von Datenbanken.
+ Keine automatisierten Methoden zur Umleitung des Datenverkehrs auf neue Endpunkte.
+ Keine Speicherreplikation.
**Vorteile der Nutzung dieser bewährten Methode:** Eine automatisierte Korrektur kann die mittlere Zeit bis zur Wiederherstellung verkürzen und Ihre Verfügbarkeit verbessern.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Designs für Amazon EKS oder andere Kubernetes-Services sollten sowohl minimale und maximale Replikate oder zustandsbehaftete Sets als auch die minimale Größenanpassung von Clustern und Knotengruppen umfassen. Diese Mechanismen sorgen für ein Minimum an kontinuierlich verfügbaren Verarbeitungsressourcen und beheben gleichzeitig automatisch alle Fehler über die Steuerebene von Kubernetes.
Entwurfsmuster, auf die über einen Load Balancer mit Computing-Clustern zugegriffen wird, sollten Auto Scaling-Gruppen nutzen. Elastic Load Balancing (ELB) verteilt den eingehenden Datenverkehr von Anwendungen automatisch auf mehrere Ziele und virtuelle Appliances in einer oder mehreren Availability Zones (AZs).
Bei Cluster-Compute-Instances, die kein Load Balancing nutzen, sollte die Größe für den Verlust von mindestens einem Knoten ausgelegt sein. Auf diese Weise kann der Service mit möglicherweise reduzierter Kapazität weiterlaufen, während er einen neuen Knoten wiederherstellt. Beispiele für Services sind Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK und Amazon OpenSearch Service. Viele dieser Services können mit zusätzlichen Funktionen zur Selbstheilung ausgestattet werden. Einige Cluster-Technologien müssen beim Verlust eines Knotens einen Alarm generieren, der einen automatisierten oder manuellen Workflow zur Wiederherstellung eines neuen Knotens auslöst. Dieser Workflow kann mit AWS Systems Manager automatisiert werden, um Probleme schnell zu beheben.
Mit Amazon EventBridge lassen sich Ereignisse wie CloudWatch-Alarme oder Statusänderungen in anderen AWS-Services überwachen und filtern. Auf der Grundlage von Ereignisinformationen kann er dann AWS Lambda, Systems Manager Automation oder andere Ziele aufrufen, um eine angepasste Abhilfelogik für Ihren Workload auszuführen. Amazon EC2 Auto Scaling kann so konfiguriert werden, dass der Status der EC2-Instance überprüft wird. 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. Bei Large-Scale-Ersetzungen (z. B. dem Verlust einer ganzen Availability Zone) ist für eine Hochverfügbarkeit die statische Stabilität vorzuziehen.
### Implementierungsschritte
+ Verwenden Sie Auto Scaling-Gruppen, um Tiers in einem Workload bereitzustellen. [Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) kann zustandslose Anwendungen selbst reparieren und Kapazitäten hinzufügen oder entfernen.
+ Für die bereits erwähnten Computing-Instances verwenden Sie [Load Balancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) und wählen Sie den entsprechenden von Load-Balancer-Typ aus.
+ Erwägen Sie die Reparatur für Amazon RDS. Bei Standby-Instances konfigurieren Sie [den automatischen Failover](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) auf die Standby-Instance. Bei Amazon RDS-Lesereplikaten ist ein automatisierter Workflow erforderlich, um ein Lesereplikat zur primären Instance zu machen.
+ Implementieren Sie die [automatische Wiederherstellung auf EC2-Instances,](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) die Anwendungen bereitstellen, die nicht an mehreren Standorten bereitgestellt werden können und die einen Neustart bei Fehlern tolerieren können. 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 [EBS-Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) und Einbindungspunkte für [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) oder [Dateisysteme für Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) und [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Mit [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)können Sie die automatische Wiederherstellung von EC2-Instances auf Layer-Ebene konfigurieren.
+ Implementieren Sie die automatische Wiederherstellung mit [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) und [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) wenn Sie keine automatische Skalierung oder automatische Wiederherstellung verwenden können oder wenn 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.
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) kann verwendet werden, um Ereignisse zu überwachen und zu filtern, wie [CloudWatch-Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) oder Zustandsänderungen in anderen AWS-Services. Auf der Grundlage von Ereignisinformationen kann es dann AWS Lambda (oder andere Ziele) aufrufen, um eine angepasste Wiederherstellungslogik für Ihren Workload auszuführen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [Definition der Verfügbarkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Zugehörige Dokumente:**
+ [So funktioniert AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Automatische Wiederherstellung mit 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 for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Was ist Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [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)
+ [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)
+ [Amazon RDS-Failover](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM – Systems Manager-Automatisierung](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [Bewährte Methoden für eine widerstandsfähige Architektur](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**Zugehörige Videos:**
+ [Automatically Provision and Scale OpenSearch Service (OpenSearch automatisch Bereitstellen und skalieren)](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Automatischer Failover mit Amazon RDS](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**Zugehörige Beispiele:**
+ [Workshop zu Auto Scaling](https://catalog.workshops.aws/general-immersionday/en-US/advanced-modules/compute/auto-scaling)
+ [Amazon RDS-Failover Workshop](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**Zugehörige Tools:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung
Steuerebenen stellen die administrativen APIs zum Erstellen, Lesen und Schreiben, Aktualisieren, Löschen und Auflisten (CRUDL) von Ressourcen bereit, während Datenebenen den normalen Datenverkehr des Services abwickeln. Konzentrieren Sie sich bei der Implementierung von Wiederherstellungs- oder Abhilfemaßnahmen für Ereignisse, die sich möglicherweise auf die Ausfallsicherheit auswirken, auf eine minimale Anzahl von Operationen auf der Steuerebene, um den Service wiederherzustellen, zu skalieren, zu reparieren oder einen Failover durchzuführen. Aktionen auf der Datenebene sollten während dieser Beeinträchtigungen Vorrang vor allen anderen Aktivitäten haben.
Die folgenden Aktionen gehören beispielsweise alle zur Steuerebene: Starten einer neuen Computing-Instance, Erstellen von Block-Speicher und Beschreiben von Warteschlangen-Services. Wenn Sie Computing-Instances starten, muss die Steuerebene mehrere Aufgaben erfüllen, z. B. einen physischen Host mit Kapazität finden, Netzwerkschnittstellen zuweisen, lokale Block-Speicher-Volumes vorbereiten, Anmeldeinformationen generieren und Sicherheitsregeln hinzufügen. Steuerebenen neigen zu einer komplizierten Orchestrierung.
**Gewünschtes Ergebnis:** Wenn bei einer Ressource eine Störung auftritt, ist das System in der Lage, diese automatisch oder manuell zu beheben, indem es den Datenverkehr von gestörten auf intakte Ressourcen umleitet.
**Typische Anti-Muster:**
+ Abhängigkeit von der Änderung von DNS-Einträgen, um den Datenverkehr umzuleiten.
+ Abhängigkeit von Skalierungsoperationen auf Steuerebene, um beeinträchtigte Komponenten aufgrund einer unzureichenden Bereitstellung von Ressourcen zu ersetzen.
+ Abhängigkeit von umfangreichen Aktionen auf der Steuerebene, in die mehrere Services und APIs involviert sind, um Störungen jeglicher Art zu beheben.
**Vorteile der Nutzung dieser bewährten Methode:** Eine höhere Erfolgsquote bei der automatisierten Behebung kann Ihre mittlere Zeit bis zur Wiederherstellung verkürzen und die Verfügbarkeit des Workloads verbessern.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel: Bei bestimmten Arten von Service-Störungen sind die Steuerebenen betroffen. Die Abhängigkeit von einer umfassenden Nutzung der Steuerebene für die Behebung kann die Wiederherstellungszeit (RTO) und die mittlere Zeit bis zur Wiederherstellung (MTTR) erhöhen.
## Anleitung zur Umsetzung
Um die Aktionen auf der Datenebene zu begrenzen, bewerten Sie für jeden Service, welche Aktionen zur Wiederherstellung des Services erforderlich sind.
Nutzen Sie Amazon Application Recovery Controller (ARC), um den DNS-Datenverkehr zu verlagern. Diese Funktionen überwachen kontinuierlich die Fähigkeit Ihrer Anwendung, nach Fehlern wiederhergestellt zu werden, und ermöglichen es Ihnen, die Wiederherstellung Ihrer Anwendung über mehrere AWS-Regionen, Availability Zones und On-Premises zu steuern.
Route 53-Routingrichtlinien verwenden die Steuerebene. Verlassen Sie sich also bei der Wiederherstellung nicht auf diese Ebene. Die Route 53-Datenebenen beantworten DNS-Abfragen und führen Zustandsprüfungen durch und werten diese aus. Sie sind global verteilt und für ein [Service Level Agreement (SLA) mit einer Verfügbarkeit von 100 % entworfen worden](https://aws.amazon.com/route53/sla/).
Die Route 53-Verwaltungs-APIs und -Konsolen, über die Sie Route 53-Ressourcen erstellen, aktualisieren und löschen, arbeiten auf Steuerebenen, die so konzipiert sind, dass die starke Konsistenz und Stabilität, die Sie beim Verwalten von DNS benötigen, Priorität haben. Zu diesem Zweck befinden sich die Steuerebenen in einer einzelnen Region, USA Ost (Nord-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.
Verwenden Sie für Amazon EC2 Designs mit statischer Stabilität, um Aktionen auf der Steuerebene zu begrenzen. Zu den Aktionen auf der Steuerebene gehört das Hochskalieren von Ressourcen einzeln oder über Auto Scaling-Gruppen (ASG). Für ein Höchstmaß an Ausfallsicherheit stellen Sie ausreichende Kapazitäten in dem für den Failover verwendeten Cluster bereit. Wenn diese Kapazität begrenzt werden muss, legen Sie Drosselungen für das gesamte System fest, um den Gesamtdatenverkehr an die beschränkte Ressourcenmenge sicher zu begrenzen.
Bei Services wie Amazon DynamoDB, Amazon API Gateway, Load Balancern und AWS Lambda Serverless wird die Datenebene für diese Services genutzt. Die Erstellung neuer Funktionen, Load Balancers, API-Gateways oder DynamoDB-Tabellen ist jedoch eine Aktion auf der Steuerebene und sollte vor der Störung als Vorbereitung auf ein Ereignis und zum Üben von Failover-Aktionen durchgeführt werden. Für Amazon RDS ermöglichen Aktionen auf der Datenebene den Zugriff auf Daten.
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/).
Erfahren Sie, welche Operationen auf der Datenebene und welche Operationen auf der Steuerebene ausgeführt werden.
### Implementierungsschritte
Bewerten Sie für jeden Workload, der nach einem Störfall wiederhergestellt werden muss, das Failover-Runbook, das Hochverfügbarkeitsdesign, das Auto Healing Design oder den Plan zur Wiederherstellung von HA-Ressourcen. Identifizieren Sie jede Aktion, die als Aktion auf der Steuerebene in Frage kommt.
Ziehen Sie in Erwägung, eine Aktion auf der Steuerebene in eine Aktion auf der Datenebene umzuwandeln:
+ Auto Scaling (Steuerebene) im Vergleich zu vorab skalierten Amazon EC2-Ressourcen (Datenebene)
+ Migrieren Sie zu Lambda und seinen Skalierungsmethoden (Datenebene) oder Amazon EC2 und ASG (Steuerebene)
+ Bewerten Sie alle Entwürfe unter Verwendung von Kubernetes und der Art der Aktionen auf der Steuerebene. Das Hinzufügen von Pods ist eine Aktion auf der Datenebene von Kubernetes. Aktionen sollten sich auf das Hinzufügen von Pods und nicht von Knoten beschränken. Mit [der Verwendung von überdimensionierten Knoten](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) ist die bevorzugte Methode zur Begrenzung von Aktionen auf der Steuerebene.
Ziehen Sie alternative Ansätze in Betracht, bei denen Aktionen auf der Datenebene dieselbe Maßnahme bewirken können.
+ Route 53 Record change (control plane) or ARC (data plane) (Route 53-Datensatzänderung (Steuerebene) oder Route 53 ARC (Datenebene))
+ [ Route 53 Health checks for more automated updates (Route 53-Zustandsprüfungen für weitere automatisierte Aktualisierungen) ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
Ziehen Sie einige Services in einer sekundären Region in Betracht, wenn der Service geschäftskritisch ist, um mehr Aktionen auf der Steuerebene und Datenebene in einer nicht betroffenen Region zu ermöglichen.
+ Amazon EC2 Auto Scaling oder Amazon EKS in einer primären Region im Vergleich zu Amazon EC2 Auto Scaling oder Amazon EKS in einer sekundären Region und Routing des Datenverkehrs zur sekundären Region (Aktion auf Steuerebene)
+ Ein Lesereplikat in der sekundären primären Region erstellen oder Versuchen derselben Aktion in der primären Region (Aktion auf der Steuerebene)
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [Definition der Verfügbarkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Zugehörige 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) (aufgeteilt in die Steuerebene und die Datenebene)
+ [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 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)
+ [ Kubernetes-Steuerebene und -Datenebene ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**Zugehörige Videos:**
+ [ Back to Basics – Using Static Stability (Zurück zu den Basics – Verwendung statischer Stabilität) ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Building resilient multi-site workloads using AWS global services (Aufbau belastbarer Workloads an mehreren Standorten mit globalen AWS-Services) ](https://www.youtube.com/watch?v=62ZQHTruBnk)
**Zugehörige Beispiele:**
+ [Vorstellung von Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [ 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/)
+ [ 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 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/)
+ [ Statische Stabilität mithilfe von Availability Zones ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**Zugehörige Tools:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität
Workloads sollten statisch stabil sein und nur in einem einzigen Normalmodus ausgeführt werden. Bimodales Verhalten liegt vor, wenn sich der Workload im Normalmodus und im Fehlermodus unterschiedlich verhält.
Sie können beispielsweise versuchen, nach einem Ausfall der Availability Zone eine Wiederherstellung durchzuführen, indem Sie neue Instances in einer anderen Availability Zone starten. Dies kann zu einer bimodalen Reaktion während eines Ausfallmodus führen. Stattdessen sollten Sie Workloads erstellen, die statisch stabil sind und nur in einem Modus betrieben werden. In diesem Beispiel hätten diese Instances vor dem Ausfall in der zweiten Availability Zone bereitgestellt werden sollen. Dieses statische Stabilitätsdesign verifiziert, dass der Workload nur in einem einzigen Modus ausgeführt wird.
**Gewünschtes Ergebnis:** Workloads zeigen im Normalmodus und im Fehlermodus kein bimodales Verhalten.
**Typische Anti-Muster:**
+ Es wird davon ausgegangen, dass Ressourcen unabhängig vom Umfang des Fehlers immer bereitgestellt werden können.
+ Während eines Fehlers wird versucht, dynamisch Ressourcen zu erwerben.
+ Es werden keine ausreichenden Ressourcen für Zonen oder Regionen bereitgestellt, bis ein Fehler auftritt.
+ Statische stabile Designs werden nur für Rechenressourcen in Erwägung gezogen.
**Vorteile der Nutzung dieser bewährten Methode:** Workloads, die mit statisch stabilen Designs ausgeführt werden, sind in der Lage, bei normalen Ereignissen und bei Ausfällen vorhersehbare Ergebnisse erzielen.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel
## Implementierungsleitfaden
Bimodales Verhalten bedeutet, dass ein Workload im normalen Modus und im Fehlermodus unterschiedliche Verhaltensweisen zeigt (z. B. Verlassen auf den Start neuer Instances bei Ausfall einer Availability Zone). Ein Beispiel für bimodales Verhalten ist, wenn stabile Elastic Load Balancing-Designs genügend Instances in jeder Availability Zone bereitstellen, so dass 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. 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. Statische Stabilität für die Bereitstellung von Rechenleistung (z. B. EC2-Instances oder -Container) führt zu höchster Zuverlässigkeit.
![\[Diagramm: Statische Stabilität von EC2-Instances in Availability Zones\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/static-stability.png)
Dies muss gegen die Kosten für dieses Modell und den geschäftlichen Nutzen der Aufrechterhaltung des Workloads in allen Ausfallsituationen abgewogen werden. Es ist kostengünstiger, weniger Rechenkapazität bereitzustellen und bei einem Ausfall neue Instances zu starten. Bei großen Ausfällen (z. B. bei Beeinträchtigung einer Availability Zone oder Region) ist dieser Ansatz jedoch weniger effektiv, da er sowohl auf einer Betriebsebene als auch auf der Verfügbarkeit ausreichender Ressourcen in den nicht betroffenen Zonen oder Regionen beruht.
Ihre Lösung sollte die Anforderungen an die Zuverlässigkeit und Kosten für Ihren Workload gegeneinander abwägen. Ansätze mit statischer Stabilität gelten für eine Vielzahl von Architekturen, darunter Computing-Instances, die über Availability Zones verteilt sind, Designs mit Lesereplikaten für Datenbanken, Kubernetes (Amazon EKS)-Clusterdesigns und Failover-Architekturen für mehrere Regionen.
Es ist auch möglich, ein statisch stabileres Design zu implementieren, indem mehr Ressourcen in jeder Zone verwendet werden. Wenn Sie eine größere Anzahl von Zonen hinzufügen, verringert sich die Menge der zusätzlichen Rechenleistung, die Sie für die statische Stabilität benötigen.
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 zur unerwarteten Auslastung einer anderen Komponente führen, die daraufhin ausfallen könnte, was möglicherweise weitere unerwartete Konsequenzen nach sich zieht. Diese negative Feedback-Schleife wirkt sich auf die Verfügbarkeit Ihres Workloads aus. Deshalb sollten Sie stattdessen Systeme erstellen, die statisch stabil sind und nur in einem Modus betrieben werden. Ein statisch stabiles Design arbeitet konstant und aktualisiert den Konfigurationsstatus in regelmäßigen Abständen. Wenn ein Aufruf fehlschlägt, verwendet der 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, sie kann aber die Belastung Ihres Workloads erheblich ändern und führt wahrscheinlich zu Fehlern.
Bewerten Sie kritische Workloads, um festzustellen, für welche Workloads diese Art von Resilienzentwurf erforderlich ist. Für diejenigen, die als kritisch eingestuft werden, muss jede Anwendungskomponente überprüft werden. Beispiele für Services, für die statische Stabilitätsbewertungen erforderlich sind:
+ **Datenverarbeitung**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2
+ **Datenbanken**: Amazon Redshift, Amazon RDS, Amazon Aurora
+ **存储**: Amazon S3 (eine Zone), Amazon EFS (Bereitstellungen), Amazon FSx (Bereitstellungen)
+ **Load Balancer:** Unter bestimmten Designs
### Implementierungsschritte
+ Erstellen Sie Systeme, die statisch stabil sind und nur in einem einzigen Modus ausgeführt werden. Stellen Sie in diesem Fall in jeder Availability Zone oder Region genügend Instances bereit, um die Workload-Kapazität zu bewältigen, falls eine Availability Zone oder Region entfernt würde. Eine Vielzahl von Services kann für das Routing zu intakten Ressourcen verwendet werden, z. B.:
+ [Regionsübergreifendes DNS-Routing](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP-Amazon S3-Routing mit mehreren Regionen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ Konfigurieren Sie [Datenbank-Read-Replikate,](https://aws.amazon.com/rds/features/multi-az/) um den Verlust einer einzelnen primären Instance oder einer Read Replica zu berücksichtigen. Wenn der Datenverkehr von Lesereplikaten bedient wird, sollte die Menge in jeder Availability Zone und jeder Region dem Gesamtbedarf im Fall eines Zonen- oder Regionsausfalls entsprechen.
+ Konfigurieren Sie kritische Daten in einem Amazon S3-Speicher, der so konzipiert ist, dass er für die gespeicherten Daten beim Ausfall einer Availability Zone statisch stabil ist. Wenn [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) Speicherklasse verwendet wird, sollte diese nicht als statisch stabil angesehen werden, da der Ausfall dieser Zone den Zugriff auf die zugehörigen gespeicherten Daten minimiert.
+ [Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) sind manchmal falsch oder so konfiguriert, dass sie eine bestimmte Availability Zone bedienen. In diesem Fall könnte das statisch stabile Design darin bestehen, einen Workload über mehrere AZs in einem komplexeren Design zu verteilen. Das ursprüngliche Design kann aus Sicherheits-, Latenz- oder Kostengründen verwendet werden, um den Verkehr zwischen den Zonen zu reduzieren.
## Ressourcen
**Zugehörige bewährte Methoden für Well-Architected:**
+ [Definition der Verfügbarkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**Zugehörige 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)
+ [Fault Isolation Boundaries (Grenzen für die Fehlerisolierung)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [Statische Stabilität mithilfe von Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Multi-Zone RDS (RDS für mehrere Zonen)](https://aws.amazon.com/rds/features/multi-az/)
+ [Minimierung der Abhängigkeiten bei der Planung der Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Regionsübergreifendes DNS-Routing](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP-Amazon S3-Routing mit mehreren Regionen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Amazon S3 mit einer Zone](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [Cross Zone Load Balancing (Zonenübergreifender Lastenausgleich)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**Zugehörige Videos:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328) (Statische Stabilität in AWS: AWS re:Invent 2019: Einführung der Amazon Builders' Library (DOP328))](https://youtu.be/sKRdemSirDM?t=704)
**Zugehörige Beispiele:**
+ [Die Amazon Builders' Library: Statische Stabilität durch Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
# REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken
Benachrichtigungen werden nach Erkennung von Schwellenwertüberschreitungen gesendet, auch wenn das durch das Ereignis verursachte Problem automatisch behoben wurde.
Auto Healing sorgt dafür, dass Ihr 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.
Resiliente Systeme sind so konzipiert, dass Verschlechterungsereignisse sofort an die entsprechenden Teams gemeldet werden. Diese Benachrichtigungen sollten über einen oder mehrere Kommunikationskanäle gesendet werden.
**Gewünschtes Ergebnis: **Bei Überschreitung von Schwellenwerten wie Fehlerraten, Latenz oder anderen kritischen Leistungsindikatoren (KPIs) werden sofort Benachrichtigungen an die Betriebsteams gesendet, sodass diese Probleme so schnell wie möglich behoben und Auswirkungen auf die Benutzer vermieden oder minimiert werden.
**Typische Anti-Muster:**
+ Es werden zu viele Alarme gesendet.
+ Es werden Alarme gesendet, die keine Maßnahmen erfordern.
+ Die Schwellenwerte für den Alarm sind zu hoch (überempfindlich) oder zu niedrig (nicht empfindlich genug).
+ Es werden keine Alarme für externe Abhängigkeiten gesendet.
+ Nicht berücksichtigt werden die [grauen Fehler](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) bei der Gestaltung von Überwachung und Alarmen.
+ Es werden automatische Reparaturen ausgeführt, ohne das entsprechende Team darüber zu benachrichtigen, dass eine Reparatur erforderlich war.
**Vorteile der Nutzung dieser bewährten Methode:** Durch Benachrichtigungen über die Wiederherstellung werden Betriebs- und Geschäftsteams über Service-Einschränkungen informiert, sodass sie sofort reagieren können, um sowohl die mittlere Zeit zur Erkennung (Mean Time to Detect, MTTD) als auch die mittlere Wiederherstellungszeit (Mean Time to Repair, MTTR) zu minimieren. Benachrichtigungen zu Wiederherstellungen stellen sicher, dass Sie selten auftretende Probleme nicht ignorieren.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel. Wenn keine geeigneten Überwachungsfunktionen und Mechanismen zur Benachrichtigung bei Ereignissen implementiert werden, kann dies dazu führen, dass Problemmuster nicht erkannt werden, einschließlich solcher, die durch Auto Healing behoben werden. Ein Team wird nur dann auf eine Verschlechterung des Systems aufmerksam gemacht, wenn Benutzer den Kundendienst kontaktieren oder der Fehler zufällig bemerkt wird.
## Implementierungsleitfaden
Bei der Definition einer Überwachungsstrategie ist ein ausgelöster Alarm ein häufiges Ereignis. Dieses Ereignis würde wahrscheinlich eine Kennung für den Alarm enthalten, den Alarmstatus (z. B. `ALARM AKTIV` oder `OK`) und Einzelheiten darüber, was ihn ausgelöst hat. In vielen Fällen sollte ein Alarmereignis erkannt und eine E-Mail-Benachrichtigung gesendet werden. Dies ist ein Beispiel für eine Aktion bei einem Alarm. Die Alarmbenachrichtigung ist für die Beobachtbarkeit von entscheidender Bedeutung, da hiermit die richtigen Personen darüber informiert werden, dass ein Problem vorliegt. Wenn die Aktionen bei Ereignissen in Ihrer Lösung für die Beobachtbarkeit ausgereift sind, kann das Problem automatisch behoben werden, ohne dass menschliches Eingreifen erforderlich ist.
Sobald Alarme zur KPI-Überwachung eingerichtet wurden, sollten die entsprechenden Teams Warnmeldungen erhalten, wenn Schwellenwerte überschritten werden. Diese Warnungen können auch verwendet werden, um automatisierte Prozesse auszulösen, die versuchen, die Verschlechterung zu beheben.
Für eine komplexere Schwellenwertüberwachung sollten zusammengesetzte Alarme in Betracht gezogen werden. Zusammengesetzte Alarme verwenden eine Reihe von Alarmen zur KPI-Überwachung, um eine Warnung auf Grundlage der Geschäftslogik zu erstellen. CloudWatch-Alarme können so konfiguriert werden, dass E-Mails gesendet oder Vorfälle mithilfe der Amazon SNS-Integration oder Amazon EventBridge in Drittanbietersystemen zur Nachverfolgung von Vorfällen protokolliert werden.
### Implementierungsschritte
Erstellen Sie verschiedene Arten von Alarmen, je nachdem, wie Workloads überwacht werden, z. B.:
+ Anwendungsalarme werden verwendet, um zu erkennen, wenn ein Teil des Workloads nicht ordnungsgemäß funktioniert.
+ [Alarme für die Infrastruktur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) geben an, wann Ressourcen skaliert werden sollen. Alarme können visuell in Dashboards angezeigt werden, Warnungen per Amazon SNS oder E-Mail senden und mit Auto Scaling die Ressourcen für einen Workload hoch- oder herunterskalieren.
+ Einfache [statische Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) können erstellt werden, um zu überwachen, wann eine Metrik für eine bestimmte Anzahl von Bewertungszeiträumen einen statischen Schwellenwert überschreitet.
+ [Zusammengesetzte Alarme,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) können komplexe Alarme aus mehreren Quellen berücksichtigen.
+ Nachdem der Alarm erstellt wurde, erstellen Sie entsprechende Benachrichtigungsereignisse. Sie können direkt eine [Amazon SNS-API aufrufen,](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) um Benachrichtigungen zu senden und alle Automatisierungen zur Behebung oder Kommunikation zu verknüpfen.
+ Setzen Sie [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) Überwachung, um die Überwachung von AWS-Ressourcen zu ermöglichen, bei denen es zu Leistungseinbußen kommen könnte. Für geschäftskritische Workloads bietet diese Lösung Zugriff auf proaktive und Echtzeitbenachrichtigungen für AWS-Services.
## Ressourcen
**Zugehörige bewährte Methoden für Well-Architected:**
+ [Definition der Verfügbarkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
**Zugehörige 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)
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Using Amazon CloudWatch Alarms (Verwenden von Amazon CloudWatch-Alarmen)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/)
+ [Einrichten von zusammengesetzten CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [Neuheiten im Bereich AWS-Beobachtbarkeit bei der re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**Zugehörige Tools:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 Architektur Ihres Produkts zur Erfüllung von Verfügbarkeitszielen und Uptime-SLAs (Service Level Agreements)
Entwerfen Sie Ihr Produkt zur Erfüllung der Verfügbarkeitsziele und der Uptime-SLAs (Service Level Agreements). Wenn Sie Verfügbarkeitsziele oder Uptime-SLAs veröffentlichen oder privat vereinbaren, stellen Sie sicher, dass Ihre Architektur und Ihre operativen Prozesse so konzipiert sind, dass sie diese unterstützen.
**Gewünschtes Ergebnis:** Jede Anwendung hat ein definiertes Ziel für die Verfügbarkeit und eine SLA für Leistungsmetrik, die überwacht und aufrechterhalten werden können, um die Geschäftsziele zu erreichen.
**Typische Anti-Muster:**
+ Entwurf und Bereitstellung von Workloads ohne Einstellung von SLAs.
+ SLA-Metriken werden ohne Begründung oder geschäftliche Anforderungen zu hoch angesetzt.
+ SLAs werden ohne Berücksichtigung von Abhängigkeiten und den ihnen zugrunde liegenden SLAs festgelegt.
+ Anwendungsdesigns werden ohne Berücksichtigung des Modells der geteilten Verantwortung für die Ausfallsicherheit erstellt.
**Vorteile der Nutzung dieser bewährten Methode:** Die Entwicklung von Anwendungen auf der Grundlage von Schlüsselzielen für die Ausfallsicherheit hilft Ihnen, Geschäftsziele und Kundenerwartungen zu erfüllen. Diese Ziele sind die Grundlage für die Entwicklung von Anwendungen, bei der verschiedene Technologien bewertet und verschiedene Kompromisse in Betracht gezogen werden.
## Implementierungsleitfaden
Bei der Entwicklung von Anwendungen müssen Sie eine Reihe von Anforderungen berücksichtigen, die sich aus geschäftlichen, operativen und finanziellen Zielen ergeben. Im Rahmen der operativen Anforderungen müssen für Workloads spezifische Metriken für die Ausfallsicherheit festgelegt werden, damit sie angemessen überwacht und unterstützt werden können. Die Metriken für die Ausfallsicherheit sollten nicht nach der Bereitstellung des Workloads festgelegt oder ermittelt werden. Sie sollten in der Entwurfsphase festgelegt werden und als Leitlinien für verschiedene Entscheidungen und Abwägungen dienen.
+ Jeder Workload sollte seine eigenen Metriken für die Ausfallsicherheit haben. Diese Metriken können sich von anderen geschäftlichen Anwendungen unterscheiden.
+ Die Reduzierung von Abhängigkeiten kann sich positiv auf die Verfügbarkeit auswirken. Jeder Workload sollte seine Abhängigkeiten und deren SLAs berücksichtigen. Wählen Sie im Allgemeinen Abhängigkeiten mit Verfügbarkeitszielen aus, die den Zielen Ihres Workloads entsprechen oder höher sind.
+ Ziehen Sie eine lose Kopplung in Betracht, damit Ihr Workload trotz der Beeinträchtigung durch Abhängigkeiten korrekt arbeiten kann, sofern dies möglich ist.
+ Reduzieren Sie die Abhängigkeiten auf der Steuerebene, insbesondere während der Wiederherstellung oder einer Beeinträchtigung. Evaluieren Sie Designs, die für geschäftskritische Workloads statisch stabil sind. Nutzen Sie den sparsamen Umgang mit Ressourcen, um die Verfügbarkeit dieser Abhängigkeiten in einem Workload zu erhöhen.
+ Die Überwachbarkeit und die Instrumentierung sind entscheidend für das Erreichen von SLAs. Sie reduzieren die Mean Time to Detection (MTTD) und die Mean Time to Repair (MTTR).
+ Weniger häufige Störungen (längere MTBF), kürzere Fehlererkennungszeiten (kürzere MTTD) und kürzere Reparaturzeiten (kürzere MTTR) sind die drei Faktoren, die zur Verbesserung der Verfügbarkeit in verteilten Systemen eingesetzt werden.
+ Das Festlegen und Einhalten von Metriken für die Ausfallsicherheit eines Workloads ist eine der Grundlagen für jedes effektive Design. Diese Entwürfe müssen Kompromisse in Bezug auf Designkomplexität, Service-Abhängigkeiten, Leistung, Skalierung und Kosten berücksichtigen.
**Implementierungsschritte**
+ Überprüfen und dokumentieren Sie den Workload-Entwurf unter Berücksichtigung der folgenden Fragen:
+ Wo werden die Steuerebenen im Workload verwendet?
+ Wie implementiert der Workload die Ausfallsicherheit?
+ Wie sehen die Entwurfsmuster für die Skalierung, automatische Skalierung, Redundanz und hochverfügbare Komponenten aus?
+ Welche Anforderungen gibt es an die Datenkonsistenz und -verfügbarkeit?
+ Gibt es Überlegungen zur sparsamen Nutzung von Ressourcen oder zur statischen Stabilität von Ressourcen?
+ Welche Abhängigkeiten bestehen zwischen den Services?
+ Definieren Sie in Zusammenarbeit mit den Stakeholdern SLA-Metriken auf der Grundlage der Workload-Architektur. Berücksichtigen Sie die SLAs aller Abhängigkeiten, die der Workload nutzt.
+ Sobald das SLA-Ziel festgelegt ist, optimieren Sie die Architektur, um die SLA zu erfüllen.
+ Sobald das Design festgelegt ist, das die SLA erfüllt, implementieren Sie operative Änderungen, Prozessautomatisierungen und Runbooks, die ebenfalls auf die Reduzierung von MTTD und MTTR ausgerichtet sind.
+ Sobald die Bereitstellung erfolgt ist, überwachen Sie die SLA und erstatten Sie darüber Bericht.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Bereitstellen des Workloads an mehreren Standorten](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatisieren der Reparatur auf allen Ebenen](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testen der Ausfallsicherheit mit Chaos-Engineering](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md)
+ [ Grundlegendes zum Workload-Status ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Zugehörige Dokumente:**
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Verfügbarkeit mit Redundanz)
+ [ Zuverlässigkeitssäule – Verfügbarkeit ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Measuring availability ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html) (Messung der Verfügbarkeit)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (AWS-Grenzen für die Fehlerisolierung)
+ [ Modell der geteilten Verantwortung für Ausfallsicherheit ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [Statische Stabilität mithilfe von Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS Service Level Agreements (SLAs)](https://aws.amazon.com/legal/service-level-agreements/)
+ [ Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/) (Leitfaden für eine zellenbasierte Architektur auf AWS)
+ [AWS-Infrastruktur ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Advanced Multi-AZ Resiliance Patterns whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html) (Whitepaper: Fortschrittliche Multi-AZ-Resiliance-Muster)
**Zugehörige Services:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)