Souveräne Cloud-Modelle internationaler Anbieter
Vergleich, Risiken und strategische Implikationen für Europa

Executive Summary

Mit der AWS Sovereign Cloud (Amazon AWS European Sovereign Cloud) unternimmt Amazon einen strukturell glaubwürdigen Schritt zur Adressierung zentraler europäischer Souveränitätsanforderungen. Der Ansatz basiert auf rechtlicher Eigenständigkeit, technischer Abschottung und operativer Autonomie.

Microsoft hingegen bezeichnet eigene Angebote zwar als „souverän“, hat bislang jedoch kein vergleichbares Modell struktureller Abschottung angekündigt.

Darüber hinaus besteht ein oft unterschätztes Risiko für europäische Cloud- und IT-Anbieter, die über US-Niederlassungen verfügen, ohne eine vergleichbare Trennung umzusetzen.

Für die EU ergibt sich daraus die Notwendigkeit klarer Mindestkriterien für Souveränität, unabhängig von der Herkunft des Anbieters.

Amazon Sovereign Cloud
AWS Sovereign Cloud

1. Ausgangslage

Digitale Souveränität wird in Europa zunehmend nicht mehr nur als Frage der Datenresidenz, sondern als Frage der tatsächlichen Zugriffsmacht verstanden. Zentral ist dabei nicht, wo Daten liegen, sondern wer im Ernstfall technisch und organisatorisch Zugriff erzwingen kann.

2. AWS Sovereign Cloud – Einordnung

Amazon AWS European Sovereign Cloud adressiert diese Fragestellung durch:

  • eine rechtlich eigenständige EU-Gesellschaft,
  • eine physisch und logisch getrennte Cloud-Infrastruktur,
  • eigene Control Plane,
  • eigenes IAM (Identity und Access Management) und eigene Schlüsselverwaltung,
  • Betrieb ausschließlich durch EU-Personal unter EU-Recht.

Durch die AWS Sovereign Cloud entsteht erstmals ein realistisches Szenario, in dem der US-Konzern im Fall einer behördlichen Anordnung argumentieren müsste:

„We are technically unable to comply.“

Amazon adressiert mit diesem Ansatz die zentralen operativen und regulatorischen Risiken bisheriger Hyperscaler-Modelle.

3. Vergleich: Microsoft und die Behauptung einer „Sovereign Cloud“

Microsoft kommuniziert ebenfalls umfangreiche Souveränitätsmaßnahmen (u. a. „EU Data Boundary“, „Customer Lockbox“, nationale Partner-Clouds). Diese Maßnahmen verbessern:

  • Transparenz,
  • Zugriffskontrollen,
  • Datenresidenz.

Sie führen jedoch nicht zu:

  • einer rechtlich eigenständigen EU-Cloud-Gesellschaft,
  • einer vollständig getrennten Control Plane,
  • einer technischen Unmöglichkeit des Zugriffs durch den US-Konzern.

Damit bleibt Microsofts Ansatz primär ein Governance- und Compliance-Modell, nicht jedoch ein strukturelles Souveränitätsmodell.

Der entscheidende Unterschied liegt darin, dass Microsoft bislang nicht glaubwürdig sagen könnte, technisch keinen Zugriff zu haben.

4. Risiko für europäische Anbieter mit US-Niederlassungen

Ein häufig übersehener Aspekt betrifft europäische Cloud- und IT-Anbieter, die:

  • Niederlassungen in den USA betreiben,
  • dort Mitarbeitende beschäftigen,
  • oder dort geschäftlich präsent sind,

ohne eine klare rechtliche und technische Abschottung umzusetzen.

In diesen Fällen gilt:

  • US-Rechtszugriffe können indirekt relevant werden,
  • selbst wenn Infrastruktur und Daten physisch in Europa liegen,
  • insbesondere bei fehlender Trennung von Management, IAM oder Schlüsselverwaltung.

Aus Souveränitätsperspektive sind solche Anbieter nicht automatisch besser gestellt als US-Hyperscaler – teilweise sogar schlechter, da Governance- und Audit-Strukturen oft weniger ausgereift sind.

5. Verbleibende Restrisiken (anbieterübergreifend)

Auch bei strukturell abgeschotteten Modellen verbleibt ein Restrisiko:

  • geopolitischer oder industriepolitischer Druck (z. B. Einschränkung von Technologietransfers oder Weiterentwicklung),
  • Abhängigkeit von proprietären Technologien,
  • Quasi-Monopolstellungen.

Dieses Risiko ist nicht anbieterspezifisch, sondern systemisch.

6. Strategische Empfehlung für die EU

Aus europäischer Sicht ist eine differenzierte Strategie erforderlich:

  1. Akzeptanz glaubwürdiger souveräner Modelle, unabhängig von der Herkunft des Anbieters, sofern:

    • technische Zugriffsunfähigkeit,
    • rechtliche Eigenständigkeit,
    • operative Autonomie

    nachweisbar sind.

  2. Parallelentwicklung europäischer Alternativen, insbesondere für kritische Infrastrukturen.

  3. Einheitliche Souveränitätskriterien, die auch für europäische Anbieter mit Drittstaaten-Präsenz gelten.

Souveränität sollte dabei funktional definiert werden – nicht politisch oder national.

7. Fazit

  • AWS setzt derzeit den höchsten strukturellen Souveränitätsstandard unter den Hyperscalern, da erstmals rechtliche Eigenständigkeit, technische Abschottung und operative Autonomie konsequent kombiniert werden.

  • Microsofts bisherige Souveränitätsmodelle bleiben überwiegend prozessual, d. h. sie basieren auf Governance-, Compliance- und Kontrollmechanismen, nicht jedoch auf einer strukturellen Unfähigkeit zum Zugriff des US-Konzerns.

  • Europäische Anbieter sind nicht per se souverän, wenn sie keine klare rechtliche, technische und organisatorische Abschottung umsetzen. Eine Niederlassung oder operative Präsenz in Drittstaaten kann – ohne entsprechende Trennung – selbst zum Souveränitätsrisiko werden.

  • Die EU sollte digitale Souveränität konsequent funktional definieren: Maßgeblich ist nicht die Herkunft eines Anbieters, sondern die tatsächliche Zugriffsmacht auf Daten, Metadaten und Systeme.

  • Eine Reduktion der Abhängigkeit von Quasi-Monopolen sollte strategisch angestrebt werden, unabhängig davon, ob diese Monopole privatwirtschaftlich, technologisch oder geopolitisch begründet sind.

  • Ebenso sollte die geopolitische Abhängigkeit von Technologien aus einzelnen Staaten systematisch reduziert werden, insbesondere dort, wo kritische Infrastrukturen, staatliche Kernfunktionen oder gesellschaftliche Grundsysteme betroffen sind.

  • Digitale Souveränität endet nicht beim Cloud-Provider, sondern umfasst alle darunterliegenden Ebenen der Wertschöpfungskette – insbesondere Hardware, Netzwerktechnologie, Halbleiter, Betriebssysteme und Basiskomponenten.

  • Digitale Souveränität entsteht nicht durch Versprechen oder Policies, sondern durch
    strukturelle Unfähigkeit zum unautorisierten Zugriff
    oder
    durch die reale Möglichkeit selbstbestimmter Kontrolle über Technologie, Betrieb und Weiterentwicklung.

 

Mehr zum Thema Digitale Souveränität ist hier zu finden.