Zusammenfassung

  • AWS verbindet die European Sovereign Cloud mit ungewöhnlich konkreten betrieblichen, rechtlichen und architektonischen Zusagen; sie sollten als überprüfbare Kontrollkarte und nicht als Standortetikett gelesen werden.
  • Eine belastbare Entscheidung prüft sechs Wege: privilegierten Betrieb, Identität und Schlüssel, Support, Softwarelieferkette, Governance und Notfalländerungsbefugnis.

Eine regulierte Anwendung kann sämtliche Kundendaten in Brandenburg halten und dennoch die wichtigste Ausnahmeentscheidung offenlassen: Wer genehmigt eine dringende Änderung, wenn die normale Befehlskette nicht verfügbar ist? Diese Frage unterstellt keinen Fehler. Sie trennt Datenresidenz — den Speicherort — von operativer Souveränität — den Personen, Zugangsmitteln, Rechtsträgern und Lieferanten, die den nächsten Systemzustand verändern können.

Das Angebot von AWS ist mehr als ein regionales Gütesiegel. Die AWS European Sovereign Cloud ist seit dem 14. Januar 2026 allgemein verfügbar; ihre erste Region liegt mit drei Availability Zones in Brandenburg. AWS erklärt, die Umgebung sei physisch und logisch von anderen Regionen getrennt, nutze eigene Identitäts-, Abrechnungs- und DNS-Systeme, halte Kundeninhalte und kundenerzeugte Metadaten in der EU und könne bei unterbrochener Verbindung zum Rest der Welt weiterarbeiten.

Der tägliche Betrieb werde von EU-Ansässigen kontrolliert; Betriebsrollen sollen schrittweise auf EU-Bürger übergehen. Eigene deutsche Gesellschaften und ein Beratungsgremium aus EU-Bürgern ergänzen die Governance-Grenze.

Das sind substanzielle Kontrollen, aber weiterhin Anbieterangaben und Vertragszusagen. Sie beweisen nicht, dass jede Kundenarchitektur automatisch dasselbe Ergebnis erreicht. Identitätsföderation, Support, Beobachtbarkeit, Schlüsselverwaltung, Bereitstellung oder Drittsoftware können Abhängigkeiten zurückbringen. Souveränität beginnt deshalb mit einem Inventar.

Der erste Weg ist der privilegierte Betrieb: alle Rollen, die Produktion ändern können, deren Rechtsraum und Arbeitgeber, die Freigabefolge und der Notfallzugriff. Der zweite betrifft Identität und kryptografische Autorität: Kontrolle über Root-Zugänge, Signatursysteme und Schlüssel sowie externe Identitätsdienste im kritischen Pfad. Der dritte ist Support: Eine lokale Annahmestelle reicht nicht, wenn komplexe Vorfälle Teams oder Diagnosewerkzeuge außerhalb der Grenze benötigen.

Der vierte Weg ist die Softwarelieferung. Eine europäische Cloud kann von Quellcodeverwaltung, Build-Systemen, Signaturschlüsseln, Schwachstelleninformationen oder Freigaberechten an anderem Ort abhängen. AWS erklärt, es gebe keine kritische Abhängigkeit von Nicht-EU-Infrastruktur. Beschaffer sollten diese Aussage in Komponenten, Ausfalltests und Nachweise übersetzen.

Der fünfte Weg ist Governance: Wer schließt Verträge, beschäftigt, vergibt Unteraufträge und kann rechtlich zum Handeln gezwungen werden? Das Addendum enthält Zusagen zu Personal, Governance, Unterauftragnehmern, Kontinuität und Vorankündigung, darunter mindestens zwölf Monate bei bestimmten wesentlichen Änderungen oder geplanter Einstellung, vorbehaltlich benannter Ausnahmen.

Der sechste Weg ist Notfallbefugnis. Zu testen sind Rechtskonflikt, Personalausfall, kompromittierter Aktualisierungskanal und eine schwere Schwachstelle mit sofortigem Patchbedarf. Für jedes Szenario gilt: Wer entscheidet, wer führt aus, welches System autorisiert, welche externe Abhängigkeit wird benötigt und welcher Nachweis bleibt zurück?

Der vorgeschlagene europäische Cloud and AI Development Act liefert eine passende Skala. Stufe eins betrifft den EU-Datenstandort. Höhere Stufen ergänzen Unabhängigkeit vom Recht von Drittstaaten, Transparenz der Softwarelieferung, EU-Eigentum und -Kontrolle sowie schließlich Kontrolle der gesamten Softwarelieferkette ohne Drittstaateneinfluss. Der Vorschlag kann sich ändern; seine Logik bleibt überzeugend: Standort ist der Anfang, nicht das Ende der Nachweisführung.

Ein Abnahmedossier sollte die Trennung der Steuerungsebene, ein Rollen- und Rechtsraumregister, Schlüsselverwahrung, Support- und Unterauftragnehmerwege, Build- und Signaturherkunft, Governance-Zusagen sowie Ergebnisse von Isolations- und Notfallübungen enthalten. Öffentliche Quellen belegen diese Punkte nicht für eine konkrete Anwendung. Der Käufer muss sie beschaffen und testen.

AWS hat die Debatte präziser gemacht. Eine faire Antwort ist weder reflexhafte Zustimmung noch Verdacht. Ein Dienst ist für eine Anwendung nur so weit souverän, wie deren entscheidende Abhängigkeiten innerhalb einer vereinbarten, prüfbaren Grenze bleiben, wenn Normalbedingungen nicht mehr gelten.

Quellen