Optionen zur Notfallwiederherstellung in der Cloud

Die Strategien zur Notfallwiederherstellung, die Ihnen innerhalb von AWS zur Verfügung stehen, lassen sich grob in vier Ansätze einteilen, die von der kostengünstigen und wenig komplexen Erstellung von Backups bis hin zu komplexeren Strategien mit mehreren aktiven Regionen reichen. Es ist von entscheidender Bedeutung, dass Sie Ihre Strategie zur Notfallwiederherstellung regelmäßig testen, sodass Sie sie im Bedarfsfall sicher auslösen können.

Abbildung 6 - Strategien zur Notfallwiederherstellung

Bei einem Katastrophenereignis, das durch die Unterbrechung oder den Verlust eines physischen Rechenzentrums für einen gut strukturierten, hochverfügbaren Workload verursacht wird, benötigen Sie möglicherweise nur einen Backup- und Wiederherstellungsansatz für die Notfallwiederherstellung. Wenn Ihre Definition einer Katastrophe über die Unterbrechung oder den Verlust eines physischen Rechenzentrums hinausgeht und sich auf eine Region erstreckt oder wenn Sie gesetzlichen Anforderungen unterliegen, die dies erfordern, dann sollten Sie Pilot Light, Warm Standby oder Multi-Site Active/Active in Betracht ziehen.

Backup und Wiederherstellung

Backup und Wiederherstellung ist ein geeigneter Ansatz, um Datenverlusten oder -beschädigungen vorzubeugen. Dieser Ansatz kann auch verwendet werden, um eine regionale Katastrophe abzumildern, indem Daten in andere AWS-Regionen repliziert werden, oder um eine fehlende Redundanz für Workloads abzumildern, die in einer einzigen Availability Zone bereitgestellt werden. Zusätzlich zu den Daten müssen Sie auch die Infrastruktur, die Konfiguration und den Anwendungscode in der Wiederherstellungsregion neu bereitstellen. Damit die Infrastruktur schnell und fehlerfrei neu bereitgestellt werden kann, sollten Sie die Bereitstellung als Infrastruktur as Code (IaC) mit Services wie AWS CloudFormation oder AWS Cloud Development Kit (AWS CDK) durchführen. Ohne IaC kann die Wiederherstellung von Workloads in der Wiederherstellungsregion komplex sein, was zu längeren Wiederherstellungszeiten führt und möglicherweise Ihr RTO überschreitet. Sichern Sie neben den Benutzerdaten auch den Code und die Konfiguration, einschließlich Amazon Machine Images (AMIs), die Sie zur Erstellung von Amazon EC2-Instances verwenden. Sie können AWS CodePipeline verwenden, um die Neuverteilung von Anwendungscode und Konfiguration zu automatisieren.

Abbildung 7 - Sicherungs- und Wiederherstellungsarchitektur

AWS-Services

Ihre Workload-Daten erfordern eine Backup-Strategie, die in regelmäßigen Abständen oder kontinuierlich durchgeführt wird. Wie oft Sie Ihr Backup ausführen, bestimmt den erreichbaren Wiederherstellungspunkt (der sich an Ihrem RPO orientieren sollte). Das Backup sollte außerdem die Möglichkeit bieten, es zu dem Zeitpunkt wiederherzustellen, zu dem es erstellt wurde. Backups mit Point-in-Time-Recovery sind über die folgenden Services und Ressourcen verfügbar:

• Amazon Elastic Block Store (Amazon EBS)-Snapshot

• Amazon DynamoDB-Backup

• Amazon RDS-Snapshot

• Amazon Aurora DB-Snapshot

• Amazon EFS-Backup (bei Verwendung von AWS Backup)

• Amazon Redshift-Snapshot

• Amazon Neptune-Snapshot

Für Amazon Simple Storage Service (Amazon S3) können Sie Amazon S3 Cross-Region-Replication (CRR) verwenden, um Objekte asynchron und kontinuierlich in einen S3-Bucket in der DR-Region zu kopieren und gleichzeitig eine Versionierung für die gespeicherten Objekte bereitzustellen, sodass Sie den Wiederherstellungspunkt wählen können. Die kontinuierliche Replikation von Daten hat den Vorteil, dass sie die kürzeste Zeit (nahezu null) für die Sicherung Ihrer Daten benötigt, schützt aber möglicherweise nicht so gut vor Katastrophenereignissen wie Datenbeschädigung oder Angriffen (z. B. unbefugtes Löschen von Daten) wie die zeitpunktbezogene Sicherungen. Die kontinuierliche Replikation wird im Abschnitt AWS-Services für Pilot Light behandelt.

AWS Backup bietet einen zentralen Ort zur Konfiguration, Planung und Überwachung der AWS-Backup-Funktionen für die folgenden Services und Ressourcen:

• Amazon Elastic Block Store (Amazon EBS)-Volumes

• Amazon EC2-Instances

• Amazon Relational Database Service (Amazon RDS)-Datenbanken (einschließlich Amazon Aurora-Datenbanken)

• Amazon DynamoDB-Tabellen

• Amazon Elastic File System (Amazon EFS)-Dateisysteme

• AWS Storage Gateway-Volumes

• Amazon FSx for Windows File Server und Amazon FSx for Lustre

AWS Backup unterstützt das Kopieren von Backups über Regionen hinweg, z. B. in eine Notfallwiederherstellungsregion.

Als zusätzliche Notfallwiederherstellungsstrategie für Ihre Amazon S3-Daten aktivieren Sie die S3-Objektversionierung. Die Objektversionierung schützt Ihre Daten in S3 vor den Folgen von Lösch- oder Änderungsaktionen, indem sie die ursprüngliche Version vor der Aktion beibehält. Die Objektversionierung kann eine nützliche Abhilfe für Katastrophen durch menschliches Versagen sein. Wenn Sie die S3-Replikation verwenden, um Daten in Ihrer DR-Region zu sichern, dann fügt Amazon S3 standardmäßig eine Löschmarkierung nur im Quell-Bucket hinzu, wenn ein Objekt im Quell-Bucket gelöscht wird. Dieser Ansatz schützt die Daten in der DR-Region vor böswilligen Löschungen in der Quellregion.

Zusätzlich zu den Daten müssen Sie auch die Konfiguration und die Infrastruktur sichern, die erforderlich sind, um Ihren Workload neu zu verteilen und Ihr Recovery Time Objective (RTO) einzuhalten. AWS CloudFormation bietet IaC-Lösungen (Infrastructure as Code, mit denen Sie alle AWS-Ressourcen in Ihrem Workload definieren können, sodass Sie diesen zuverlässig für mehrere AWS-Konten und AWS-Regionen bereitstellen und neu bereitstellen können). Sie können die von Ihrem Workload verwendeten Amazon EC2-Instances als Amazon Machine Images (AMIs) sichern. Das AMI wird aus Snapshots des Root-Volumes Ihrer Instance und aller anderen EBS-Volumes erstellt, die mit Ihrer Instance verknüpft sind. Sie können dieses AMI verwenden, um eine wiederhergestellte Version der EC2-Instance zu starten. Ein AMI kann innerhalb einer Region oder regionsübergreifend kopiert werden. Oder Sie können AWS Backup verwenden, um Backups kontoübergreifend und in andere AWS-Regionen zu kopieren. Die kontoübergreifende Backup-Funktion schützt Sie vor Katastrophenereignissen wie internen Bedrohungen oder einer Kontokompromittierung. AWS Backup bietet außerdem zusätzliche Funktionen für EC2-Backups. Zusätzlich zu den einzelnen EBS-Volumes der Instances speichert und verfolgt AWS Backup auch die folgenden Metadaten: Instance-Typ, konfigurierte Virtual Private Cloud (VPC), Sicherheitsgruppe, IAM-Rolle, Überwachungskonfiguration und Tags. Diese zusätzlichen Metadaten werden jedoch nur bei der Wiederherstellung des EC2-Backups in derselben AWS Region verwendet.

Alle Daten, die in der Notfallwiederherstellungsregion als Backups gespeichert sind, müssen zum Zeitpunkt des Failovers wiederhergestellt werden. AWS Backup bietet eine Wiederherstellungsfunktion, ermöglicht aber derzeit keine geplante oder automatische Wiederherstellung. Sie können eine automatische Wiederherstellung in der DR-Region implementieren, indem Sie das AWS SDK verwenden, um APIs für AWS Backup aufzurufen. Sie können dies als regelmäßig wiederkehrenden Auftrag einrichten oder die Wiederherstellung auslösen, sobald ein Backup abgeschlossen ist. Die folgende Abbildung zeigt ein Beispiel für die automatische Wiederherstellung mit Amazon Simple Notification Service (Amazon SNS) und AWS Lambda.

Abbildung 8 - Wiederherstellen und Testen von Backups

Anmerkung

Ihre Backup-Strategie muss das Testen Ihrer Backups einbeziehen. Weitere Informationen finden Sie im Abschnitt Testen der Notfallwiederherstellung. Lesen Sie außerdem den Artikel AWS Well-Architected Lab: Testen von Backups und Wiederherstellung von Daten. Dort finden Sie eine praktische Demonstration der Implementierung.

Pilot Light

Mit dem Pilot Light-Ansatz replizieren Sie Ihre Daten von einer Region in eine andere und stellen eine Kopie Ihrer zentralen Workload-Infrastruktur bereit. Ressourcen, die zur Unterstützung der Datenreplikation und des Backups erforderlich sind, wie Datenbanken und Objektspeicher, sind immer betriebsbereit. Andere Elemente, wie z. B. Anwendungsserver, werden mit Anwendungscode und Konfigurationen geladen, sind aber offline und werden nur während der Tests oder beim Aufrufen des Failovers für die Notfallwiederherstellung verwendet. Im Gegensatz zum Backup- und Wiederherstellungsansatz ist Ihre Kerninfrastruktur immer verfügbar und Sie haben jederzeit die Möglichkeit, durch die Aktivierung und Skalierung Ihrer Anwendungsserver schnell eine vollwertige Produktionsumgebung bereitzustellen.

Abbildung 9 - Pilot Light-Architektur

Ein Pilot Light-Ansatz minimiert die laufenden Kosten für die Notfallwiederherstellung, indem er die aktiven Ressourcen minimiert und die Wiederherstellung zum Zeitpunkt einer Katastrophe vereinfacht, da die Kernanforderungen an die Infrastruktur bereits vorhanden sind. Diese Wiederherstellungsoption erfordert, dass Sie Ihren Bereitstellungsansatz ändern. Sie müssen Änderungen an der Kerninfrastruktur in jeder Region vornehmen und gleichzeitig Änderungen am Workload (Konfiguration, Code) in jeder Region bereitstellen. Dieser Schritt lässt sich vereinfachen, indem Sie Ihre Bereitstellungen automatisieren und Infrastruktur as Code (IaC) verwenden, um die Infrastruktur über mehrere Konten und Regionen hinweg bereitzustellen (vollständige Bereitstellung der Infrastruktur in der primären Region und verkleinerte/deaktivierte Bereitstellung der Infrastruktur in den DR-Regionen). Es wird empfohlen, für jede Region ein anderes Konto zu verwenden, um ein Höchstmaß an Ressourcen- und Sicherheitsisolierung zu gewährleisten (falls kompromittierte Anmeldeinformationen Teil Ihrer Notfallwiederherstellungspläne sind).

Bei diesem Ansatz müssen Sie sich auch gegen eine Datenpanne wappnen. Die kontinuierliche Datenreplikation schützt Sie zwar vor einigen Arten von Katastrophen, aber möglicherweise nicht vor einer Datenbeschädigung oder -zerstörung, es sei denn, Ihre Strategie umfasst auch die Versionierung der gespeicherten Daten oder Optionen für eine Point-in-Time-Wiederherstellung. Sie können die replizierten Daten in der Katastrophenregion sichern, um Point-in-Time-Backups in derselben Region zu erstellen.

AWS-Services

Zusätzlich zu den AWS-Services für Point-in-Time-Backups, die im Abschnitt Backup und Wiederherstellung beschrieben sind, sollten Sie auch die folgenden Services für Ihre Pilot Light-Strategie in Betracht ziehen.

Für Pilot Light ist die kontinuierliche Datenreplikation auf Live-Datenbanken und Datenspeicher in der DR-Region der beste Ansatz für ein niedriges RPO (wenn sie zusätzlich zu den zuvor besprochenen Point-in-Time-Backups verwendet wird). AWS bietet eine kontinuierliche, regionsübergreifende, asynchrone Datenreplikation für Daten über die folgenden Services und Ressourcen:

• Amazon Simple Storage Service (Amazon S3)-Replikation

• Amazon RDS-Read-Replicas

• Globale Amazon Aurora-Datenbanken

• Globale Amazon DynamoDB-Tabellen

Mit der kontinuierlichen Replikation sind die Versionen Ihrer Daten fast sofort in Ihrer DR-Region verfügbar. Die tatsächlichen Replikationszeiten können mithilfe von Service-Funktionen wie S3 Replication Time Control (S3 RTC) für S3-Objekte und Verwaltungsfunktionen für globale Amazon Aurora-Datenbanken überwacht werden.

Bei einem Failover, bei dem Sie Ihren Lese-/Schreib-Workload von der Notfallwiederherstellungsregion aus ausführen, müssen Sie eine RDS-Lesereplik zur primären Instance heraufstufen. Bei DB-Instances, die nicht auf Aurora basieren, dauert dieser Prozess einige Minuten und umfasst einen Neustart. Für die regionsübergreifende Replikation (Cross-Region Replication, CRR) und den Failover mit RDS bietet die Verwendung der globalen Datenbank von Amazon Aurora mehrere Vorteile. Die globale Datenbank verwendet eine dedizierte Infrastruktur, die Ihre Datenbanken vollständig für Ihre Anwendung zur Verfügung stellt und die Replikation in die sekundäre Region mit einer typischen Latenzzeit von weniger als einer Sekunde ermöglicht (innerhalb einer AWS-Region sogar weniger als 100 Millisekunden). Mit der globalen Amazon Aurora-Datenbank können Sie bei einer Leistungsverschlechterung oder einem Ausfall Ihrer primären Region eine der sekundären Regionen hochstufen, um die Lese-/Schreibaufgaben in weniger als 1 Minute zu übernehmen, selbst im Falle eines kompletten regionalen Ausfalls. Die Hochstufung kann automatisch erfolgen und es ist kein Neustart erforderlich.

In Ihrer DR-Region muss eine verkleinerte Version Ihrer Kern-Workload-Infrastruktur mit weniger oder kleineren Ressourcen bereitgestellt werden. Mit AWS CloudFormation können Sie Ihre Infrastruktur definieren und sie konsistent über AWS-Konten und AWS-Regionen hinweg bereitstellen. AWS CloudFormation verwendet vordefinierte Pseudoparameter, um das AWS-Konto und die AWS-Region zu identifizieren, in der der Service bereitgestellt wird. Daher können Sie eine Bedingungslogik in Ihre CloudFormation-Vorlagen implementieren, um nur die verkleinerte Version Ihrer Infrastruktur in der DR-Region bereitzustellen. Für die Bereitstellung von EC2-Instances liefert ein Amazon Machine Image (AMI) Informationen zur Hardwarekonfiguration und installierten Software. Sie können eine Image Builder-Pipeline implementieren, die die von Ihnen benötigten AMIs erstellt und diese sowohl in Ihre primäre als auch in Ihre Backup-Region kopiert. So stellen Sie sicher, dass diese Golden AMIs alles enthalten, was Sie brauchen, um Ihren Workload in einer neuen Region bereitzustellen oder zu skalieren, falls es zu einem Notfall kommt. Amazon EC2-Instances werden in einer verkleinerten Konfiguration bereitgestellt (weniger Instances als in Ihrer primären Region). Sie können hibernate verwenden, um EC2-Instance in einen angehaltenen Zustand zu versetzen, in dem Sie keine EC2-Kosten verursachen. Sie zahlen dann nur für den verwendeten Speicherplatz. Um EC2-Instance zu starten, können Sie Skripte mit der AWS Command Line Interface (CLI) oder dem AWS SDK erstellen. Um die Infrastruktur zur Unterstützung des Datenverkehrs in der Produktion zu skalieren, lesen Sie AWS Auto Scaling im Abschnitt Warm Standby.

Bei einer Active/Standby-Konfiguration wie Pilot Light geht der gesamte Datenverkehr zunächst an die primäre Region und wechselt zur Notfallwiederherstellungsregion, wenn die primäre Region nicht mehr verfügbar ist. Es gibt zwei Optionen für die Verwaltung des Datenverkehrs mit AWS-Services. Die erste Option ist die Verwendung von Amazon Route 53. Mit Amazon Route 53 können Sie mehrere IP-Endpunkte in einer oder mehreren AWS-Regionen mit einer Route 53-Domäne verknüpfen. Dann können Sie den Datenverkehr an den entsprechenden Endpunkt unter diesem Domänennamen weiterleiten. Amazon Route 53-Status-Checks überwachen diese Endpunkte. Mithilfe dieser Status-Checks können Sie DNS-Failovers konfigurieren, um sicherzustellen, dass der Datenverkehr an funktionsfähige Endpunkte geleitet wird.

Die zweite Möglichkeit ist die Verwendung von AWS Global Accelerator. Mit AnyCast IP können Sie mehrere Endpunkte in einer oder mehreren AWS-Regionen mit derselben statischen IP-Adresse bzw. denselben statischen IP-Adressen verknüpfen. AWS Global Accelerator leitet den Datenverkehr dann an den entsprechenden Endpunkt weiter, der mit dieser Adresse verknüpft ist. Global Accelerator-Status-Checks überwachen die Endpunkte. Mithilfe dieser Status-Checks prüft AWS Global Accelerator automatisch den Zustand Ihrer Anwendungen und leitet den Datenverkehr der Benutzer nur an einen funktionsfähigen Anwendungsendpunkt weiter. Global Accelerator bietet geringere Latenzzeiten zum Anwendungsendpunkt, da es das umfangreiche AWS-Edge-Netzwerk nutzt, um den Datenverkehr so schnell wie möglich auf das AWS-Netzwerk-Backbone zu routen. Global Accelerator vermeidet außerdem Caching-Probleme, die bei DNS-Systemen (wie Route 53) auftreten können.

CloudEndure Disaster Recovery

CloudEndure Disaster Recovery ist über AWS Marketplace verfügbar und repliziert kontinuierlich servergehostete Anwendungen und servergehostete Datenbanken aus jeder beliebigen Quelle in AWS, indem der zugrunde liegende Server auf Blockebene repliziert wird. Mit CloudEndure Disaster Recovery können Sie die AWS Cloud als Notfallwiederherstellungsregion für einen lokalen Workload und seine Umgebung nutzen. Der Service kann auch für die Notfallwiederherstellung von in AWS gehosteten Workloads verwendet werden, wenn diese nur aus Anwendungen und Datenbanken bestehen, die in EC2 gehostet werden (d. h. nicht RDS). CloudEndure Disaster Recovery verwendet die Pilot Light-Strategie, bei der eine Kopie der Daten und der deaktivierten Ressourcen in einer Amazon Virtual Private Cloud (Amazon VPC) aufbewahrt wird, die als Staging-Area dient. Wenn ein Failover-Ereignis ausgelöst wird, werden die bereitgestellten Ressourcen verwendet, um automatisch eine Bereitstellung mit voller Kapazität in der Amazon VPC zu erstellen, die als Wiederherstellungsort dient.

Abbildung 10 - CloudEndure Disaster Recovery-Architektur

Warm Standby

Beim Warm Standby-Ansatz wird sichergestellt, dass eine verkleinerte, aber voll funktionsfähige Kopie Ihrer Produktionsumgebung in einer anderen Region vorhanden ist. Dieser Ansatz erweitert das Pilot Light-Konzept und verkürzt die Zeit bis zur Wiederherstellung, da Ihr Workload in einer anderen Region ständig aktiv ist. Mit diesem Ansatz können Sie auch leichter Tests durchführen oder kontinuierliche Tests implementieren, um das Vertrauen in Ihre Fähigkeit zur Wiederherstellung nach einer Katastrophe zu erhöhen.

Abbildung 11 - Warm Standby-Architektur

Hinweis: Der Unterschied zwischen Pilot Light und Warm Standby kann mitunter nicht eindeutig sein. Beide beinhalten eine Umgebung in Ihrer DR-Region mit Kopien der Assets Ihrer primären Region. Der Unterschied besteht darin, dass Pilot Light keine Anfragen bearbeiten kann, ohne dass zuvor zusätzliche Maßnahmen ergriffen werden, während Warm Standby den Datenverkehr (mit reduzierter Kapazität) sofort bearbeiten kann. Der Pilot Light-Ansatz erfordert, dass Sie Server "einschalten" und möglicherweise zusätzliche (nicht zum Kerngeschäft gehörende) Infrastruktur bereitstellen und hochskalieren, während Sie bei Warm Standby nur hochskalieren müssen (alles ist bereits bereitgestellt und läuft). Verwenden Sie Ihre RTO- und RPO-Anforderungen, um zwischen diesen Ansätzen zu wählen.

AWS-Services

Alle AWS-Services, die unter Backup und Wiederherstellung und Pilot Light aufgeführt sind, werden auch im Warm Standby-Konzept für die Datensicherung, die Datenreplikation, die Weiterleitung des Datenverkehrs im aktiven Standby-Modus und die Bereitstellung der Infrastruktur einschließlich EC2-Instances verwendet.

AWS Auto Scaling wird zur Skalierung von Ressourcen wie Amazon EC2-Instance, Amazon ECS-Aufgaben, Amazon DynamoDB-Durchsatz und Amazon Aurora-Replikate innerhalb einer AWS Region verwendet. Amazon EC2 Auto Scaling skaliert die Bereitstellung von EC2-Instances über Availability Zones innerhalb einer AWS Region und sorgt für Ausfallsicherheit innerhalb dieser Region. Nutzen Sie Auto Scaling, um Ihre DR-Region im Rahmen einer Pilot Light- oder Warm Standby-Strategie auf volle Produktionsleistung zu skalieren. Erhöhen Sie zum Beispiel für EC2 die Einstellung Gewünschte Kapazität in der Auto Scaling-Gruppe. Sie können diese Einstellung manuell über die AWS Management Console, automatisch über das AWS SDK oder durch erneute Bereitstellung Ihrer AWS CloudFormation-Vorlage mit dem neuen Wert für die gewünschte Kapazität anpassen. Sie können AWS CloudFormation-Parameter verwenden, um die Neubereitstellung der CloudFormation-Vorlage zu erleichtern. Stellen Sie sicher, dass die Service-Kontingente in Ihrer DR-Region hoch genug sind, sodass die Hochskalierung auf die Produktionsleistung nicht behindert wird.

Multi-Site Active/Active

Sie können Ihren Workload im Rahmen einer Multi-Site Active/Active- oder Hot Standby Active/Passive-Strategie gleichzeitig in mehreren Regionen ausführen. Multi-Site Active/Active bedient den Datenverkehr aus allen Regionen, für die es bereitgestellt wird, während Hot Standby den Datenverkehr nur aus einer einzigen Region bedient und die andere(n) Region(en) nur für die Notfallwiederherstellung verwendet wird/werden. Bei einem Multi-Site Active/Active-Ansatz können Benutzer auf Ihren Workload in jeder der Regionen zugreifen, in denen er bereitgestellt ist. Dieser Ansatz ist der komplexeste und kostspieligste Ansatz für die Notfallwiederherstellung, kann aber bei den meisten Katastrophen mit der richtigen Technologieauswahl und -implementierung die Wiederherstellungszeit auf nahezu null reduzieren (bei einer Datenbeschädigung müssen Sie sich jedoch möglicherweise auf Backups verlassen, was in der Regel zu einem Wiederherstellungspunkt ungleich null führt). Hot Standby verwendet eine Active/Passive-Konfiguration, bei der die Benutzer nur zu einer einzigen Region geleitet werden und die DR-Regionen keinen Datenverkehr aufnehmen. Die meisten Kunden sind der Ansicht, dass beim Aufbau einer vollständigen Umgebung in der zweiten Region eine Active/Active-Konfiguration sinnvoll ist. Wenn Sie den Datenverkehr nicht über beide Regionen abwickeln möchten, bietet Warm Standby einen wirtschaftlicheren und operativ weniger komplexen Ansatz.

Abbildung 12 - Multi-Site Active/Active-Architektur (für Hot-Standby müssen Sie einen Active-Pfad in Inactive ändern)

Bei Multi-Site Active/Active gibt es in diesem Szenario kein Failover, da der Workload in mehr als einer Region ausgeführt wird. Notfallwiederherstellungstests würden sich in diesem Fall darauf konzentrieren, wie der Workload auf den Ausfall einer Region reagiert: Wird der Datenverkehr von der ausgefallenen Region weggeleitet? Kann/können die andere(n) Region(en) den gesamten Datenverkehr bewältigen? Auch Tests für eine Datenkatastrophe sind erforderlich. Backup und Wiederherstellung sind weiterhin erforderlich und sollten regelmäßig getestet werden. Es sollte auch beachtet werden, dass die Wiederherstellungszeiten für eine Datenkatastrophe mit Datenbeschädigung, -löschung oder -verschleierung immer größer als null sein werden und der Wiederherstellungspunkt immer an einem Punkt vor der Entdeckung der Katastrophe liegen wird. Wenn die zusätzliche Komplexität und die Kosten eines Multi-Site Active/Active- (oder Hot-Standby)-Ansatzes erforderlich sind, um die Wiederherstellungszeiten nahe null zu halten, dann sollten zusätzliche Anstrengungen unternommen werden, um die Sicherheit aufrechtzuerhalten und menschliches Versagen zu verhindern, um menschliche Katastrophen abzufedern.

AWS-Services

Alle AWS-Services, die unter Backup und Wiederherstellung, Pilot Light und Warm Standby behandelt werden, werden hier auch für die Point-in-Time-Datensicherung, die Datenreplikation, die Weiterleitung des Active/Active-Datenverkehrs und die Bereitstellung und Skalierung der Infrastruktur einschließlich EC2-Instances verwendet.

Für die bereits besprochenen Active/Passive-Szenarien (Pilot Light und Warm Standby) können sowohl Amazon Route 53 als auch AWS Global Accelerator für die Weiterleitung des Datenverkehrs zur aktiven Regionen verwendet werden. Für die Active/Active-Strategie ermöglichen beide Services auch die Definition von Richtlinien, die festlegen, welche Benutzer zu welchem aktiven regionalen Endpunkt gehen. Mit AWS Global Accelerator legen Sie eine Datenverkehrsverteilung fest, um den Prozentsatz des Datenverkehrs zu steuern, der an jeden Anwendungsendpunkt geleitet wird. Amazon Route 53 unterstützt diesen prozentualen Ansatz und darüber hinaus mehrere andere verfügbare Richtlinien, einschließlich Richtlinien für die geografische Verteilung und die Latenz. Global Accelerator nutzt automatisch das umfangreiche Netzwerk von AWS-Edge-Servern, um den Datenverkehr so schnell wie möglich an das AWS-Netzwerk-Backbone weiterzuleiten, was zu geringeren Latenzen bei Anfragen führt.

Die Datenreplikation mit dieser Strategie ermöglicht ein RPO nahe null. AWS-Services wie die globale Amazon Aurora-Datenbank nutzen eine dedizierte Infrastruktur, die Ihre Datenbanken vollständig für Ihre Anwendung verfügbar macht, und können mit einer typischen Latenz von unter einer Sekunde in eine sekundäre Region replizieren. Bei Active/Passive-Strategien erfolgen Schreibvorgänge nur in der primären Region. Der Unterschied zu Active/Active besteht darin, wie die Schreibvorgänge in jeder aktiven Region gehandhabt werden. Üblicherweise werden Lesevorgänge von der Region ausgeführt, die dem Benutzer am nächsten ist, was als Read Local bezeichnet wird. Bei Schreibvorgängen haben Sie mehrere Möglichkeiten:

• Eine Write Global Strategie routet alle Schreibvorgänge an eine einzige Region. Sollte diese Region ausfallen, wird eine andere Region zur Annahme von Schreibvorgängen befördert. Die globale Aurora-Datenbank eignet sich gut für Write Global, da sie die Synchronisierung mit Lese-Replikaten über die Regionen hinweg unterstützt und Sie eine der sekundären Regionen in weniger als 1 Minute zur Übernahme von Lese-/Schreibaufgaben hochstufen können.

• Eine Write Local-Strategie routet Schreibvorgänge an die nächstgelegene Region (genau wie Lesevorgänge). Globale Amazon DynamoDB-Tabellen ermöglichen eine solche Strategie und Lese- und Schreibzugriffe aus jeder Region, in der Ihre globale Tabelle bereitgestellt wird. Globale Amazon DynamoDB-Tabellen verwenden einen Last Writer Wins-Abgleich bei gleichzeitigen Aktualisierungen.

• Eine Write Partitioned-Strategie weist Schreibvorgänge einer bestimmten Region auf der Grundlage eines Partitionsschlüssels (wie der Benutzer-ID) zu, um Schreibkonflikte zu vermeiden. In diesem Fall kann die bidirektional konfigurierte Amazon S3-Replikation verwendet werden. Sie unterstützt derzeit die Replikation zwischen zwei Regionen. Stellen Sie bei der Implementierung dieses Ansatzes sicher, dass Sie replica modification sync für beide Buckets (A und B) aktivieren, um Änderungen an Replikat-Metadaten wie Objekt-Zugriffskontrolllisten (ACLs), Objekt-Tags oder Objektsperren für die replizierten Objekten zu replizieren. Sie können außerdem konfigurieren, ob Löschmarkierungen zwischen Buckets in Ihren aktiven Regionen repliziert werden sollen. Neben der Replikation muss Ihre Strategie auch Point-in-Time-Backups zum Schutz vor Datenbeschädigung oder -zerstörung vorsehen.

AWS CloudFormation ist ein leistungsstarkes Tool, um eine einheitlich bereitgestellte Infrastruktur zwischen AWS-Konten in mehreren AWS-Regionen durchzusetzen. AWS CloudFormation StackSets erweitert diese Funktionalität, indem es Ihnen ermöglicht, CloudFormation-Stacks über mehrere Konten und Regionen hinweg mit einem einzigen Vorgang zu erstellen, zu aktualisieren oder zu löschen. AWS CloudFormation nutzt YAML oder JSON, um Infrastruktur as Code zu definieren. Sie können mit AWS Cloud Development Kit (AWS CDK) jedoch Ihnen bekannte Programmiersprachen nutzen, um die Infrastructure as Code-Lösungen zu definieren. Ihr Code wird in CloudFormation umgewandelt und dann zum Bereitstellen von Ressourcen in AWS verwendet.