Sovereign Failover: Design für digitale Souveränität mit der AWS European Sovereign Cloud

Organisationen, die in mehreren Rechtsräumen tätig sind, müssen berücksichtigen, wie sich regulatorische Änderungen oder geopolitische Ereignisse auf ihren Zugriff auf Cloud-Infrastruktur auswirken können. Dieser Beitrag beschreibt, wie Sie Failover-Architekturen entwerfen, die sich über AWS-Partitionen erstrecken – einschließlich der AWS European Sovereign Cloud, AWS GovCloud (US) und weiterer AWS Regionen der globalen Infrastruktur –, damit Workloads auch dann weiter betrieben werden können, wenn sich Souveränitätsanforderungen verändern.

Die AWS European Sovereign Cloud wurde entwickelt, um Kunden bei Anforderungen an operative Autonomie und Datenresidenz zu unterstützen. Darüber hinaus kann sie helfen, weitergehende geopolitische und souveränitätsbezogene Risiken zu adressieren. In diesem Beitrag betrachten wir die Architektur, Herausforderungen und Best Practices für partitionenübergreifenden Failover, einschließlich Netzwerkkonnektivität, Authentifizierung und Governance. Wenn Sie diese Rahmenbedingungen berücksichtigen, können Sie resiliente Cloud-native Anwendungen entwerfen, die regulatorische Compliance und betriebliche Kontinuität in Einklang bringen.

Souveränitätsrisiken einordnen

Digitale Souveränität bedeutet, digitale Abhängigkeiten aktiv zu steuern – also zu entscheiden, wie Daten, Technologien und Infrastrukturen genutzt werden, und das Risiko eines Verlusts von Zugriff, Kontrolle oder Konnektivität zu reduzieren. Wie bei jeder Disaster-Recovery-Strategie gibt es mehrere Möglichkeiten, Kontinuität für die zu entwerfenden Systeme bereitzustellen. Die meisten davon umfassen eine Form von Failover-Architektur, also die Bereitstellung einer alternativen Infrastruktur, die genutzt wird, wenn ein Ausfall die ursprüngliche Infrastruktur beeinträchtigt. Der Unterschied bei souveränitätsorientierter Disaster Recovery liegt in den Kontrollmechanismen und Strukturen der Zielumgebung, auf die umgeschaltet wird. Wenn Sie die AWS European Sovereign Cloud in Ihr Workload-Design einbeziehen, erweitern Sie Ihre Failover-Fähigkeiten um Optionen, mit denen Sie ein höheres Maß an Souveränität wiederherstellen oder aufrechterhalten können, falls die primäre Umgebung nicht verfügbar ist.

Da sich regulatorische Anforderungen weiterentwickeln, müssen moderne Failover-Architekturen souveräne Umgebungen wie die AWS European Sovereign Cloud, AWS GovCloud (US) und Multi-Vendor-Deployments berücksichtigen. Dieser Beitrag konzentriert sich auf drei Kernbereiche, um Souveränitätsanforderungen in das Failover-Design zu integrieren: die Failover-Strategie, Netzwerkkonnektivität über isolierte Partitionen hinweg sowie Authentifizierung und Autorisierung in partitionenübergreifenden Architekturen. Diese Patterns lassen sich sowohl auf kurze regionale Ausfälle als auch auf langfristige Störungen ganzer Partitionen anwenden.

AWS-Partitionen verstehen

Als globaler Cloud-Anbieter betreibt AWS mehrere Infrastruktur-Partitionen, die auf spezifische operative und regulatorische Anforderungen zugeschnitten sind. Zusätzlich zur globalen AWS-Infrastruktur bietet AWS spezialisierte Partitionen wie AWS GovCloud (US) für US-Behörden, die AWS China Regions sowie die AWS European Sovereign Cloud für Kunden mit strengen Anforderungen an Datenresidenz und Kontrolle innerhalb der EU.

Jede Partition ist eine logisch isolierte Gruppe von AWS Regions mit einem eigenen Satz von Ressourcen, einschließlich AWS Identity and Access Management (IAM). Aufgrund dieser Trennung bilden Partitionen harte Grenzen. Anmeldeinformationen werden nicht über Partitionen hinweg übernommen, und Services wie Amazon S3 sowie Funktionen wie S3 Cross-Region Replication oder AWS Transit Gateway Inter-Region Peering funktionieren nicht partitionenübergreifend. Diese Einschränkungen sind beabsichtigt und schaffen operative Isolation. AWS GovCloud (US), eingeführt 2011, unterstützt Kunden des öffentlichen Sektors in den USA bei Compliance-Anforderungen wie FedRAMP und ITAR. Die AWS China Regions werden in lokalen Partnerschaften betrieben, um chinesische Datenhoheitsanforderungen zu erfüllen. In ähnlicher Weise ist die AWS European Sovereign Cloud eine vollständig innerhalb der EU aufgebaute Partition, die 2026 eingeführt wurde.

Diese Partitionen bieten eine stärkere Kontrolle über Daten sowie physische Isolation der Infrastruktur. Das macht sie besonders relevant für Organisationen in regulierten und sensiblen Sektoren, die strenge Compliance-Anforderungen erfüllen müssen.

Wesentliche Vorteile von AWS-Partitionen

AWS hat Partitionen aus mehreren Gründen eingeführt. Sie helfen Kunden dabei, länderspezifische Compliance- und Regulierungsanforderungen zu erfüllen – sei es in AWS GovCloud (US), AWS China oder der AWS European Sovereign Cloud. Grundlage dafür sind mehrere Schutzmechanismen und Kontrollen, darunter die physische, logische und operative Trennung der Cloud-Infrastruktur zwischen Partitionen. Das adressiert unmittelbar die sicherheitsrelevanten Aspekte von Partitionen. Partitionen ermöglichen die vollständige Isolation von Ressourcen. Das unterstützt das Sicherheitsmanagement, insbesondere bei Architekturen für sensible Workloads.

Ein weiterer wichtiger Punkt ist die Serviceverfügbarkeit. Nicht jeder AWS Service steht in jeder Partition zur Verfügung. Einen Überblick über die pro Region verfügbaren AWS Services finden Sie unter AWS Capabilities by Region.

Partitionenübergreifende Architekturen

Eine partitionenübergreifende Architektur ermöglicht Failover zwischen Partitionen, indem Ressourcen und Infrastruktur über mehrere isolierte AWS-Partitionen hinweg bereitgestellt werden. Da Partitionen hinsichtlich Identität, Netzwerk und Services vollständig voneinander getrennt sind, kann ein Failover nicht einfach wie innerhalb einer einzelnen Partition oder Region umgeschaltet werden. Stattdessen müssen Umgebungen vorab bereitgestellt und mit internen oder externen Werkzeugen synchron gehalten werden. Ohne eine solche Architektur ist ein Failover zwischen Partitionen in der Praxis kaum umsetzbar. Partitionenübergreifende Architekturen machen Failover zwar möglich, erfordern aber doppelte Infrastruktur, getrennte Identitätssysteme und eine angepasste Datensynchronisation.

Abbildung 1: Verschiedene Gründe für einen Failover und ihre möglichen Zielorte

Beim Entwurf von Cross-Region- oder partitionenübergreifenden Failover-Strategien hängt die Wahl der Regions von der Art des Ausfalls ab, den Sie adressieren möchten:

• Naturkatastrophen: Wählen Sie Regions in unterschiedlichen geografischen Zonen oder mit abweichenden geografischen Merkmalen.
• Technische Ausfälle: Verteilen Sie Workloads auf voneinander unabhängige Teile der globalen technischen Infrastruktur, etwa Stromnetze, Netzwerke und andere gemeinsam genutzte Ressourcen.
• Durch menschliches Handeln verursachte Ausfälle: Berücksichtigen Sie politische, sozioökonomische und rechtliche Faktoren, die den Betrieb beeinflussen könnten.

Abbildung 2: Active-Active-Failover-Szenario mit einer souveränen Failover-Option

Failover zwischen Partitionen

Partitionenübergreifende Workloads entstehen aus dem Bedarf verschiedener Branchen, Kontinuität über souveräne Domänen hinweg sicherzustellen und gleichzeitig regionale Vorgaben einzuhalten. Beispiele sind militärische und verteidigungsnahe Umgebungen, die spezialisierte Clouds wie AWS GovCloud (US) mit kommerziellen Umgebungen verbinden, oder Notfallreaktionssysteme, die eine strikte Partitionsisolation mit zentralem Management kombinieren müssen. Control Planes, die Workloads über Partitionen hinweg verwalten, sind entscheidend, um mandantenfähige Strukturen zu unterstützen und zentralisierte Metriken, Log-Aggregation, Onboarding, Security Management und weitere Funktionen bereitzustellen.

Sie können beispielsweise Backups in eine zweite Partition verlagern, um bei Bedarf in diese Partition wiederherzustellen. Ebenso lässt sich in einer anderen Partition ein Pilot-Light für eine Anwendung betreiben. Das reduziert die Kosten der Infrastruktur in der zweiten Partition erheblich, weil sie erst im Ereignisfall vollständig hochgefahren wird. Warm-Standby- oder Multi-Site-Active-Active-Setups unterscheiden sich vor allem durch den Bedarf an komplexerer Netzwerksynchronisation über Partitionen hinweg.

Abbildung 3: Verschiedene Arten von Disaster-Recovery-Szenarien

Bei der Planung eines Failovers können Sie auch Anbieterunabhängigkeit als zusätzliche Souveränitätsanforderung berücksichtigen. Eine Möglichkeit dafür ist die Nutzung eines anderen Cloud-Anbieters. Ein Failover in eine andere AWS-Partition ist jedoch einfacher als ein Wechsel zu einem anderen Cloud-Anbieter, da sich Infrastructure-as-Code-Vorlagen über Partitionen hinweg wiederverwenden lassen.

Gründe für die Verbindung von Partitionen

Obwohl Partitionen auf Isolation ausgelegt sind, müssen manche Workloads innerhalb einer Partition mit Workloads in weniger regulierten Partitionen oder mit externen Systemen kommunizieren, die über das öffentliche Internet erreichbar sind. Für solche Fälle sollten mehrere Architekturstrategien und die zugehörigen Architekturentscheidungen betrachtet werden. Es gibt Anwendungsfälle, in denen AWS Services partitionenübergreifend kommunizieren und Aktionen über mehrere Partitionen hinweg orchestrieren müssen, zum Beispiel:

• Domänenübergreifende Anwendungen
• Feature-Parität und Serviceverfügbarkeit
• Kostenoptimierung bei gleichzeitiger Erfüllung von Sicherheitsanforderungen
• Konsolidierung von Infrastruktur
• Control-Plane-Patterns

Die Umsetzung dieser Anwendungsfälle erfordert eine genauere Betrachtung der technischen Verbindung von Partitionen, sowohl aus Netzwerk- als auch aus Sicherheitsperspektive.

Regionale Verbindungen im Vergleich zu verbundenen Partitionen

Regionale Verbindungen ermöglichen die Kopplung von AWS Regions innerhalb derselben Partition, zum Beispiel mit Funktionen wie S3 Cross-Region Replication oder Transit Gateway Peering. Dadurch lassen sich Workloads innerhalb der globalen Infrastruktur einer Partition vergleichsweise nahtlos verteilen und im Failover-Fall umschalten. Die Unterscheidung zwischen regionalen Verbindungen und verbundenen Partitionen ist entscheidend, um resiliente und zugleich compliance-konforme Architekturen zu entwerfen, die sowohl operative als auch regulatorische Anforderungen erfüllen.

Netzwerke zwischen Partitionen verbinden

AWS-Partitionen lassen sich auf drei Arten verbinden: über Internet-Konnektivität mit TLS-Absicherung, über IPsec Site-to-Site VPN über das Internet oder über ein AWS Direct Connect Gateway zu On-Premises-Routern beziehungsweise über Partnerverbindungen zwischen Direct-Connect-Points-of-Presence (PoPs). Jeder Ansatz bringt andere Trade-offs in Bezug auf Security-Komplexität und Wiederherstellbarkeit mit sich. Weitere Informationen zu Konnektivitätsmustern zwischen AWS GovCloud (US) und der globalen AWS-Infrastruktur finden Sie im Beitrag Connectivity patterns between AWS GovCloud (US) and AWS commercial partition. Zusätzlich zur zuvor gezeigten Customer-Gateway-Lösung können Partner, die in Direct-Connect-PoPs präsent sind, partitionenübergreifende Konnektivitätsservices bereitstellen. Diese Services können Traffic von einem Direct-Connect-PoP zu einem anderen transportieren. Ein solches Setup ermöglicht dedizierte Leitungen zwischen den Direct-Connect-PoPs der AWS European Sovereign Cloud und Direct-Connect-Standorten in anderen Partitionen.

Da IAM-Anmeldeinformationen partitionenübergreifend nicht funktionieren, müssen Sie separate Rollen erstellen oder externe Identitätsanbieter verwenden. Gängige Ansätze umfassen IAM-Rollen mit Vertrauensstellungen und External IDs, regionale Endpunkte von AWS Security Token Service (AWS STS), ressourcenbasierte Policies oder partitionenübergreifende Rollen, die über AWS Organizations verwaltet werden. Ein modernes Best Practice ist die Föderation von Identitäten aus einem zentralen Identity Provider in mehrere Partitionen, um IAM-Benutzer nach Möglichkeit zu vermeiden. Wenn dennoch IAM-Benutzer eingesetzt werden, können Anmeldeinformationen in AWS Secrets Manager gespeichert, mit AWS Lambda rotiert und durch einen Backup-Benutzer hinsichtlich Verfügbarkeit abgesichert werden. Diese Patterns werden häufig mit Standardzugriffskontrollen kombiniert, etwa mit Amazon API Gateway und Authorizers, um partitionenübergreifende Interaktionen abzusichern. Einen tieferen Einblick in partitionenübergreifende Authentifizierung und Autorisierung mit AWS IAM bietet der Beitrag IAM Identity Center for AWS environments spanning AWS GovCloud (US) and standard Regions.

Bei der Absicherung der Kommunikation zwischen AWS-Partitionen bieten zertifikatbasierte Ansätze sowohl Chancen als auch Herausforderungen. Da Zertifikate aus AWS Certificate Manager (ACM) und AWS Private Certificate Authority (AWS Private CA) an einzelne Partitionen gebunden sind, müssen Sie in der Regel in jeder Umgebung separate PKI-Infrastrukturen bereitstellen und betreiben – einschließlich dedizierter Root-CAs und der manuellen Handhabung privater Schlüsselübertragungen. Um eine sichere partitionenübergreifende Kommunikation herzustellen, kann eine weitergehende Lösung auf doppelt signierten Zertifikaten basieren, bei denen Root-CAs in jeder Partition die Zertifikate der jeweils anderen Seite gegenzeichnen. Dadurch entsteht eine bidirektionale Vertrauenskette. Die Umsetzung erfordert die Einrichtung von Root-CAs mit AWS Certificate Manager Private CA, Cross-Signing-Vereinbarungen, das Management von Trust Stores über Partitionen hinweg sowie die Handhabung komplexer Zertifikatsvalidierungen und Sperrprüfungen. Zusätzlich müssen unterschiedliche regulatorische Anforderungen eingehalten und detaillierte Audit-Trails vorgehalten werden. Auch wenn dieser Ansatz die operative Komplexität erhöht, ist er essenziell, um authentifizierte und verschlüsselte Kommunikation über isolierte Partitionen hinweg zu ermöglichen – insbesondere in regulierten Umgebungen, in denen Security und Compliance oberste Priorität haben.

AWS Organizations über Partitionen hinweg verwalten

Die Einrichtung von Accounts der AWS European Sovereign Cloud innerhalb Ihrer AWS Organization muss in einer vollständig separaten Organization erfolgen. In der Partition AWS GovCloud (US) können Accounts, wie in der Dokumentation Inviting Accounts into an Organization for AWS GovCloud beschrieben, mit einer kommerziellen Organization gekoppelt werden. Wenn Souveränität das primäre Ziel ist, ist ein Failover in einen ausschließlich auf der AWS European Sovereign Cloud basierenden Betriebszustand deutlich einfacher, wenn die AWS-Organizations-Struktur von Beginn an getrennt aufgebaut ist. Das bedeutet jedoch nicht, dass Sie bei null anfangen müssen. Sie können dieselben Organizational Units (OUs) und Policies für die AWS European Sovereign Cloud verwalten, indem Sie Ihre vorhandene Deployment-Automatisierung wiederverwenden.

Idealerweise werden die Account-Strukturen in AWS Organizations getrennt aufgebaut, damit sich die AWS-Landschaft innerhalb der AWS European Sovereign Cloud ohne Abhängigkeit von anderen Partitionen nutzen lässt.

Abbildung 4: Konnektivität und Serviceverteilung über AWS-Partitionen hinweg, etwa in der AWS European Sovereign Cloud

Security-Kontrollen sollten pro Partition mit eigenen Service Control Policies (SCPs) umgesetzt werden, während AWS Control Tower die kommerzielle Seite verwaltet. Für das Netzwerk sind isolierte Transit Gateways, separate Amazon Route 53 DNS-Zonen sowie eine sichere partitionenübergreifende Kommunikation mithilfe von AWS PrivateLink erforderlich. Für Monitoring müssen AWS Config Aggregators und AWS Security Hub Instanzen in jeder Partition separat konfiguriert werden, während konsolidierte Abrechnung über Organizations verwaltet werden kann. Wichtig ist, die Einschränkungen zu berücksichtigen. So kann AWS Control Tower Accounts in AWS GovCloud (US) oder der AWS European Sovereign Cloud nicht direkt verwalten, und einige Funktionen von AWS Organizations stehen in diesen Partitionen nur eingeschränkt zur Verfügung. Insgesamt unterstützt dieser Ansatz Governance, Security und operative Klarheit über Partitionen hinweg.

Fazit

Der Umgang mit souveränitätsgetriebenen Cloud-Architekturen erfordert eine Strategie, die Partitionsisolation, Netzwerkkonnektivität und sichere partitionenübergreifende Authentifizierung gemeinsam adressiert. Souveränität im Failover-Design zu priorisieren, erhöht die Komplexität. Dieser Trade-off kann sich jedoch lohnen, wenn Ihre Workloads gegen geopolitische Risiken oder regulatorische Änderungen geschützt werden müssen. Beginnen Sie damit, die für Ihr Unternehmen relevanten Ausfallszenarien zu identifizieren, und wählen Sie anschließend die einfachste Architektur, die diese Risiken angemessen adressiert. Wenn Sie sich proaktiv auf sich verändernde regulatorische Rahmenbedingungen vorbereiten, können Sie in der AWS Cloud sowohl Compliance als auch Resilienz aufrechterhalten.