Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # AWS Arten von Dienstleistungen AWS betreibt drei verschiedene Kategorien von Diensten auf der Grundlage ihrer Grenze zur Fehlerisolierung: zonal, regional und global. In diesem Abschnitt wird detaillierter beschrieben, wie diese verschiedenen Arten von Diensten konzipiert wurden, sodass Sie feststellen können, wie sich Ausfälle innerhalb eines Dienstes eines bestimmten Diensttyps auf AWS Ihre ausgeführte Arbeitslast auswirken. Es enthält auch allgemeine Anleitungen dazu, wie Sie Ihre Workloads so gestalten können, dass Sie diese Dienste auf ausfallsichere Weise nutzen können. Für globale Services bietet dieses Dokument auch präskriptive Anleitungen, die Ihnen helfen können[Anhang B — Globale Servicehinweise für Edge-Netzwerke](appendix-b---edge-network-global-service-guidance.md), Auswirkungen auf Ihre Workloads durch Beeinträchtigungen der Steuerungsebene bei Services zu verhindern. So können Sie Abhängigkeiten von globalen AWS Diensten sicher eingehen und gleichzeitig die Entstehung einzelner Ausfallpunkte minimieren. [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md) **Topics** + [Zonale Dienste](zonal-services.md) + [Regionale Dienste](regional-services.md) + [Weltweite Dienste](global-services.md) # Zonale Dienste [https://aws.amazon.com/builders-library/static-stability-using-availability-zones/](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI) AWS ermöglicht das Anbieten zonaler Dienste wie Amazon EC2 und AmazonEBS. Ein zonaler Service bietet die Möglichkeit, anzugeben, in welcher Availability Zone die Ressourcen bereitgestellt werden. Diese Dienste werden unabhängig in jeder Availability Zone innerhalb einer Region betrieben und, was noch wichtiger ist, sie fallen auch unabhängig voneinander in jeder Availability Zone aus. Das bedeutet, dass Komponenten eines Dienstes in einer Availability Zone nicht von Komponenten in anderen Availability Zones abhängig sind. Das ist möglich, weil ein zonaler Dienst über **zonale Datenebenen** verfügt. In einigen Fällen, wie z. B. beiEC2, umfasst der Service auch zonale Steuerungsebenen für zonal ausgerichtete Operationen, wie z. B. das Starten einer Instance. EC2 Für diese Dienste bietet er AWS außerdem einen regionalen Kontrollebenen-Endpunkt, um die Interaktion mit dem Service zu vereinfachen. Die regionale Kontrollebene bietet auch Funktionen mit regionalem Geltungsbereich und dient als Aggregations- und Routing-Ebene über den zonalen Kontrollebenen. Dies wird in der folgenden Abbildung dargestellt. ![\[Dieses Bild zeigt einen zonalen Dienst mit zonal isolierten Steuerungsebenen und Datenebenen\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png) Availability Zones bieten Kunden die Möglichkeit, Produktionsworkloads zu betreiben, die höher verfügbar, fehlertoleranter und skalierbarer sind, als dies von einem einzigen Rechenzentrum aus möglich wäre. Wenn ein Workload mehrere Availability Zones verwendet, sind Kunden besser isoliert und vor Problemen geschützt, die sich auf die physische Infrastruktur einer einzelnen Availability Zone auswirken. Auf diese Weise können Kunden Dienste einrichten, die in allen Availability Zones redundant sind und bei richtiger Architektur auch dann betriebsbereit bleiben, wenn eine Availability Zone ausfällt. Kunden können die Vorteile nutzenAZI, um hochverfügbare und belastbare Workloads zu erstellen. Durch die Implementierung AZI in Ihre Architektur können Sie sich nach einem isolierten Ausfall der Availability Zone schnell erholen, da Ihre Ressourcen in einer Availability Zones die Interaktion mit Ressourcen in anderen Availability Zones minimieren oder ganz ausschließen. Auf diese Weise können Abhängigkeiten zwischen verschiedenen Availability Zones entfernt werden, was die Evakuierung von Availability Zones vereinfacht. Weitere Informationen zur Erstellung von Evakuierungsmechanismen für Availability Zones finden Sie unter [Advanced Multi-AZ Resilience Patterns](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html). Darüber hinaus können Sie die Vorteile von Availability Zones weiter nutzen, indem Sie einige der bewährten Methoden anwenden, die auch für die eigenen Dienste AWS verwendet werden. So können Sie z. B. jeweils nur Änderungen an einer einzigen Availability Zone vornehmen oder eine Availability Zone aus dem Dienst entfernen, wenn eine Änderung in dieser Availability Zone fehlschlägt. [Statische Stabilität](static-stability.md) ist auch ein wichtiges Konzept für Architekturen mit mehreren Verfügbarkeitszonen. Einer der Ausfallmodi, die Sie bei Architekturen mit mehreren Verfügbarkeitszonen einplanen sollten, ist der Verlust einer Availability Zone, was zum Verlust der Kapazität einer Availability Zone führen kann. Wenn Sie nicht im Voraus genügend Kapazität bereitgestellt haben, um den Verlust einer Availability Zone zu bewältigen, kann dies dazu führen, dass Ihre verbleibende Kapazität durch die aktuelle Auslastung überlastet wird. Darüber hinaus müssen Sie sich auf die Steuerungsebenen der zonalen Dienste verlassen, die Sie verwenden, um diese verlorene Kapazität zu ersetzen, was weniger zuverlässig sein kann als ein statisch stabiles Design. In diesem Fall kann die Bereitstellung ausreichender zusätzlicher Kapazität dazu beitragen, dass Sie auch beim Verlust einer Fehlerdomäne, z. B. einer Availability Zone, statisch stabil bleiben, indem Sie den normalen Betrieb fortsetzen können, ohne dass dynamische Änderungen erforderlich sind. Sie können sich dafür entscheiden, eine Auto Scaling-Gruppe von EC2 Instances zu verwenden, die in mehreren Availability Zones bereitgestellt werden, um je nach den Anforderungen Ihres Workloads dynamisch ein- und auszuskalieren. Auto Scaling eignet sich gut für allmähliche Nutzungsänderungen, die sich über Minuten bis Dutzende von Minuten erstrecken. Das Starten neuer EC2 Instances nimmt jedoch Zeit in Anspruch, insbesondere wenn Ihre Instances Bootstrapping erfordern (z. B. die Installation von Agenten, Anwendungsbinärdateien oder Konfigurationsdateien). Während dieser Zeit könnte Ihre verbleibende Kapazität durch die aktuelle Auslastung überlastet sein. Darüber hinaus hängt die Bereitstellung neuer Instanzen durch Auto Scaling von der EC2 Steuerungsebene ab. Dies stellt einen Kompromiss dar: Um den Verlust einer einzelnen Availability Zone statisch stabil zu halten, müssen Sie genügend EC2 Instances in den anderen Availability Zones vorab bereitstellen, um die Last zu bewältigen, die von der beeinträchtigten Availability Zone wegverlagert wurde, anstatt sich bei der Bereitstellung neuer Instances auf Auto Scaling zu verlassen. Die Vorabbereitstellung zusätzlicher Kapazität kann jedoch zusätzliche Kosten verursachen. Nehmen wir beispielsweise an, dass Ihr Workload bei normalem Betrieb sechs Instances benötigt, um den Kundenverkehr in drei Availability Zones abzuwickeln. Um bei einem Ausfall einer einzelnen Availability Zone statisch stabil zu sein, würden Sie drei Instances in jeder Availability Zone bereitstellen, also insgesamt neun. Wenn eine einzelne Availability Zone-Instances ausfallen würde, hätten Sie immer noch sechs übrig und könnten weiterhin Ihren Kundenverkehr bedienen, ohne während des Ausfalls neue Instances bereitstellen und konfigurieren zu müssen. Die statische Stabilität Ihrer EC2 Kapazität ist mit zusätzlichen Kosten verbunden, da Sie in diesem Fall 50% zusätzliche Instances ausführen. Nicht für alle Dienste, bei denen Sie Ressourcen vorab bereitstellen können, fallen zusätzliche Kosten an, z. B. für die Vorabbereitstellung eines S3-Buckets oder eines Benutzers. Sie müssen alle Kompromisse bei der Implementierung statischer Stabilität gegen das Risiko einer Überschreitung der gewünschten Wiederherstellungszeit für Ihren Workload abwägen. AWS Local Zones und Outposts bringen die Datenebene ausgewählter AWS Dienste näher an die Endbenutzer heran. Die Kontrollebenen für diese Dienste befinden sich in der übergeordneten Region. Ihre Local Zone- oder Outposts-Instance verfügt über Abhängigkeiten EBS auf der Kontrollebene für zonale Dienste wie EC2 und von der Availability Zone, in der Sie Ihre Local Zone oder Ihr Outposts-Subnetz erstellt haben. Sie werden auch von regionalen Kontrollebenen für regionale Dienste wie Elastic Load Balancing (ELB), Sicherheitsgruppen und die von Amazon Elastic Kubernetes Service ([Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html)) verwaltete Kubernetes-Steuerebene (falls Sie diese verwenden) abhängig sein. EKS Weitere spezifische Informationen zu Outposts finden Sie in der [Dokumentation](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html) sowie in der [Support- und FAQ Wartungsabteilung](https://aws.amazon.com/outposts/rack/faqs/). Implementieren Sie statische Stabilität, wenn Sie Local Zones oder Outposts verwenden, um die Widerstandsfähigkeit zu verbessern, um Beeinträchtigungen oder Unterbrechungen der Netzwerkkonnektivität zur übergeordneten Region auf Ebenen zu kontrollieren. # Regionale Dienste Bei regionalen Diensten handelt es AWS sich um Dienste, die auf mehreren Availability Zones aufbauen, sodass Kunden nicht herausfinden müssen, wie sie zonale Dienste optimal nutzen können. Wir gruppieren den Service, der in mehreren Availability Zones bereitgestellt wird, logisch, um den Kunden einen einzigen regionalen Endpunkt zu bieten. Amazon SQS und [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) sind Beispiele für regionale Dienste. Sie nutzen die Unabhängigkeit und Redundanz von Availability Zones, um Infrastrukturausfälle als Kategorie von Verfügbarkeits- und Dauerhaftigkeitsrisiken zu minimieren. Amazon S3 verteilt beispielsweise Anfragen und Daten auf mehrere Availability Zones und ist so konzipiert, dass es nach dem Ausfall einer Availability Zone automatisch wiederhergestellt wird. Sie interagieren jedoch nur mit dem regionalen Endpunkt des Service. AWS ist der Ansicht, dass die meisten Kunden ihre Stabilitätsziele in einer einzelnen Region erreichen können, indem sie regionale Dienste oder Multi-AZ-Architekturen verwenden, die auf zonalen Diensten basieren. Für einige Workloads ist jedoch möglicherweise zusätzliche Redundanz erforderlich, und Sie können die Isolierung von verwenden, um Architekturen mit mehreren Regionen für Hochverfügbarkeit oder Geschäftskontinuität AWS-Regionen zu erstellen. Durch die physische und logische Trennung zwischen ihnen AWS-Regionen werden korrelierte Fehler zwischen ihnen vermieden. Mit anderen Worten, ähnlich wie wenn Sie ein EC2 Kunde wären und von der Isolierung der Availability Zones profitieren könnten, indem Sie sie in allen Bereichen einsetzen, können Sie denselben Vorteil auch für regionale Dienste nutzen, indem Sie sie in mehreren Regionen einsetzen. Dies setzt voraus, dass Sie für Ihre Anwendung eine Architektur mit mehreren Regionen implementieren, die Ihnen helfen kann, die Beeinträchtigung durch einen regionalen Dienst zu verkraften. Es kann jedoch schwierig sein, die Vorteile einer multiregionalen Architektur zu nutzen. Es erfordert sorgfältige Arbeit, um die Vorteile der regionalen Isolation zu nutzen, ohne dass auf Anwendungsebene etwas zunichte gemacht wird. Wenn Sie beispielsweise ein Failover einer Anwendung zwischen Regionen durchführen, müssen Sie eine strikte Trennung zwischen Ihren Anwendungsstapeln in jeder Region einhalten, sich aller Anwendungsabhängigkeiten bewusst sein und ein Failover für alle Teile der Anwendung durchführen. Um dies mit einer komplexen, auf Microservices basierenden Architektur zu erreichen, die viele Abhängigkeiten zwischen Anwendungen aufweist, sind Planung und Koordination zwischen vielen Ingenieur- und Geschäftsteams erforderlich. Wenn einzelne Workloads ihre eigenen Failover-Entscheidungen treffen können, wird die Koordination zwar weniger komplex, führt aber aufgrund des erheblichen Unterschieds in der Latenz, die zwischen Regionen und innerhalb einer einzelnen Region auftritt, zu modalem Verhalten. AWS bietet derzeit keine Funktion für die synchrone regionsübergreifende Replikation. Wenn Sie einen asynchron replizierten Datenspeicher (bereitgestellt von AWS) in verschiedenen Regionen verwenden, besteht die Möglichkeit eines Datenverlusts oder einer Inkonsistenz, wenn Sie für Ihre Anwendung ein Failover zwischen Regionen durchführen. Um mögliche Inkonsistenzen zu vermeiden, benötigen Sie einen zuverlässigen Datenabgleichsprozess, auf den Sie sich verlassen können und der möglicherweise auf mehreren Datenspeichern in Ihrem Workload-Portfolio ausgeführt werden muss, oder Sie müssen bereit sein, Datenverlust in Kauf zu nehmen. Schließlich müssen Sie das Failover üben, um zu wissen, dass es funktioniert, wenn Sie es brauchen. Die regelmäßige Rotation Ihrer Anwendung zwischen den Regionen, um das Failover zu üben, ist ein erheblicher Zeit- und Ressourcenaufwand. Wenn Sie sich dafür entscheiden, einen synchron replizierten Datenspeicher für mehrere Regionen zu verwenden, um Ihre Anwendungen zu unterstützen, die gleichzeitig in mehr als einer Region ausgeführt werden, unterscheiden sich die Leistungsmerkmale und die Latenz einer solchen Datenbank, die sich über Hunderte oder Tausende von Meilen erstreckt, erheblich von denen einer Datenbank, die in einer einzigen Region betrieben wird. Dies erfordert, dass Sie Ihren Anwendungsstapel von Grund auf planen, um dieses Verhalten zu berücksichtigen. Außerdem wird dadurch die Verfügbarkeit beider Regionen zu einer starken Abhängigkeit, was zu einer verringerten Belastbarkeit Ihrer Arbeitslast führen kann. # Weltweite Dienste Zusätzlich zu den regionalen und zonalen AWS Diensten gibt es eine kleine Gruppe von AWS Diensten, deren Steuerungsebenen und Datenebenen nicht in jeder Region unabhängig voneinander existieren. *Da ihre Ressourcen nicht regionsspezifisch sind, werden sie allgemein als global bezeichnet.* Globale AWS Dienste folgen immer noch dem herkömmlichen AWS Entwurfsmuster, bei dem die Steuerungsebene und die Datenebene getrennt werden, um statische Stabilität zu erreichen. Der wesentliche Unterschied bei den meisten globalen Diensten besteht darin, dass ihre Steuerungsebene auf einer *einzigen* Ebene gehostet wird AWS-Region, während ihre Datenebene global verteilt ist. Es gibt drei verschiedene Arten von globalen Diensten und eine Reihe von Diensten, die je nach der von Ihnen ausgewählten Konfiguration global erscheinen können. In den folgenden Abschnitten werden die einzelnen Arten von globalen Diensten und die Trennung ihrer Steuerungsebenen und Datenebenen beschrieben. Anhand dieser Informationen können Sie sich beim Aufbau zuverlässiger Mechanismen für Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR) orientieren, ohne auf eine globale Service-Kontrollebene angewiesen zu sein. Dieser Ansatz trägt dazu bei, einzelne Fehlerquellen in Ihrer Architektur zu beseitigen und mögliche regionsübergreifende Auswirkungen zu vermeiden, selbst wenn Sie in einer Region tätig sind, die sich von der Region unterscheidet, in der sich die globale Servicesteuerungsebene befindet. Es hilft Ihnen auch dabei, Failover-Mechanismen sicher zu implementieren, die nicht auf globale Servicesteuerungsebenen angewiesen sind. ## Globale Dienste, die je nach Partition einzigartig sind In jeder Partition gibt es einige globale AWS Dienste (in diesem paper als *partitionelle* Dienste bezeichnet). Partitionale Dienste stellen ihre Steuerungsebene in einer einzigen bereit. AWS-Region Einige partitionelle Dienste, wie AWS Network Manager, sind nur auf der Kontrollebene verfügbar und orchestrieren die Datenebene anderer Dienste. Andere partitionelle Dienste, wie z. B.IAM, verfügen über eine eigene Datenebene, die isoliert und auf alle Daten in der Partition verteilt ist. AWS-Regionen Fehler in einem partitionellen Dienst wirken sich nicht auf andere Partitionen aus. In der `aws` Partition befindet sich die Steuerungsebene des IAM Dienstes in der `us-east-1` Region, mit isolierten Datenebenen in jeder Region der Partition. Partitionale Dienste verfügen außerdem über unabhängige Steuerungsebenen und Datenebenen in den `aws-cn` Partitionen `aws-us-gov` und. Die Trennung von Steuerungsebene und Datenebene für IAM ist in der folgenden Abbildung dargestellt. ![\[Dieses Bild zeigt, dass es IAM eine einzige Steuerungsebene und eine regionalisierte Datenebene gibt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png) Im Folgenden sind partitionelle Dienste und ihre Position auf der Steuerungsebene in der `aws` Partition aufgeführt: + AWS IAM (`us-east-1`) + AWS Organizations (`us-east-1`) + AWS Kontoverwaltung () `us-east-1` + Route 53 Application Recovery Controller (ARC) (`us-west-2`) — Dieser Dienst ist nur in der `aws` Partition vorhanden + AWS Netzwerkmanager (`us-west-2`) + Route 53 Privat DNS (`us-east-1`) Wenn auf einer dieser Servicesteuerungsebenen ein Ereignis auftritt, das sich auf die Verfügbarkeit auswirkt, können Sie die von diesen Diensten bereitgestellten Operationen CRUDL vom Typ -möglicherweise nicht nutzen. Wenn Ihre Wiederherstellungsstrategie also von diesen Vorgängen abhängt, verringert eine Auswirkung auf die Verfügbarkeit der Kontrollebene oder die Region, in der sich die Kontrollebene befindet, Ihre Chancen auf eine erfolgreiche Wiederherstellung. [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md)bietet Strategien zur Beseitigung von Abhängigkeiten von globalen Service-Kontrollebenen während der Wiederherstellung. ****Empfehlung**** Verlassen Sie sich bei Ihrem Wiederherstellungspfad nicht auf die Steuerungsebenen partitioneller Dienste. Verlassen Sie sich stattdessen auf die Datenebenenoperationen dieser Dienste. Weitere Informationen dazu, wie Sie [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md) für partitionale Dienste entwerfen sollten, finden Sie unter. ## Globale Dienste im Edge-Netzwerk Die nächsten globalen AWS Dienste haben eine Kontrollebene in der `aws` Partition und hosten ihre Datenebenen in [der globalen PoP-Infrastruktur](points-of-presence.md) (und möglicherweise AWS-Regionen auch). Auf die darin gehosteten Datenebenen PoPs kann über Ressourcen in jeder Partition sowie über das Internet zugegriffen werden. Beispielsweise betreibt Route 53 ihre Kontrollebene in der `us-east-1` Region, ihre Datenebene ist jedoch auf Hunderte von Ebenen PoPs weltweit verteilt, ebenso wie auf jede Ebene AWS-Region (zur Unterstützung der öffentlichen und privaten Route 53 DNS innerhalb der Region). Route 53-Zustandsprüfungen sind ebenfalls Teil der Datenebene und werden von acht Stellen AWS-Regionen in der `aws` Partition aus durchgeführt. Clients können DNS mithilfe von öffentlich gehosteten Zonen von Route 53 von überall im Internet, einschließlich anderer Partitionen wie GovCloud, sowie von einer AWS Virtual Private Cloud (VPC) aus Probleme lösen. Im Folgenden sind die globalen Edge-Netzwerkdienste und ihre Position auf der Steuerungsebene in der `aws` Partition aufgeführt: + Route 53 Öffentlich DNS (`us-east-1`) + Amazon CloudFront (`us-east-1`) + AWS WAF Klassisch für CloudFront (`us-east-1`) + AWS WAF für CloudFront (`us-east-1`) + Amazon Certificate Manager (ACM) für CloudFront (`us-east-1`) + AWSGlobaler Beschleuniger (AGA) (`us-west-2`) + AWS Shield Advanced (`us-east-1`) Wenn Sie AGA Integritätsprüfungen für EC2 Instances oder Elastic IP-Adressen verwenden, verwenden diese Route 53-Zustandsprüfungen. Das Erstellen oder Aktualisieren von AGA Integritätsprüfungen hängt von der Route 53-Steuerebene ab, in der Sie sich befinden`us-east-1`. Für die Ausführung der AGA Integritätsprüfungen wird die Datenebene der Route 53-Systemdiagnose verwendet. Bei einem Ausfall, der sich auf die Region auswirkt, in der sich die Steuerungsebenen für diese Dienste befinden, oder bei einem Ausfall, der sich auf die Steuerungsebene selbst auswirkt, können Sie die von diesen Diensten bereitgestellten Operationen CRUDL vom Typ -möglicherweise nicht verwenden. Wenn Sie in Ihrer Wiederherstellungsstrategie Abhängigkeiten von diesen Vorgängen berücksichtigt haben, ist die Erfolgswahrscheinlichkeit dieser Strategie möglicherweise geringer, als wenn Sie sich nur auf die Datenebene dieser Dienste verlassen würden. ****Empfehlung**** Verlassen Sie sich bei Ihrem Wiederherstellungspfad nicht auf die Steuerungsebene der Edge-Netzwerkdienste. Verlassen Sie sich stattdessen auf den Betrieb dieser Dienste auf der Datenebene. Weitere Informationen [Anhang B — Globale Servicehinweise für Edge-Netzwerke](appendix-b---edge-network-global-service-guidance.md) zur Planung globaler Dienste im Edge-Netzwerk finden Sie unter. ## Globaler Betrieb in einer einzigen Region Die letzte Kategorie umfasst spezifische Operationen auf Kontrollebene innerhalb eines Dienstes, die globale Auswirkungen haben, und nicht ganze Dienste wie die vorherigen Kategorien. Während Sie mit zonalen und regionalen Diensten in der von Ihnen angegebenen Region interagieren, hängen bestimmte Operationen grundsätzlich von einer einzelnen Region ab, die sich von der Region unterscheidet, in der sich die Ressource befindet. Diese Dienste unterscheiden sich von Diensten, die nur in einer einzigen Region bereitgestellt werden. Eine Liste dieser Dienste finden Sie unter. [Anhang C — Dienste für eine einzelne Region](appendix-c---single-region-services.md) Während eines Fehlers, der sich auf die zugrunde liegende globale Abhängigkeit auswirkt, können Sie die Aktionen CRUDL vom Typ -typ der abhängigen Operationen möglicherweise nicht verwenden. Wenn Sie in Ihrer Wiederherstellungsstrategie Abhängigkeiten von diesen Vorgängen berücksichtigt haben, ist die Erfolgswahrscheinlichkeit dieser Strategie möglicherweise geringer, als wenn Sie sich nur auf die Datenebene dieser Dienste verlassen würden. Sie sollten bei Ihrer Wiederherstellungsstrategie Abhängigkeiten von diesen Vorgängen vermeiden. Im Folgenden finden Sie eine Liste von Diensten, von denen andere Dienste abhängig sein können und die globalen Geltungsbereich haben: + **Route 53** Verschiedene AWS Dienste erstellen Ressourcen, die einen oder mehrere ressourcenspezifische DNS Namen bereitstellen. Wenn Sie beispielsweise einen Elastic Load Balancer (ELB) bereitstellen, erstellt der Service öffentliche DNS Aufzeichnungen und Zustandsprüfungen in Route 53 für dieELB. Dies hängt von der Route 53-Steuerebene ab. `us-east-1` Andere Dienste, die Sie verwendenELB, müssen möglicherweise ebenfalls im Rahmen ihrer Workflows auf der Kontrollebene eine Bereitstellung bereitstellen, öffentliche Route DNS 53-Datensätze erstellen oder Route 53-Zustandsprüfungen erstellen. Wenn Sie beispielsweise eine Amazon API REST API Gateway-Ressource, eine Amazon Relational Database Service (AmazonRDS) -Datenbank oder eine Amazon OpenSearch Service-Domain bereitstellen, werden DNS Datensätze in Route 53 erstellt. Im Folgenden finden Sie eine Liste von Diensten, deren Kontrollebene von der Route 53-Steuerebene abhängt, `us-east-1` um DNS Datensätze, Hosting-Zonen und/oder Route-53-Zustandsprüfungen zu erstellen, zu aktualisieren oder zu löschen. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. Sie soll einige der am häufigsten verwendeten Dienste hervorheben, deren Aktionen auf der Kontrollebene zum Erstellen, Aktualisieren oder Löschen von Ressourcen von der Route 53-Steuerebene abhängen: + Amazon API Gateway REST und HTTP APIs + RDSAmazon-Instanzen + Amazon Aurora Aurora-Datenbanken + Amazon ELB Load Balancer + AWS PrivateLink VPCEndpunkte + AWS Lambda URLs + Amazon ElastiCache + OpenSearch Amazon-Dienst + Amazon CloudFront + Amazon MemoryDB + Amazon Neptune + Amazon DynamoDB DynamoDB-Beschleuniger () DAX + AGA + Amazon Elastic Container Service (AmazonECS) mit DNS basiertem Service Discovery (das AWS Cloud Map API zur Verwaltung von Route 53 verwendetDNS) + Amazon EKS Kubernetes-Steuerebene Es ist wichtig zu beachten, dass der VPC DNS Service, zum [EC2Beispiel Hostnamen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html), unabhängig voneinander existiert AWS-Region und nicht von der Route 53-Steuerebene abhängt. Datensätze, die für EC2 Instanzen im VPC DNS Service wie, `ip-10-0-10.ec2.internal``ip-10-0-1-5.compute.us-west-2.compute.internal`, `i-0123456789abcdef.ec2.internal` und AWS erstellt werden`i-0123456789abcdef.us-west-2.compute.internal`, sind nicht auf die Route 53-Steuerebene angewiesen. `us-east-1` ****Empfehlung**** Verlassen Sie sich in Ihrem Wiederherstellungspfad nicht darauf, Ressourcen zu erstellen, zu aktualisieren oder zu löschen, die die Erstellung, Aktualisierung oder Löschung von Route 53-Ressourceneinträgen, Hosting-Zonen oder Zustandsprüfungen erfordern. Stellen Sie diese Ressourcen vorab bereitELBs, z. B. um eine Abhängigkeit von der Route 53-Steuerebene in Ihrem Wiederherstellungspfad zu verhindern. + **Amazon S3** Die folgenden Operationen auf der Amazon S3 S3-Steuerebene hängen grundsätzlich von `us-east-1` der `aws` Partition ab. Ein Ausfall, der sich auf Amazon S3 oder andere Dienste auswirkt, `us-east-1` könnte dazu führen, dass die Aktionen dieser Kontrollebenen in anderen Regionen beeinträchtigt werden: ``` PutBucketCors DeleteBucketCors PutAccelerateConfiguration PutBucketRequestPayment PutBucketObjectLockConfiguration PutBucketTagging DeleteBucketTagging PutBucketReplication DeleteBucketReplication PutBucketEncryption DeleteBucketEncryption PutBucketLifecycle DeleteBucketLifecycle PutBucketNotification PutBucketLogging DeleteBucketLogging PutBucketVersioning PutBucketPolicy DeleteBucketPolicy PutBucketOwnershipControls DeleteBucketOwnershipControls PutBucketAcl PutBucketPublicAccessBlock DeleteBucketPublicAccessBlock ``` Die Steuerungsebene für Amazon S3 Multiregion Access Points (MRAP) wird [nur in dieser Region gehostet](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html), `us-west-2` und Anfragen zum Erstellen, Aktualisieren oder Löschen von Zielen MRAPs richten sich direkt an diese Region. Die Steuerungsebene für hat MRAP auch grundlegende Abhängigkeiten von AGA in`us-west-2`, Route 53 in und in jeder Region`us-east-1`, ACM in der sie für die Bereitstellung von Inhalten konfiguriert MRAP ist. Sie sollten sich nicht auf die Verfügbarkeit der MRAP Kontrollebene in Ihrem Wiederherstellungspfad oder in den Datenebenen Ihrer eigenen Systeme verlassen. Dies unterscheidet sich von [MRAPFailover-Steuerungen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html), mit denen der aktive oder passive Routing-Status für jeden Ihrer Buckets in der festgelegt wird. MRAP Diese APIs werden in [fünf](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration) Modulen gehostet AWS-Regionen und können verwendet werden, um den Datenverkehr mithilfe der Datenebene des Dienstes effektiv zu verlagern. Darüber hinaus [sind Amazon S3 S3-Bucket-Namen global eindeutig](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) und alle Aufrufe an `CreateBucket` und `DeleteBucket` APIs hängen davon ab`us-east-1`, dass in der `aws` Partition die Einzigartigkeit des Namens gewährleistet ist, auch wenn der API Aufruf an die spezifische Region gerichtet ist, in der Sie den Bucket erstellen möchten. Und schließlich sollten Sie sich bei wichtigen Workflows zur Bucket-Erstellung nicht auf die Verfügbarkeit einer bestimmten Schreibweise eines Bucket-Namens verlassen, insbesondere nicht auf solche, die einem erkennbaren Muster folgen. ****Empfehlung**** Verlassen Sie sich im Rahmen Ihres Wiederherstellungspfads nicht darauf, neue S3-Buckets zu löschen oder zu erstellen oder S3-Bucket-Konfigurationen zu aktualisieren. Stellen Sie alle erforderlichen S3-Buckets vorab mit den erforderlichen Konfigurationen bereit, sodass Sie keine Änderungen vornehmen müssen, um sich nach einem Ausfall zu erholen. Dieser Ansatz gilt MRAPs auch für. + **CloudFront** Amazon API Gateway bietet [Edge-optimierte Endgeräte API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized). Die Erstellung dieser Endpunkte hängt von der CloudFront Steuerungsebene ab, auf der die Verteilung vor dem Gateway-Endpunkt erstellt wird. `us-east-1` ****Empfehlung**** Verlassen Sie sich nicht darauf, im Rahmen Ihres Wiederherstellungspfads neue Edge-optimierte API Gateway-Endpunkte zu erstellen. Stellen Sie alle erforderlichen Gateway-Endpunkte vorab bereit. API Bei allen in diesem Abschnitt erörterten Abhängigkeiten handelt es sich um Aktionen auf Steuerungsebene, nicht um Aktionen auf Datenebene. Wenn Ihre Workloads so konfiguriert sind, dass sie statisch stabil sind, sollten sich diese Abhängigkeiten nicht auf Ihren Wiederherstellungspfad auswirken. Beachten Sie, dass die Implementierung statischer Stabilität zusätzliche Arbeit oder Dienste erfordert. ## Dienste, die globale Standardendpunkte verwenden In einigen Fällen stellen AWS Dienste einen standardmäßigen, globalen Endpunkt bereit, wie der AWS Security Token Service ([AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html)). Andere Dienste können diesen globalen Standardendpunkt in ihrer Standardkonfiguration verwenden. Das bedeutet, dass ein regionaler Dienst, den Sie verwenden, global von einem einzigen Dienst abhängig sein könnte AWS-Region. In den folgenden Details wird erklärt, wie unbeabsichtigte Abhängigkeiten von globalen Standardendpunkten entfernt werden können, sodass Sie den Dienst auf regionale Weise verwenden können. **AWS STS:** STS ist ein Webdienst, mit dem Sie temporäre Anmeldeinformationen mit eingeschränkten Rechten für IAM Benutzer oder für Benutzer, die Sie authentifizieren (Verbundbenutzer), anfordern können. STSDie Verwendung aus dem AWS Software Development Kit (SDK) und der Befehlszeilenschnittstelle (CLI) ist standardmäßig auf. `us-east-1` Der STS Service bietet auch regionale Endpunkte. Diese Endpunkte sind in Regionen, die ebenfalls standardmäßig aktiviert sind, standardmäßig aktiviert. Sie können diese jederzeit nutzen, indem Sie Ihre Endgeräte konfigurieren SDK oder die CLI folgenden Anweisungen befolgen: [AWS STSRegionalisierte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) Endpunkte. Für die Verwendung von SigV4a sind außerdem [temporäre Anmeldeinformationen erforderlich, die von einem regionalen Endpunkt angefordert werden](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions). STS Sie können den globalen STS Endpunkt nicht für diesen Vorgang verwenden. ****Empfehlung**** Aktualisieren Sie Ihre SDK CLI AND-Konfiguration, um die regionalen STS Endpunkte zu verwenden. **Security Assertion Markup Language (SAML) Anmeldung:** SAML Dienste sind überall vorhanden. AWS-Regionen Um diesen Service zu nutzen, wählen Sie den entsprechenden regionalen SAML Endpunkt aus, z. B. [https://us-west-2.signin.aws.amazon.com/saml](https://us-west-2.signin.aws.amazon.com/saml). Sie müssen die Konfigurationen in Ihren Vertrauensrichtlinien und Ihrem Identity Provider (IdP) aktualisieren, um die regionalen Endpunkte verwenden zu können. Spezifische Einzelheiten finden Sie in der [AWS SAMLDokumentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html). Wenn Sie einen IdP verwenden, auf dem auch gehostet wird AWS, besteht das Risiko, dass dieser auch bei einem AWS Ausfall beeinträchtigt wird. Dies kann dazu führen, dass Sie Ihre IdP-Konfiguration nicht aktualisieren können oder dass Sie den Verbund möglicherweise nicht vollständig durchführen können. Sie sollten „Break-Glass“ -Benutzer vorab einrichten, falls Ihr IdP beeinträchtigt oder nicht verfügbar ist. Nähere Informationen darüber, [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md) wie Sie Break-Glass-Benutzer auf statisch stabile Weise erstellen können, finden Sie unter. ****Empfehlung**** Aktualisieren Sie Ihre Richtlinien für die IAM Vertrauensstellung von Rollen, sodass Anmeldungen aus mehreren Regionen akzeptiert SAML werden. Aktualisieren Sie bei einem Ausfall Ihre IdP-Konfiguration, sodass ein anderer regionaler SAML Endpunkt verwendet wird, falls Ihr bevorzugter Endpunkt beeinträchtigt ist. Erstellen Sie einen oder mehrere Break-Glass-Benutzer für den Fall, dass Ihr IdP beeinträchtigt oder nicht verfügbar ist. **AWS IAMIdentity Center:** Identity Center ist ein cloudbasierter Dienst, der es einfach macht, den Single Sign-On-Zugriff auf Kunden- und Cloud-Anwendungen zentral zu verwalten. AWS-Konten Identity Center muss in einer einzigen Region Ihrer Wahl bereitgestellt werden. Das Standardverhalten für den Dienst besteht jedoch darin, den globalen SAML Endpunkt ([https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)) zu verwenden, der in gehostet wird`us-east-1`. Wenn Sie Identity Center auf einem anderen Server bereitgestellt haben AWS-Region, sollten Sie den [Relaystatus](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html) URL jedes Berechtigungssatzes so aktualisieren, dass er auf denselben regionalen Konsolenendpunkt abzielt wie Ihre Identity Center-Bereitstellung. [Wenn Sie beispielsweise Identity Center in bereitgestellt haben`us-west-2`, sollten Sie den Relaystate Ihrer Berechtigungssätze so aktualisieren, dass er https://us-west-2.console.aws.amazon.com verwendet.](https://us-west-2.console.aws.amazon.com) Dadurch wird jegliche Abhängigkeit `us-east-1` von Ihrer Identity Center-Bereitstellung entfernt. Da IAM Identity Center nur in einer einzigen Region bereitgestellt werden kann, sollten Sie außerdem „Break-Glass“ -Benutzer vorab einrichten, falls Ihre Bereitstellung beeinträchtigt wird. Nähere Informationen darüber, [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md) wie Sie Break-Glass-Benutzer auf statisch stabile Weise erstellen können, finden Sie unter. ****Empfehlung**** Stellen Sie den Relaystatus Ihrer Berechtigungssätze in IAM Identity Center so ein, dass er URL der Region entspricht, in der Sie den Dienst bereitgestellt haben. Für den Fall, dass Ihre IAM Identity Center-Bereitstellung nicht verfügbar ist, richten Sie einen oder mehrere Benutzer ein, die sich durch die Nutzung von „Breakglass“ auszeichnen. **Amazon S3 Storage Lens:** Storage Lens bietet ein Standard-Dashboard namens default-account-dashboard. Die Dashboard-Konfiguration und die zugehörigen Metriken werden in gespeichert`us-east-1`. Sie können zusätzliche Dashboards in anderen Regionen erstellen, indem Sie die [Heimatregion](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region) für die Dashboard-Konfiguration und die Metrikdaten angeben. ****Empfehlung**** Wenn Sie während eines Fehlers, der sich auf den Service auswirkt, Daten aus dem standardmäßigen S3 Storage Lens-Dashboard benötigen`us-east-1`, erstellen Sie ein zusätzliches Dashboard in einer alternativen Heimatregion. Sie können auch alle anderen benutzerdefinierten Dashboards, die Sie in weiteren Regionen erstellt haben, duplizieren. ## Zusammenfassung der globalen Dienste Bei den Datenebenen für globale Dienste gelten ähnliche Isolations- und Unabhängigkeitsprinzipien wie bei regionalen AWS Diensten. Ein Ausfall, der sich auf die Datenebene einer IAM Region auswirkt, hat keine Auswirkungen auf den Betrieb der IAM Datenebene in einer anderen AWS-Region Region. In ähnlicher Weise hat ein Fehler, der sich auf die Datenebene von Route 53 in einem PoP auswirkt, keine Auswirkungen auf den Betrieb der Route 53-Datenebene im Rest der. PoPs Daher müssen wir Ereignisse zur Dienstverfügbarkeit berücksichtigen, die sich auf die Region auswirken, in der die Kontrollebene betrieben wird, oder auf die Kontrollebene selbst. Da es für jeden globalen Dienst nur eine einzige Kontrollebene gibt, kann ein Ausfall, der sich auf diese Kontrollebene auswirkt, regionsübergreifende Auswirkungen auf Operationen CRUDL vom Typ -typ haben (das sind die Konfigurationsvorgänge, die normalerweise zur Einrichtung oder Konfiguration eines Dienstes verwendet werden, im Gegensatz zur direkten Nutzung des Dienstes). Die effektivste Methode, Workloads so zu gestalten, dass globale Dienste stabil genutzt werden können, ist die Verwendung statischer Stabilität. Bei einem Ausfallszenario sollten Sie Ihren Workload so gestalten, dass keine Änderungen erforderlich sind. Verwenden Sie dazu eine Kontrollebene, um die Auswirkungen zu minimieren, oder ein Failover an einen anderen Standort durchzuführen. Anleitungen zur [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md) Nutzung dieser Art von globalen Services zur Beseitigung von Abhängigkeiten auf der Kontrollebene und zur Eliminierung einzelner Fehlerquellen finden Sie unter und. [Anhang B — Globale Servicehinweise für Edge-Netzwerke](appendix-b---edge-network-global-service-guidance.md) Wenn Sie die Daten aus einem Vorgang auf der Steuerungsebene für die Wiederherstellung benötigen, zwischenspeichern Sie diese Daten in einem Datenspeicher, auf den über dessen Datenebene zugegriffen werden kann, z. B. einem [AWS Systems Manager](https://aws.amazon.com/systems-manager/) Parameter Store (SSMParameter Store) -Parameter, einer DynamoDB-Tabelle oder einem S3-Bucket. Aus Redundanzgründen können Sie diese Daten auch in einer zusätzlichen Region speichern. Wenn Sie beispielsweise die [bewährten Methoden](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html) für Route 53 Application Recovery Controller (ARC) befolgen, sollten Sie Ihre fünf regionalen Cluster-Endpunkte fest codieren oder mit einem Lesezeichen versehen. Während eines Ausfalls können Sie möglicherweise nicht auf einige API Operationen zugreifen, einschließlich Route ARC API 53-Operationen, die nicht auf dem extrem zuverlässigen Datenebenen-Cluster gehostet werden. Mithilfe des `DescribeCluster` API Vorgangs können Sie die Endpunkte für Ihre Route ARC 53-Cluster auflisten. Im Folgenden finden Sie eine Zusammenfassung einiger der häufigsten Fehlkonfigurationen oder Anti-Pattern, die zu Abhängigkeiten von den Steuerungsebenen globaler Dienste führen: + Änderungen an Route 53-Datensätzen vornehmen, z. B. den Wert eines A-Datensatzes aktualisieren oder die Gewichtung eines gewichteten Datensatzes ändern, um ein Failover durchzuführen. + Erstellen oder Aktualisieren von IAM Ressourcen, einschließlich IAM Rollen und Richtlinien, während eines Failovers. Dies ist in der Regel nicht beabsichtigt, kann aber das Ergebnis eines ungetesteten Failover-Plans sein. + Bediener verlassen sich bei einem Ausfall auf IAM Identity Center, um Zugriff auf Produktionsumgebungen zu erhalten. + Verlassen Sie sich bei der Nutzung der Konsole auf die IAM Identity Center-Standardkonfiguration`us-east-1`, wenn Sie Identity Center in einer anderen Region bereitgestellt haben. + Vornehmen von Änderungen an den Wählgewichten für den AGA Traffic, um ein regionales Failover manuell durchzuführen. + Aktualisierung der Ausgangskonfiguration einer CloudFront Distribution, sodass ein Failaway von einem beeinträchtigten Ursprung aus erfolgt. + Bereitstellung von Notfallwiederherstellungsressourcen (DR), wie z. B. ELBs RDS Instanzen bei einem Ausfall, die von der Erstellung von DNS Datensätzen in Route 53 abhängig sind. Im Folgenden finden Sie eine Zusammenfassung der in diesem Abschnitt enthaltenen Empfehlungen für eine zuverlässige Nutzung globaler Dienste, die dazu beitragen würden, die bisher üblichen Anti-Pattern-Angriffe zu verhindern. ****Zusammenfassung der Empfehlungen**** Verlassen Sie sich bei Ihrem Wiederherstellungspfad nicht auf die Steuerungsebenen partitionaler Dienste. Verlassen Sie sich stattdessen auf die Datenebenenoperationen dieser Dienste. Weitere Informationen dazu, wie Sie [Anhang A — Anleitung zum partitionellen Service](appendix-a---partitional-service-guidance.md) für partitionale Dienste entwerfen sollten, finden Sie unter. Verlassen Sie sich bei Ihrem Wiederherstellungspfad nicht auf die Steuerungsebene der Edge-Netzwerkdienste. Verlassen Sie sich stattdessen auf den Betrieb dieser Dienste auf der Datenebene. Weitere Informationen [Anhang B — Globale Servicehinweise für Edge-Netzwerke](appendix-b---edge-network-global-service-guidance.md) zur Planung globaler Dienste im Edge-Netzwerk finden Sie unter. Verlassen Sie sich in Ihrem Wiederherstellungspfad nicht darauf, Ressourcen zu erstellen, zu aktualisieren oder zu löschen, die die Erstellung, Aktualisierung oder Löschung von Route 53-Ressourceneinträgen, Hosting-Zonen oder Zustandsprüfungen erfordern. Stellen Sie diese Ressourcen vorab bereitELBs, z. B. um eine Abhängigkeit von der Route 53-Steuerebene in Ihrem Wiederherstellungspfad zu verhindern. Verlassen Sie sich nicht darauf, im Rahmen Ihres Wiederherstellungspfads S3-Buckets zu löschen oder neue S3-Buckets zu erstellen oder S3-Bucket-Konfigurationen zu aktualisieren. Stellen Sie alle erforderlichen S3-Buckets vorab mit den erforderlichen Konfigurationen bereit, sodass Sie keine Änderungen vornehmen müssen, um sich nach einem Ausfall zu erholen. Dieser Ansatz gilt MRAPs auch für. Verlassen Sie sich nicht darauf, im Rahmen Ihres Wiederherstellungspfads neue Edge-optimierte API Gateway-Endpunkte zu erstellen. Stellen Sie alle erforderlichen Gateway-Endpunkte vorab bereit. API Aktualisieren Sie Ihre SDK CLI Land-Konfiguration, um die regionalen STS Endpunkte zu verwenden. Aktualisieren Sie Ihre Richtlinien für IAM Rollenvertrauensstellungen, sodass SAML Anmeldungen aus mehreren Regionen akzeptiert werden. Aktualisieren Sie bei einem Ausfall Ihre IdP-Konfiguration, sodass ein anderer regionaler SAML Endpunkt verwendet wird, falls Ihr bevorzugter Endpunkt beeinträchtigt ist. Erstellen Sie Break-Glass-Benutzer für den Fall, dass Ihr IdP beeinträchtigt oder nicht verfügbar ist. Stellen Sie den Relaystatus URL Ihrer Berechtigungssätze in IAM Identity Center so ein, dass er der Region entspricht, in der Sie den Dienst bereitgestellt haben. Für den Fall, dass Ihre Identity Center-Bereitstellung nicht verfügbar ist, richten Sie einen oder mehrere Benutzer ein, die sich durch die Nutzung von „Breakglass“ auszeichnen. Wenn Sie während eines Fehlers, der sich auf den Service auswirkt, Daten aus dem standardmäßigen S3 Storage Lens-Dashboard benötigen`us-east-1`, erstellen Sie ein zusätzliches Dashboard in einer anderen Heimatregion. Sie können auch alle anderen benutzerdefinierten Dashboards, die Sie in weiteren Regionen erstellt haben, duplizieren.