Zusammenfassung

  • AWS beschreibt seine European Sovereign Cloud als eigene Partition aws-eusc, die physisch, logisch und betrieblich von anderen AWS-Partitionen getrennt ist.
  • Die Grenze verhindert vertraute Abkürzungen: Zugangsdaten, S3 Cross-Region Replication und das Regions-Peering von Transit Gateway funktionieren laut AWS nicht partitionsübergreifend.
  • Ob das Ziel geeignet ist, entscheidet das benannte Ausfallszenario. Regionen-, Identitäts-, Konnektivitäts-, Rechts- und geopolitische Störungen entfernen unterschiedliche Voraussetzungen.

Der erste Wiederherstellungsschritt scheitert an der Grenze

Ein Runbook für zwei kommerzielle Regionen beginnt damit, im Ziel eine Rolle zu übernehmen, replizierte S3-Objekte zu prüfen und das Recovery-Netz über Transit Gateway anzubinden. Auf aws-eusc gerichtet stoppt es vor dem Anwendungsstart: Zugangsdaten gelten nicht partitionsübergreifend; auch S3 Cross-Region Replication und Regions-Peering über Transit Gateway überqueren die Grenze laut AWS nicht.

Das Ziel braucht daher vorab eigene Konten und Identitäten, einen ausdrücklichen Datenweg und eine andere Netzverbindung. Erst danach stellt sich die nächste Frage: Warum wurde die Quelle unbenutzbar? Diese Ursache entscheidet, ob der neu gebaute Pfeil im tatsächlichen Störungsbild bestehen bleibt.

Bei einem Fehler in einer einzelnen Availability Zone kann eine Multi-AZ-Anwendung innerhalb derselben Region weiterarbeiten. Bei einem Regionsausfall kann ein Ziel in einer anderen Region derselben Partition genügen. Fällt dagegen die Identitäts- oder Vertrauensebene der kommerziellen Partition aus, kann jedes Ziel, das weiterhin von ihr abhängt, unzugänglich bleiben. Eine regulatorische Anordnung kann nicht die Technik, sondern die Erlaubnis zur Datenbewegung beseitigen. Eine geopolitische oder großräumige Konnektivitätsstörung kann den Betrieb der souveränen Partition schützen, aber gleichzeitig Betreiber und Datenzufuhr abschneiden.

AWS rät in seiner Architekturbetrachtung dazu, das einfachste Design für das tatsächliche natürliche, technische, menschliche, geopolitische oder regulatorische Szenario zu wählen. Eine pauschale Behauptung „Failover in die souveräne Cloud“ überspringt diese Auswahl.

Die harte Grenze verändert jedes Szenario

AWS nennt aws-eusc eine eigene Partition und eusc-de-east-1 die erste Region in Brandenburg. Konten sind an eine Partition gebunden; neue Konten, IAM-Identitäten und Rollen werden benötigt. AWS sagt außerdem, dass S3 Cross-Region Replication und Regions-Peering über Transit Gateway die Partitionsgrenze nicht überqueren.

Damit fehlt sowohl eine angenommene Steuerungskontinuität als auch ein Teil der angenommenen Daten- und Netzwerkkontinuität. Das Ziel muss vorab provisioniert und über interne oder externe Werkzeuge synchronisiert werden. Eigene Organisationsstrukturen, Policies, Zertifikate, DNS, Monitoring und Governance sind keine späteren Optimierungen, sondern Voraussetzungen.

Die Trennung entspricht der souveränen Zielsetzung. Nach Angaben von AWS ist die Region physisch und logisch separat, vollständig in der EU angesiedelt und mit dedizierten Identitäts-, Abrechnungs-, Vertrauens- und DNS-Komponenten ausgestattet. Sie soll weiterarbeiten können, wenn die Verbindung zum Rest der Welt unterbrochen wird. Das beweist eine beabsichtigte Betriebsunabhängigkeit der Plattform; es beweist nicht die Betriebsfähigkeit einer Kundenanwendung.

Fünf Störungsbilder, fünf Prüfungen

Beim Regionsausfall lautet die Kernfrage, ob sämtliche Dienste, Funktionen, Quoten und Daten im Ziel vorhanden sind. AWS veröffentlicht ein breites Serviceangebot und eine aktuelle Fähigkeitsmatrix. Ein gleicher Servicename beweist aber weder Feature-Parität noch reservierte Kapazität.

Beim Identitätsausfall muss das Ziel ohne Konten, Rollen, Zertifikatsstellen oder Freigabeprozesse der Quelle gestartet werden können. Eine kopierte Infrastrukturdefinition hilft nicht, wenn niemand rechtmäßig eine Rolle übernehmen oder ein Zertifikat erneuern kann.

Beim Netzausfall muss der vorgesehene Pfad unter genau dieser Trennung bestehen. AWS beschreibt TLS über das Internet, IPsec VPN und Direct-Connect-bezogene Varianten. Adressierung, Routing, Firewalls, DNS, Schlüssel und Betreiberabhängigkeiten müssen für den Ausfall geprüft werden, nicht nur im Normalbetrieb.

Beim Daten- oder Konsistenzfehler ist eine Sicherung möglicherweise die falsche Quelle. Das Unternehmen muss bestimmen, welcher Datenstand maßgeblich ist, wie er über die Partition gelangt, welche Verluste zulässig sind und wie divergierende Schreibvorgänge später zusammengeführt werden. Da native S3-Regionsreplikation die Grenze nicht überquert, braucht es ein ausdrücklich verantwortetes Verfahren.

Beim regulatorischen oder geopolitischen Ereignis kommt eine weitere Frage hinzu: Darf die technische Handlung ausgeführt werden? Die Zulässigkeit des Zielorts ist nicht automatisch die Erlaubnis, Daten aus der Quelle zu übertragen oder Notfallregeln zu umgehen. Aktivierungsbefugnis ist ein eigener Kontrollpunkt.

Plattformresilienz und Workload-Recovery

AWS ordnet in seinem Modell der geteilten Verantwortung die Resilienz der Cloud-Infrastruktur dem Anbieter zu. Der Kunde konfiguriert Resilienz in der Cloud: Multi-Location-Design, Selbstheilung, Backups und Replikation, Netzwerk, Quoten, Beobachtbarkeit, Runbooks und Tests.

Mehrere Availability Zones und redundante Versorgung sind deshalb relevante Plattformeigenschaften. Sie ersetzen keine kundenseitige Zielkapazität. Eine Compliance-Liste kann die Eignung für regulierte Daten belegen, aber keine Funktion, Quote oder Übung liefern. AWS betont zudem, dass der Kunde die Auswirkungen jedes Services auf seine eigene Compliance beurteilen muss.

AWS definiert RTO als maximal akzeptierte Zeit bis zur Wiederherstellung und RPO als maximal akzeptiertes Alter des letzten wiederherstellbaren Datenpunkts. Die Organisation setzt diese Ziele. Backup-and-Restore, Pilot Light, Warm Standby und Active-Active finanzieren unterschiedliche Bereitschaft und können deshalb nicht unter einem einzigen Versprechen zusammengefasst werden.

Die zitierten AWS-Quellen enthalten weder das Abhängigkeitsinventar noch Quoten, Datenvolumen, Übungszeiten, Rollback-Ergebnisse oder Kosten eines bestimmten Käufers. Sie belegen auch keinen abgeschlossenen partitionsübergreifenden Failover einer namentlich genannten regulierten Anwendung. Eine Bewertung muss diese Unbekannten offenhalten.