Digitale Souveränität in der Cloud ist kein Produktmerkmal

Mit der AWS European Sovereign Cloud steht Unternehmen eine neue Infrastruktur für besonders hohe europäische Souveränitätsanforderungen zur Verfügung. Doch die Entscheidung für eine Sovereign Cloud allein macht noch keine souveräne IT-Strategie. Unternehmen müssen zunächst klären, welche Kontrolle sie tatsächlich benötigen, welche Risiken sie reduzieren wollen und für welche Workloads ein höheres Souveränitätsniveau erforderlich ist.

Digitale Souveränität wird häufig wie eine Produkteigenschaft behandelt: Eine Cloud ist souverän oder sie ist es nicht. Ein Anbieter kommt aus Europa oder aus den USA. Eine Software ist Open Source oder proprietär. Für eine belastbare IT-Strategie greift diese binäre Betrachtung zu kurz.

Digitale Souveränität in der Cloud bedeutet nicht, Abhängigkeiten vollständig zu vermeiden. Entscheidend ist, ob Unternehmen diese Abhängigkeiten kennen, ihre Auswirkungen bewerten und im Bedarfsfall kontrollieren können. Damit wird digitale Souveränität zu einer Governance-Aufgabe, die Daten, Anwendungen, Infrastruktur, Plattformen, Betriebsmodelle, Prozesse und Lieferketten einbezieht.

Vollständige technologische Unabhängigkeit ist in einer global vernetzten IT kaum erreichbar. Hardware-Lieferketten, Softwarekomponenten, Internet-Infrastruktur und internationale Technologieökosysteme erzeugen Abhängigkeiten, die sich nicht vollständig vermeiden lassen. Entscheidend ist deshalb nicht, ob Abhängigkeiten existieren, sondern ob ein Unternehmen sie kennt, ihre Auswirkungen bewerten und im Bedarfsfall kontrollieren kann.

Digitale Souveränität wird damit zu einer klassischen Governance-Aufgabe: Welche Abhängigkeiten sind für welchen Geschäftsprozess akzeptabel und wo benötigen wir ein höheres Maß an Kontrolle?

Erst Anforderungen definieren, dann Technologie auswählen

Der Ausgangspunkt einer Souveränitätsstrategie sollte deshalb nicht die Auswahl eines Cloud-Anbieters sein. Zunächst muss ein Unternehmen seinen eigenen Anspruch an digitale Souveränität definieren.

Dafür lassen sich verschiedene Ebenen der IT betrachten – von Daten und Anwendungen über Infrastruktur und Plattformen bis hin zu Betriebsmodellen, Prozessen und Lieferketten. Drei Perspektiven helfen dabei, diese Komplexität zu strukturieren: Kontrolle, Compliance und Kontinuität.

Kontrolle betrachtet, wer Entscheidungshoheit über Daten, Infrastruktur, Verschlüsselung oder Lieferketten besitzt. Compliance berücksichtigt regulatorische Anforderungen ebenso wie interne Richtlinien. Kontinuität untersucht, ob Technologien, Kompetenzen und Anbieter langfristig verfügbar bleiben und realistische Exit- und Wechselmöglichkeiten bestehen.

Aus dieser Betrachtung entsteht kein allgemeingültiger Souveränitätsanspruch für das gesamte Unternehmen. Ein öffentlich zugängliches Informationssystem stellt andere Anforderungen als eine Plattform, auf der besonders sensible oder geschäftskritische Daten verarbeitet werden.

Genau deshalb ist der höchste erreichbare Souveränitätsgrad nicht automatisch das richtige Ziel.

Souveränität messbar machen

Frameworks können helfen, diese zunächst qualitative Betrachtung in einen nachvollziehbaren Bewertungsmaßstab zu überführen. Das EU Cloud Sovereignty Framework schafft beispielsweise eine strukturierte Grundlage, um Cloud-Angebote anhand definierter Souveränitätsziele und konkreter Anforderungen zu bewerten. Auch der C3A-Kriterienkatalog des BSI verfolgt das Ziel, Anforderungen an die Souveränität von Cloud-Angeboten strukturiert bewertbar zu machen.

Entscheidend ist dabei nicht, für jeden Workload das höchstmögliche Niveau zu erreichen. Unternehmen müssen vielmehr festlegen, welches Souveränitätsniveau für einen konkreten Anwendungsfall erforderlich und angemessen ist. Geschäftskritikalität, Schutzbedarf, regulatorische Vorgaben und die Auswirkungen möglicher Abhängigkeiten beeinflussen diese Entscheidung.

Daraus entsteht eine einfache Steuerungslogik: Unternehmen definieren zunächst einen Ist-Zustand und ein erforderliches Zielniveau. Die Differenz zeigt den Handlungsbedarf. Anschließend können Maßnahmen nach Risiko, Aufwand und Geschäftswert priorisiert und in die IT-Roadmap integriert werden.

Souveränität wird damit von einer abstrakten Forderung zu einem Bestandteil der IT-Governance.

Wo kommt die AWS European Sovereign Cloud ins Spiel?

Genau an diesem Punkt werden neue Angebote wie die AWS European Sovereign Cloud interessant. Seit Januar 2026 ist die erste Region der eigenständigen Cloud-Infrastruktur in Brandenburg verfügbar.

AWS hat dafür nicht lediglich eine weitere Region innerhalb seiner bestehenden europäischen Infrastruktur geschaffen. Die European Sovereign Cloud ist physisch und logisch von den bestehenden AWS Regions getrennt. Sie verfügt unter anderem über eigenständige Account-, Identity- und Billing-Systeme und ist darauf ausgelegt, vollständig innerhalb der Europäischen Union betrieben zu werden. Der operative Zugriff auf die Infrastruktur ist entsprechend qualifiziertem, in der EU ansässigem Personal vorbehalten.

Auch auf Governance-Ebene wurden zusätzliche Strukturen geschaffen. AWS beschreibt für die European Sovereign Cloud eine eigenständige Unternehmensstruktur unter EU-Recht mit europäischen Geschäftsführern und einem unabhängigen Advisory Board.

Dadurch können Unternehmen konkreter prüfen, ob für einen Workload zusätzliche Anforderungen an Datenresidenz, operative Kontrolle oder organisatorische Trennung gelten.

Das bedeutet jedoch nicht, dass jeder AWS Workload in die European Sovereign Cloud migriert werden sollte.

Die Sovereign Cloud ist kein Selbstzweck

Ein Unternehmen könnte beispielsweise zu dem Ergebnis kommen, dass für einen großen Teil seiner Workloads eine bestehende europäische AWS Region in Kombination mit technischen Kontrollen bereits das erforderliche Zielniveau erreicht.

AWS bietet dafür unterschiedliche Mechanismen. Mit dem AWS Key Management Service können Kunden die Kontrolle über ihre Verschlüsselungsschlüssel steuern. External Key Stores ermöglichen darüber hinaus, Schlüsselmaterial in einem externen Schlüsselmanagementsystem außerhalb der AWS Cloud zu halten. AWS Control Tower stellt inzwischen mehr als 245 Kontrollen in der Kategorie digitale Souveränität bereit, mit denen sich entsprechende Vorgaben technisch durchsetzen und überwachen lassen.

Für einen anderen Workload können diese Maßnahmen jedoch nicht ausreichen. Besonders hohe Anforderungen an Datenresidenz, operative Unabhängigkeit oder die organisatorische Trennung des Cloud-Betriebs können ein anderes Infrastrukturmodell erforderlich machen. Hier kann die AWS European Sovereign Cloud eine zusätzliche Option darstellen.

Die Architekturentscheidung lautet deshalb nicht „AWS oder Sovereign Cloud“. Sie kann innerhalb einer Cloud-Strategie wesentlich granularer ausfallen: Welcher Workload benötigt welche Kontrollen und welches Betriebsmodell?

Aus der Cloud-Entscheidung wird eine Portfolio-Entscheidung

Eine belastbare Souveränitätsstrategie kann dadurch zu unterschiedlichen Ergebnissen innerhalb desselben Unternehmens führen.

Unkritische Anwendungen können weiterhin auf etablierten Public-Cloud-Infrastrukturen betrieben werden. Für andere Workloads werden zusätzliche technische Kontrollen wie kundenseitig kontrollierte Verschlüsselung oder externe Schlüsselverwaltung erforderlich. Besonders sensible Anwendungen können wiederum auf einer Infrastruktur wie der AWS European Sovereign Cloud betrieben werden. Und für einzelne Anforderungen können europäische Anbieter, Open-Source-Technologien oder der eigene Rechenzentrumsbetrieb die passendere Antwort sein.

Genau darin liegt der Unterschied zwischen digitaler Souveränität und technologischer Autarkie: Souveränität verlangt nicht, sämtliche Abhängigkeiten zu eliminieren. Sie verlangt die Fähigkeit, zwischen ihnen bewusst zu wählen.

Souveränität in die IT-Strategie integrieren

Die Einführung neuer Sovereign-Cloud-Angebote sollte deshalb nicht zu einer neuen isolierten Infrastrukturstrategie führen. Souveränität muss Bestandteil bestehender Architektur-, Cloud- und Governance-Prozesse werden.

Aus der initialen Bewertung entsteht ein Zielbild. Die identifizierten Lücken werden priorisiert und in eine Roadmap überführt. Architekturprinzipien können anschließend definieren, welche Souveränitätsanforderungen bestimmte Datenklassen oder Workload-Kategorien erfüllen müssen und welche Plattformen dafür zulässig sind.

Diese Bewertung ist kein Einmalprojekt. Anbieter entwickeln ihre Angebote weiter, regulatorische Anforderungen verändern sich und auch die Kritikalität von Anwendungen kann sich verschieben. Der Souveränitätsstatus eines Workloads muss deshalb regelmäßig neu bewertet werden.

Die AWS European Sovereign Cloud erweitert dabei die verfügbaren Handlungsoptionen erheblich. Sie nimmt Unternehmen aber nicht die zentrale Entscheidung ab: Wie viel Souveränität benötigen wir tatsächlich, und an welcher Stelle in der IT?

Wer diese Frage beantworten kann, muss digitale Souveränität nicht mehr über Herkunft oder