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.

Anhang B — Globale Servicehinweise für Edge-Netzwerke

Für globale Dienste in Edge-Netzwerken sollten Sie statische Stabilität implementieren, um die Resilienz Ihres Workloads während einer Beeinträchtigung der AWS Dienststeuerungsebene aufrechtzuerhalten.

Route 53

Die Route 53-Steuerungsebene besteht aus allen öffentlichen Route 53-APIs, die Funktionen für gehostete Zonen, Datensätze, Integritätsprüfungen, DNS-Abfrageprotokolle, wiederverwendbare Delegierungssätze, Verkehrsrichtlinien und Kostenzuweisungskennzeichnungen abdecken. Es wird in den us-east-1 gehostet. Die Datenebene ist der maßgebliche DNS-Dienst, der über 200 AWS-Region Points-of-Points-of-Points-of-east-Standorte und Daten der Zustandsprüfung beantwortet. Darüber hinaus verfügt Route 53 über eine Datenebene für Gesundheitschecks, bei der es sich ebenfalls um einen global verteilten Dienst handelt, der auf mehrere Dienste verteilt ist. AWS-Regionen Diese Datenebene führt Zustandsprüfungen durch, aggregiert und an die Datenebenen des öffentlichen und privaten DNS der Route 53 und liefert. Während einer Beeinträchtigung der Steuerungsebene funktionieren Crudl-Operationen für Route 53 möglicherweise nicht, aber DNS-Auflösungs- und Integritätsprüfungen sowie Routing-Aktualisierungen, die sich aus Änderungen bei den Integritätsprüfungen ergeben, funktionieren weiterhin.

Dies bedeutet, dass Sie sich bei der Planung von Abhängigkeiten von Route 53 in Ihrem Wiederherstellungspfad nicht auf die Route 53-Steuerebene verlassen sollten. Ein statisch stabiles Design wäre beispielsweise, den Status von Integritätsprüfungen zu verwenden, um Failover zwischen Regionen durchzuführen oder eine Availability Zone zu evakuieren. Sie können die Routingkontrollen des Route 53 Application Recovery Controller (ARC) verwenden, um den Status von Integritätsprüfungen und die Antworten auf DNS-Abfragen manuell zu ändern. Es gibt ähnliche Muster wie das, was ARC bietet, die Sie auf der Grundlage Ihrer Anforderungen implementieren können. Einige dieser Muster werden unter Creating Disaster Recovery Mechanisms using Route 53 und im Abschnitt Advanced Multi-AZ Resilience Patterns Health Check Circuit Breaker beschrieben. Wenn Sie sich für einen DR-Plan mit mehreren Regionen entschieden haben, stellen Sie Ressourcen, für die DNS-Einträge erstellt werden müssen, wie ELBs und RDS-Instances, vorab bereit. Ein non-statically-stable Design wäre, den Wert eines Route 53-Ressourcendatensatzes über die ChangeResourceRecordSets API zu aktualisieren, die Gewichtung eines gewichteten Datensatzes zu ändern oder neue Datensätze zu erstellen, um ein Failover durchzuführen. Diese Ansätze hängen von der Route 53-Steuerebene ab.

Amazon CloudFront

Die CloudFront Amazon-Kontrollebene besteht aus allen öffentlichen CloudFront APIs für die Verwaltung von Distributionen und wird in us-east-1 gehostet. Die Datenebene ist die Verteilung selbst, die PoPs vom In-the-Edge-Netzwerk aus bedient wird. Es übernimmt die Bearbeitung, das Routing und das Caching Ihrer ursprünglichen Inhalte. Während einer Beeinträchtigung der Steuerungsebene funktionieren Crudl-Operationen für CloudFront (einschließlich Invalidierungsanfragen) möglicherweise nicht, aber Ihre Inhalte werden weiterhin zwischengespeichert und bereitgestellt, und die Origin-Failover funktionieren weiterhin.

Das bedeutet, dass Sie sich bei der Planung von Abhängigkeiten auf CloudFront Ihrem Wiederherstellungspfad nicht auf die CloudFront Steuerungsebene verlassen sollten. Ein statisch stabiles Design wäre beispielsweise die Verwendung automatisierter Origin-Failover, um die Auswirkungen einer Beeinträchtigung eines Ihrer Origins zu mildern. Sie können sich auch dafür entscheiden, Origin Load Balancing oder Failover mit Lamda @Edge zu erstellen. Weitere Informationen zu diesem Muster finden Sie unter Drei erweiterte Entwurfsmuster für hochverfügbare Anwendungen mit Amazon CloudFront und Verwenden von Amazon CloudFront und Amazon S3 zum Erstellen von aktiv-aktiven Geo-Proximity-Anwendungen für mehrere Regionen. Ein non-statically-stable Design wäre, die Konfiguration Ihrer Distribution als Reaktion auf einen Origin-Fehler manuell zu aktualisieren. Dieser Ansatz würde von der CloudFront Steuerungsebene abhängen.

Amazon Certificate Manager

Wenn Sie benutzerdefinierte Zertifikate für Ihre CloudFront Distribution verwenden, sind Sie auch von ACM abhängig. Die Verwendung CloudFront benutzerdefinierter Zertifikate in der Region usa-east-1 Während einer Beeinträchtigung der Kontrollebene funktionieren Ihre vorhandenen Zertifikate, die in Ihrer Distribution konfiguriert wurden, ebenso wie automatische Zertifikatserneuerungen. Verlassen Sie sich nicht darauf, die Konfiguration der Distribution zu ändern oder neue Zertifikate als Teil Ihres Wiederherstellungspfads zu erstellen.

AWSWeb Application Firewall (WAF) und WAF Classic

Wenn Sie es AWS WAF mit Ihrer CloudFront Distribution verwenden, sind Sie von der WAF-Kontrollebene abhängig, die ebenfalls in der Region us-east-1 gehostet wird. Bei einer Beeinträchtigung der Steuerungsebene funktionieren die konfigurierten Web Access Control Lists (ACLs) und die zugehörigen Regeln weiterhin. Verlassen Sie sich nicht darauf, Ihre WAF-Web-ACLs als Teil Ihres Wiederherstellungspfads zu aktualisieren.

AWS Global Accelerator

Die AGA-Steuerungsebene besteht aus allen öffentlichen AGA-APIs und wird in us-west-2 gehostet. Die Datenebene ist das Netzwerk-Routing der Anycast-IP-Adressen, die von AGA an Ihre registrierten Endpunkte bereitgestellt werden. AGA verwendet auch Route 53-Gesundheitschecks, um den Zustand Ihrer AGA-Endpunkte zu ermitteln, die Teil der Route 53-Datenebene sind. Während einer Beeinträchtigung der Steuerungsebene funktionieren Operationen vom Typ CRUDL für AGA möglicherweise nicht. Das Routing zu Ihren vorhandenen Endpunkten sowie die bestehenden Integritätsprüfungen, Wähltasten und Konfigurationen zur Gewichtung von Endpunkten, die verwendet werden, um den Datenverkehr an andere Endpunkte und Endpunktgruppen weiterzuleiten oder zu verlagern, werden weiterhin funktionieren.

Dies bedeutet, dass Sie sich bei der Planung von Abhängigkeiten von AGA bei Ihrem Wiederherstellungspfad nicht auf die AGA-Steuerungsebene verlassen sollten. Ein statisch stabiles Design würde beispielsweise darin bestehen, den Status der konfigurierten Integritätsprüfungen zu verwenden, um an fehlerhaften Endpunkten ein Failaway durchzuführen. Beispiele für diese Konfiguration finden Sie unter Bereitstellen von Anwendungen für mehrere Regionen in der AWS Verwendung von AWS Global Accelerator. Ein non-statically-stable Plan wäre, die Prozentsätze für die AGA-Traffic Wählvorgänge zu ändern, Endpunktgruppen zu bearbeiten oder einen Endpunkt aus einer Endpunktgruppe zu entfernen, wenn eine Beeinträchtigung auftritt. Diese Ansätze würden von der AGA-Steuerungsebene abhängen.

Amazon S3 Shield

Die Amazon Shield Advanced-Steuerungsebene besteht aus allen öffentlichen Shield Advanced-APIs und wird in us-east-1 gehostet. Dazu gehören Funktionen wie CreateProtectionCreateProtectionGroup,AssociateHealthCheck,DesribeDRTAccess, undListProtections. Die Datenebene ist der von Shield Advanced bereitgestellte DDoS-Schutz sowie die Erstellung von Shield Advanced-Metriken. Shield Advanced verwendet auch Route 53-Gesundheitschecks (die Teil der Route 53-Datenebene sind), sofern Sie sie konfiguriert haben. Während einer Beeinträchtigung der Steuerungsebene funktionieren Crudl-Operationen für Shield Advanced möglicherweise nicht, aber der für Ihre Ressourcen konfigurierte DDoS-Schutz sowie die Reaktionen auf Änderungen bei den Zustandsprüfungen funktionieren weiterhin.

Das bedeutet, dass Sie sich bei Ihrem Wiederherstellungsprozess nicht auf die Shield Advanced-Steuerungsebene verlassen sollten. Die Shield Advanced-Steuerungsebene bietet zwar keine direkten Funktionen, die Sie normalerweise in einer Wiederherstellungssituation verwenden würden, es kann jedoch vorkommen, dass Sie dies tun würden. Ein statisch stabiles Design würde beispielsweise darin bestehen, dass Ihre DR-Ressourcen bereits so konfiguriert sind, dass sie Teil einer Schutzgruppe sind, und dass ihnen Gesundheitschecks zugeordnet sind, anstatt diesen Schutz nach dem Auftreten des Fehlers zu konfigurieren. Dadurch wird verhindert, dass Sie bei der Wiederherstellung auf die Shield Advanced-Steuerebene angewiesen sind.