Zusammenfassung

  • Die erste Region der AWS European Sovereign Cloud liegt im Land Brandenburg, und AWS beschreibt die Infrastruktur als vollständig innerhalb der EU, physisch und logisch von anderen AWS-Regionen getrennt.
  • Die Trennung hat einen Preis: bestehende AWS-Konten sind nicht nutzbar, Konten der souveränen Cloud sind eigenständig und nicht mit anderen Regionen interoperabel. Wer umzieht, zerlegt zuerst sein Identitätssystem.
  • Der harte Teil steht nicht auf der Marketingseite, sondern im Nachtrag mit Stand 14. Mai 2026: Er macht „nur qualifiziertes EU-Personal bedient das System“ zu einer zitierfähigen Klausel und erklärt, AWS habe außerhalb der EU keine technischen Mittel für den Zugriff auf Kundeninhalte.
  • Dieselben Dokumente listen, was offen bleibt: interne Systemmetriken, die die EU verlassen dürfen, die Konsultation globaler Fachteams über „kontrollierte Mechanismen“, Support-Gesellschaften in Irland und Luxemburg sowie globales Downstream-Routing bei einigen Messaging-Diensten.
  • Die Adressschicht hat kein Dokument. Dieser Text sagt nichts über die RIPE-NCC-Mitgliedschaft der Gesellschaft, über Autonome Systeme, über angekündigte Präfixe oder darüber, welche Einheit die genutzten Adressen hält.

Zuerst die Folge: Mauersprache, Listeninhalt

Die Formulierungen von AWS klingen nach Mauerbau. „Vollständig innerhalb der EU“, „physisch und logisch von anderen AWS-Regionen getrennt“, „keine kritischen Abhängigkeiten von Infrastruktur außerhalb der EU“. Es ist das Vokabular der FAQ zur souveränen Cloud auf aws.eu und der AWS-FAQ zur digitalen Souveränität, nahezu wortgleich wiederholt.

Doch beim Weiterlesen wird aus der Mauer eine Liste. Souveränität heißt nicht „nichts kommt durch“, sondern „was kommt durch, aufgrund welcher Klausel, und wer genehmigt es“. Der Unterschied wirkt akademisch, bis Sie nach einem Vorfall einer Aufsichtsbehörde erklären müssen, welche Person aus welcher Jurisdiktion um drei Uhr morgens die Daten Ihres Kunden gesehen hat. Die Mauersprache antwortet nicht. Die Liste antwortet.

Vier deutsche Gesellschaften, vier Funktionen

AWS erklärt, für die souveräne Cloud eine neue europäische Organisation geschaffen zu haben: eine neue Muttergesellschaft und drei in Deutschland gegründete Tochtergesellschaften (siehe die Governance-Seite von AWS). Die Arbeitsteilung ist ausgeschrieben:

  • AWS European Sovereign Cloud GmbH ist die Muttergesellschaft und zugleich die im Nachtrag benannte „AWS European Sovereign Cloud Entity“;
  • Amazon Data Services European Sovereign Cloud GmbH besitzt und betreibt die zugrunde liegende Infrastruktur und ist genau der Gegenstand dieses Verzeichniseintrags;
  • AWS European Sovereign Cloud Development Centre GmbH beschäftigt das Betriebspersonal;
  • Amazon European Sovereign Cloud Trust Services GmbH hält die Vertrauenszertifikate.

Der Punkt ist nicht „alle sind deutsch“. Der Punkt ist, wo Verantwortung landet. Auf die Frage „wer hat meine Maschine angefasst“ darf die Antwort nicht die abstrakte Marke „Amazon“ sein, sondern eine juristische Person mit Namen, Sitz und Ladungsadresse im deutschen Handelsregister. Eine Marke erscheint nicht vor Gericht. Eine juristische Person erscheint dort.

Konto und Identität: der sauberste Schnitt

AWS ist deutlich: bestehende AWS-Konten lassen sich für die souveräne Cloud nicht verwenden, und deren Konten sind eigenständig und nicht mit anderen AWS-Regionen interoperabel. Das Architekturdokument ergänzt den Mechanismus: eigene Abrechnung, eigene Konten- und Identitätssysteme auf einem dedizierten Stack, sodass globale AWS-Konten Dienste der souveränen Cloud weder konfigurieren noch darauf zugreifen können (siehe die Architekturbeschreibung).

Das ist der am meisten unterschätzte Punkt des Pakets, weil er an der Oberfläche nur nach „neu anmelden“ klingt. Tatsächlich ist er ein organisatorischer Bruch: multinationale Teams können Arbeitslasten nicht „nebenbei“ hinüberschieben und Berechtigungen nicht über bestehende Identitätsbeziehungen überbrücken. Wer hineinwill, baut Personen, Rollen und Freigaben neu.

Netz: dediziert, nicht abgekoppelt

Das Vokabular lautet hier „dediziert“, nicht „isoliert“. Dedizierte Netze europäischer Anbieter, souveräne Präsenzpunkte über AWS Direct Connect, ein dediziertes Amazon Route 53 und eine europäische Root-Zertifizierungsstelle (Architekturbeschreibung). Dediziert heißt, diese Wege bedienen keine anderen Regionen; es heißt nicht, dass sie außerhalb des Internets schweben.

Auch eine souveräne Region muss geroutet werden und braucht Adressen. Und genau auf der Adressschicht schweigen diese Dokumente.

Die Vertragsebene: Betriebsversprechen werden zitierfähige Klauseln

Eine Marketingseite lässt sich schön schreiben. Ein Vertragsnachtrag nicht. Der AWS European Sovereign Cloud Addendum, zuletzt aktualisiert am 14. Mai 2026, gilt nur für Konten der souveränen Cloud und schließt AWS Training & Certification sowie AWS Professional Services ausdrücklich aus (lesen Sie den Nachtrag). Was dort steht, ist härter als die FAQ:

Nur qualifiziertes Personal der souveränen Cloud bedient die Dienste, leistet den AWS Support, betreibt die Recheninfrastruktur und kontrolliert die technischen und operativen Systeme, die Kundeninhalte und vom Kunden erzeugte Metadaten enthalten. Die Definition von „qualifiziert“ verlangt drei Dinge zugleich: Angestellter einer in der EU registrierten AWS-Gesellschaft, Resident oder Bürger der EU, und bei der Aufgabenerfüllung physisch in der EU.

Derselbe Nachtrag erklärt, dass AWS-Personal außerhalb der EU keinen Zugriff auf Kundeninhalte und vom Kunden erzeugte Metadaten hat und dass AWS außerhalb der EU keine technischen Mittel besitzt, darauf zuzugreifen — vorbehaltlich der dort genannten Ausnahmen. Er erklärt weiter, die souveräne Cloud sei so entworfen, dass sie unabhängig und auf unbestimmte Zeit betrieben werden kann, auch unabhängig von jeder Verbindung zu Infrastruktur außerhalb der EU.

Das Gewicht dieses Absatzes liegt darin, dass er ein Versprechen ist, keine Beschreibung. „Unser Personal ist in der EU“ ist eine Beschreibung. „Es sind nur diese Personen, und wir haben den übrigen keinen Fernweg gelassen“ ist ein Versprechen. Ein Versprechen lässt sich zitieren und nach einem Vorfall einklagen.

Die Liste der Lücken

Dieselben Dokumente zählen auf, was offen bleibt. Hier will dieser Text hin.

Erstens: interne Systemmetriken dürfen die EU verlassen. AWS schreibt, dass bestimmte Daten, die weder Kundeninhalte noch vom Kunden erzeugte Metadaten sind — etwa interne Systemmetriken —, die EU verlassen können, um Kapazitätsmanagement, Leistungsüberwachung, Sicherheitsfunktionen und die Unterstützung des Personals der souveränen Cloud zu tragen (Architekturbeschreibung). Technisch ist das plausibel: Kapazitätsplanung braucht den Gesamtblick. Achten Sie aber auf die Klassifikationslogik: Das Kriterium lautet „ist es Kundeninhalt?“, nicht „ist es ein Datum?“.

Zweitens: globale Fachteams bleiben konsultierbar. Das Dokument begrenzt das gesamte Personal der souveränen Cloud, einschließlich Support und Rechenzentrumsbetrieb, auf qualifizierte Personen, während globale technische Teams von AWS über kontrollierte Mechanismen konsultiert werden dürfen (ebd.). Das ist die einzige Stelle, an der das Dokument den Mechanismus nicht ausschreibt, und zugleich die Stelle, die in Verhandlungen am stärksten zu bestellen ist: Wie genau kontrolliert der Mechanismus, und wer zeichnet, wenn er es nicht tut?

Drittens: Support-Gesellschaften in Irland und Luxemburg. Die Subunternehmer-Seite führt Amazon Development Centre Ireland Limited und Amazon Web Services EMEA SARL als AWS-Gesellschaften für kundeninitiierten Support und erklärt, diese verarbeiteten keine Kundendaten, sofern der Kunde der Weitergabe im Support nicht zustimmt; der dort angegebene Stand ist zuletzt am 28. Juli 2026 aktualisiert worden (siehe die Subunternehmer-Seite). Logisch ist das sauber: Ruft man sie nicht, berühren sie einen nicht. Umgekehrt gilt es ebenso — das Log-Fragment, das Sie ins Ticket kleben, ist Ihre eigene Datenübergabe.

Viertens: Domainregistrierung bei der Key-Systems GmbH. Dieselbe Seite nennt die deutsche Key-Systems GmbH für die Domainregistrierung von Amazon Route 53. Die Domain ist die am leichtesten vergessene Schicht der Souveränitätserzählung: Die Cloud steht in Brandenburg, der DNS-Eintrag liegt im System einer anderen juristischen Person.

Fünftens: bei einigen Messaging-Diensten ist das Downstream global. Die Seite weist darauf hin, dass bei bestimmten Messaging-Diensten nachgelagerte Anbieter Daten nach Bedarf global routen und verarbeiten können. Das ist die Ausnahme von der Ausnahme: dienstbezogen, nicht regionsbezogen.

Sechstens: die Vertragspartnerin sitzt in Luxemburg. Für Konten mit Kundenstandort in der EU ist Amazon Web Services EMEA SARL mit Hauptsitz in Luxemburg die Vertragspartei (FAQ auf aws.eu). Rechenzentrum in Deutschland, Gesellschaft in Deutschland, Vertragsgegner auf Papier in Luxemburg. Das ändert nicht, wo die Daten liegen; es ändert, wo der Streit ausgetragen wird.

Diese Liste ist kein Skandal. Sie ist detaillierter als das, was die meisten Anbieter veröffentlichen. Ihr Wert liegt darin, „Souveränität“ vom Adjektiv in eine Klauselnummer zu verwandeln: Jedes „tut“ trägt eine Bedingung, jedes „tut nicht“ eine Ausnahme.

Die Evidenzgrenze: die Adressschicht hat kein Dokument

Eine Schicht blieb ohne lesbares Dokument: die der Netznummern. Die Versuche, Amazons öffentliche IP-Bereichsdaten und den Datensatz der deutschen Gesellschaft in der RIPE-NCC-Datenbank einzusehen, lieferten keinen lesbaren Inhalt. Deshalb sagt dieser Text nichts über Mitgliedschaft oder Organisationsstatus bei RIPE NCC, über Autonome Systeme, über angekündigte Präfixe und darüber, welche Einheit die genutzten Adressen hält.

Diese Lücke ist für das Souveränitätsargument nicht klein. Der Vertrag verbürgt, wer im Rechenzentrum steht; das Register zeigt, wer in der Routing-Tabelle steht. Das eine ist eine privatrechtliche Urkunde, wirksam zwischen den Parteien. Das andere ist ein öffentliches Buch, das jeder einsehen kann. Wer nur das erste prüft, prüft ein Versprechen; wer das zweite prüfen kann, prüft eine Tatsache.

Auch die Dokumentversion wandert

Ein Detail gehört festgehalten: Die Architekturbeschreibung zeichnet einen Beirat mit vier Mitgliedern, die aktuelle Governance-Seite nennt fünf (Architekturbeschreibung; Governance-Seite). Zudem beschreiben FAQ und Architekturdokument einen schrittweisen Übergang zu einem Betrieb ausschließlich durch EU-Bürger, während der Nachtrag EU-Residenten oder EU-Bürger akzeptiert.

Das ist kein Widerspruchsbeweis, sondern ein Beweis dafür, dass dasselbe Dokument weiter bearbeitet wird. Die souveräne Cloud ist keine gegossene Stele, sondern eine Satzung in Revision. Für Käufer heißt das: Die Version, die Sie unterschreiben, und die Version, die Sie drei Jahre später zitieren, können verschieden sein. Versionsnummer und Datum in die Beschaffungsakte zu schreiben, hilft mehr als der Satz „wir fordern Souveränität“.

Was also zu prüfen ist

Fünf Fragen, in dieser Reihenfolge.

Erstens: Wer ist die Vertragspartei? Ein Rechenzentrum in Deutschland bedeutet keine Vertragspartei in Deutschland.

Zweitens: In welchem Anhang steht die konkrete Form der „kontrollierten Mechanismen“, wer darf sie ändern, und wer wird über Änderungen informiert?

Drittens: Was genau fällt unter interne Systemmetriken? Wenn Ihre Compliance-Folgerung auf „nichts verlässt die EU“ beruht — ist dieser Punkt in Ihrer Architektur bereits ausgeschlossen?

Viertens: Welche Dienste gehören zur Kategorie „bestimmte Messaging-Dienste“ mit globalem Routing? Wo steht die Liste, und ändert sie sich?

Fünftens: Auf welcher öffentlichen Aufzeichnung wollen Sie die Adress- und Routing-Schicht prüfen?

Die ersten vier Fragen beantwortet dieses Dokumentpaket. Die fünfte nicht. Dort endet die Liste, und dort beginnt der Einkauf wirklich.