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.

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.

Im Folgenden sind partitionelle Dienste und ihre Position auf der Steuerungsebene in der aws Partition aufgeführt:

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 Servicebietet Strategien zur Beseitigung von Abhängigkeiten von globalen Service-Kontrollebenen während der Wiederherstellung.

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 (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:

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 befindenus-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.

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

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:

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). 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 Endpunkte. Für die Verwendung von SigV4a sind außerdem temporäre Anmeldeinformationen erforderlich, die von einem regionalen Endpunkt angefordert werden. STS Sie können den globalen STS Endpunkt nicht für diesen Vorgang 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. 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.

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 wie Sie Break-Glass-Benutzer auf statisch stabile Weise erstellen können, finden Sie unter.

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) zu verwenden, der in gehostet wirdus-east-1. Wenn Sie Identity Center auf einem anderen Server bereitgestellt haben AWS-Region, sollten Sie den Relaystatus URL jedes Berechtigungssatzes so aktualisieren, dass er auf denselben regionalen Konsolenendpunkt abzielt wie Ihre Identity Center-Bereitstellung. Wenn Sie beispielsweise Identity Center in bereitgestellt habenus-west-2, sollten Sie den Relaystate Ihrer Berechtigungssätze so aktualisieren, dass er https://us-west-2.console.aws.amazon.com verwendet. 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 wie Sie Break-Glass-Benutzer auf statisch stabile Weise erstellen können, finden Sie unter.

Amazon S3 Storage Lens: Storage Lens bietet ein Standard-Dashboard namens default-account-dashboard. Die Dashboard-Konfiguration und die zugehörigen Metriken werden in gespeichertus-east-1. Sie können zusätzliche Dashboards in anderen Regionen erstellen, indem Sie die Heimatregion für die Dashboard-Konfiguration und die Metrikdaten angeben.

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 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 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 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 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:

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.