Souveräne Cloud ist einer der am stärksten überladenen Begriffe in der Beschaffung von Verteidigungs-IT. Anbieter wenden ihn auf alles an — von einer Hyperscaler-Region, deren Gebäude innerhalb nationaler Grenzen stehen, bis hin zu einer vollständig air-gapped Private Cloud, die ausschließlich von eingestuften Staatsangehörigen betrieben wird. Das Label verbirgt architektonische Entscheidungen, die in der Praxis bestimmen, ob eine ausländische Regierung Offenlegung Ihrer Daten erzwingen kann, ob ein gegnerischer Nachrichtendienst die Mitarbeiter des Cloud-Betreibers korrumpieren kann und ob Ihr Notfallplan einen geopolitischen Bruch übersteht. Für Verteidigungs-Workloads sind diese Fragen tragend.

Dieser Artikel geht die praktische Landschaft souveräner Clouds im Jahr 2026 ab: die US-Hyperscaler-Regierungsregionen, die neue Generation europäischer souveräner Angebote (Bleu, Delos, T-Systems, OVH), NATO- und nationale Verteidigungsclouds sowie die On-Prem-Basis, mit der sie letztlich alle konkurrieren. Er richtet sich an Architekten, die Platzierungsentscheidungen treffen, nicht an Beschaffungsteams, die Ausschreibungen schreiben.

1. Was „souveräne Cloud" tatsächlich bedeutet

Souveränität in der Cloud ist keine einzelne Eigenschaft — sie sind drei orthogonale Vektoren, und jede ehrliche Bewertung muss jeden unabhängig benoten.

Datenresidenz ist die einfachste und am stärksten überbetonte. Sie fragt: Wo liegen die Bytes physisch? Eine Region in Frankfurt, Paris oder Warschau erfüllt die Residenz für EU-Käufer. Residenz allein ist jedoch die schwächste Souveränitätsgarantie, denn sie sagt nichts darüber aus, wer diese Bytes über die Steuerungsebene erreichen kann.

Operator-Souveränität fragt: Wer kann die Infrastruktur administrieren? Kommerzielle US-Hyperscaler-Regionen werden von global verteilten Engineering-Teams betrieben — ein L2-Ticket, das Ihren Mandanten berührt, könnte aus Indien, Irland oder Seattle bearbeitet werden. Souveränangebote in Regierungsqualität beschränken dies auf eine definierte Menge eingestufter Staatsangehöriger mit Audit-Spuren, die ausreichen, um Compliance zu belegen. SecNumCloud (Frankreich) und C5 (Deutschland) verlangen beide, dass Operatoren EU-Staatsangehörige unter EU-Jurisdiktion sind.

Jurisdiktionssouveränität ist der Vektor, der die meisten Beschaffungsannahmen bricht. Der US CLOUD Act von 2018 erlaubt US-Behörden, jedes US-eingetragene Unternehmen zur Herausgabe von Daten unter dessen Kontrolle zu zwingen, unabhängig davon, wo diese Daten physisch liegen. Ein US-Headquarter-Hyperscaler, der Infrastruktur in Frankfurt betreibt, ist also weiterhin rechtlich vom US-Gerichtssaal aus erreichbar. Die EU-Antwort — DSGVO, Schrems II, Data Act — hat die Frage geschärft, sie aber nicht gelöst. Die einzige strukturelle Antwort besteht darin, sowohl die Daten als auch die kontrollierende juristische Person unter EU-Jurisdiktion zu stellen.

Ein nützlicher Diagnostiktest: Fragen Sie, ob eine ausländische Gerichtsentscheidung, die dem Cloud-Anbieter zugestellt wird, prinzipiell die Offenlegung von Workload-Daten ohne Beteiligung Ihrer Regierung erzwingen könnte. Wenn die ehrliche Antwort „ja" lautet, haben Sie keine souveräne Cloud — Sie haben eine regionale Cloud.

2. Souveränangebote der US-Hyperscaler

Die US-Hyperscaler haben fünfzehn Jahre damit verbracht, regierungsfähige Isolation aufzubauen. Das Ergebnis ist die ausgereifteste souveräne Cloud-Ebene des Planeten — für US-affiliierte Käufer.

AWS GovCloud (US-East und US-West) ist physisch isoliert, wird nur von US-Personen administriert und ist auf FedRAMP High und DoD IL4/IL5 akkreditiert. AWS Secret Region und AWS Top Secret Region existieren für die klassifizierten Stufen, sind aber nur für akkreditierte US-Regierungs- und Auftragnehmerkäufer erreichbar. AWS hat eine European Sovereign Cloud (Brandenburg) für 2026 angekündigt, die vollständig von EU-Staatsangehörigen betrieben wird — der erste US-Hyperscaler, der sich für EU-Käufer auf diese Struktur festlegt.

Azure Government spiegelt das AWS-Modell mit Azure Government (FedRAMP High, IL5), Azure Government Secret (IL6) und Azure Government Top Secret. Microsoft hat die umfangreichste akkreditierte Präsenz auf der klassifizierten Ebene, und Azure Government erbt die meisten kommerziellen Azure-Dienste mit sechs- bis zwölfmonatiger Verzögerung. Microsoft betreibt zudem Microsoft Cloud for Sovereignty als konfigurierbare Schicht auf kommerziellem Azure für Käufer, die Souveränitätskontrollen ohne die volle Azure-Government-Akkreditierungslast wollen — siehe unseren GovCloud-Architekturvergleich für die Azure-vs-AWS-Platzierungsdetails.

Google Assured Workloads ist das leichteste der drei: eine Steuerungsebenen-Überlagerung auf kommerziellem Google Cloud, die Residenz-, Personal- und Schlüsselverwaltungsbeschränkungen durchsetzt. Es zielt auf FedRAMP High und IL5 für spezifische Konfigurationen, betreibt aber keine separate Region. Für Workloads, bei denen eine konfigurierte kommerzielle Region akzeptabel ist, kann dies die Zeit bis zur ATO verkürzen; für IL6 und höher konkurriert es nicht.

Die harte Beschränkung für Nicht-US-Käufer: GovCloud, Azure Government und die IL5/IL6-Stufen sind durch US-Personen-Zugriff und US-Exportkontrolle gesperrt. Eine französische Luftwaffeneinheit kann keine GovCloud-Kapazität kaufen. Das ist der strukturelle Grund, warum die EU-souveräne Cloud-Ebene existiert.

3. EU-Souveränangebote

Bleu ist das französische souveräne Cloud-Joint-Venture zwischen Capgemini und Orange. Es betreibt lizenzierte Microsoft-Azure-Technologie in französischen Rechenzentren, nur von französischen Staatsangehörigen betrieben, mit vollständiger Konzernkontrolle nach französischem Recht — explizit außerhalb der Reichweite des CLOUD Acts. SecNumCloud-Qualifizierung ist die zentrale Akkreditierung. Bleu ist das klarste Beispiel für das Modell „lizenzierter Hyperscaler unter souveränem Operator" und ist die Platzierungswahl für französische Verteidigungs-, Ministerial- und OIV-Workloads (Operator of Vital Importance).

Delos ist die deutsche souveräne Cloud, gebaut von SAP und Arvato Systems, wiederum auf lizenzierter Microsoft-Technologie, mit C5-Akkreditierung als Ziel und für Bund- und Länder-Workloads bestimmt. Delos und Bleu sind Geschwister: gleiches technisches Muster, unterschiedliche nationale Jurisdiktionen.

T-Systems Sovereign Cloud ist das ältere Angebot der Deutschen Telekom — souveräne Cloud ohne Hyperscaler-Lizenzschicht, auf OpenStack und proprietärer Telekom-Orchestrierung. Es zielt auf dieselbe Käuferbasis wie Delos, aber mit niedrigerer Feature-Decke und längerer operativer Erfahrung. Für Workloads, die nicht die volle Hyperscaler-API-Oberfläche benötigen, ist T-Systems oft günstiger und schneller zu onboarden.

OVHcloud nimmt eine eigene Nische ein: eine vollständig europäisch besessene Hyperscale-Alternative mit Bare-Metal-Pods, Dedicated Cloud und einer Public-Cloud-Stufe, alle unter französischer Jurisdiktion. OVH gibt nicht vor, mit der AWS-Featurevielfalt mithalten zu können, aber für compute- und speicherlastige Workloads ist es preislich wettbewerbsfähig und liefert echte Jurisdiktionssouveränität ohne US-Lizenzabhängigkeit. Für tiefere EU-vs-US-Platzierungsanalyse siehe unseren EU vs. US souveräne Cloud-Vergleich.

4. NATO- und nationale Verteidigungs-Clouds

Über der kommerziellen souveränen Ebene liegt eine Schicht, die nicht in Anbieter-Broschüren erscheint: NATO- und nationale MoD-Clouds. Sie sind die Ziele für klassifizierte Workloads, bei denen selbst SecNumCloud oder FedRAMP High unzureichend ist.

Die NCIA Software Factory und das breitere Cloud-Programm der NATO liefern die Allianz-Ebene für nationenübergreifende klassifizierte Workloads (NATO Secret und darunter). Nationale Verteidigungsministerien betreiben parallele souveräne Clouds — MODCloud in Großbritannien, die BWI-Cloud der Bundeswehr in Deutschland, die niederländische CC-NDC, die polnische MOD-Cloud — alle auf die nationale klassifizierte Stufe akkreditiert und mit alliierten Sharing-Protokollen integriert.

Darunter sitzt die eigentliche air-gapped Stufe, für TS/SCI-äquivalente Workloads. Das architektonische Muster haben wir in Air-Gapped-Deployment für die Verteidigung behandelt. Der relevante Punkt hier ist, dass Workload-Platzierungsentscheidungen diese Stufe explizit einschließen müssen — eine Workload von NATO Secret in eine kommerzielle souveräne Cloud zu verlagern ist selten, aber das Hochbewegen ist häufig, und die Architektur muss diesen Übergang ohne Neudesign überstehen.

5. Hybrid- und On-Prem-Basis

Souveräne Cloud ist nicht immer die richtige Antwort. Die On-Prem-Private-Cloud-Basis — VMware vSphere, OpenStack oder Kubernetes auf Bare Metal in einem akkreditierten nationalen Rechenzentrum — gewinnt weiterhin in drei Szenarien.

Erstens für klassifizierte oder air-gapped Workloads, die keine externe Netzwerkabhängigkeit tolerieren können. Die souveränen Hyperscaler bieten getrennte Modi (Azure Stack Hub, AWS Outposts, Google Distributed Cloud Air-Gapped), aber Preisgestaltung, Supportmodell und Operator-Zugriffsbeschränkungen verlagern die Rechnung oft zurück auf Private Cloud.

Zweitens für Steady-State-Workloads, bei denen Capex-Amortisation den Hyperscaler-Aufschlag schlägt. Eine Workload, die 24/7 mit vorhersagbarer Last über fünf Jahre läuft, ist die schlechtest mögliche wirtschaftliche Passung für jede Cloud — souverän oder nicht. Der Hyperscaler-Aufschlag gegenüber abgeschriebener Bare-Metal ist typischerweise 3–5x annualisiert.

Drittens für Organisationen, die bereits zertifizierte Rechenzentren betreiben. Die Grenzkosten eines zusätzlichen Racks sind niedrig. Die Grenzkosten für den Aufbau einer Hyperscaler-souveräne-Cloud-Betriebsfähigkeit sind hoch. Für etablierte MoD-IT-Organisationen ist die On-Prem-Erweiterung meist der günstigere Übergangsweg.

Kernaussage: Die Platzierungsfrage lautet selten „souveräne Cloud oder nicht". Sie lautet „welche Souveränitätsstufe pro Workload, und welche stufenübergreifenden Transfers sind erforderlich?" Eine moderne Verteidigungsumgebung betreibt alle vier — kommerzielle Cloud für Marketing, souveräne Cloud für CUI, nationale MoD-Cloud für Restricted-und-darüber, air-gapped Private Cloud für Secret-und-darüber — und die Architektur lebt in den Konnektoren dazwischen. Siehe den vollständigen Leitfaden zur Verteidigungs-Cybersicherheit für das umgebende Kontrollrahmenwerk.

6. Workload-Platzierungsentscheidungen

Workload-Platzierung reduziert sich auf eine kleine Menge an Klassifizierungsstufen und Kosten-Kontroll-Kompromissen. Die praktische Matrix:

Nicht-klassifiziert, öffentlich (Websites, Rekrutierungsportale, öffentliche APIs) gehört in kommerzielle Hyperscaler-Regionen in Ihrer Jurisdiktion. Souveränitätskontrollen fügen Kosten und betriebliche Reibung ohne entsprechenden Wert hinzu.

Nicht-klassifiziert, interne CUI (HR, Finanzen, interne Zusammenarbeit) gehört in souveräne Cloud — Bleu/Delos/Azure Gov-Klasse — für jurisdiktorischen Schutz von Personal- und Betriebsdaten, auch wenn keine formale klassifizierte Kennzeichnung gilt. Die CLOUD-Act-Exposition ist der entscheidende Faktor.

Restricted und NATO Restricted gehört in nationale MoD-Cloud oder die entsprechende alliierte Stufe. Kommerzielle souveräne Cloud ist hier meist aus Akkreditierungs- und nicht aus technischen Gründen unzureichend.

Secret und darüber gehört in air-gapped nationale oder Allianz-Infrastruktur. Keine kommerzielle Cloud-Akkreditierung erreicht diese Stufe 2026.

Die von Beschaffungsteams unterbudgetierten Kosten sind stufenübergreifender Transfer: jedes Mal, wenn Daten Stufen überschreiten, wird eine Cross-Domain-Lösung (Einweg-Diode, Inhaltsinspektions-Guard oder akkreditierte Cross-Domain-Appliance) benötigt. Diese sind langsam, teuer und stellen das operative Nadelöhr mehrstufiger Architekturen dar. Die Auslegung zur Minimierung erforderlicher Transfers ist wertvoller als die Optimierung innerhalb einer einzelnen Stufe.

7. Architekturmuster

Drei Muster wiederholen sich in gut konstruierten Verteidigungsumgebungen.

Steuerungsebene in souveräner Cloud, Datenebene in Mission-Cloud. Identität, Richtlinien, Monitoring und CI/CD leben in einer souveränen Cloud, wo Operator-Zugriff und Auditierung eng sind. Missions-Workloads — Sensorverarbeitung, C2-Dienste, Geodatenanalytik — laufen dort, wo Latenz und Klassifizierung es erfordern, oft auf Edge- oder Mission-Cloud-Infrastruktur. Die Steuerungsebene verwaltet die Missions-Ebene über schmale, auditierte Schnittstellen. Dies ist dieselbe Trennung, die Zero-Trust-Militärnetzwerke auf Netzwerkebene formalisieren.

Föderierte Identität über Stufen. Identität muss die Umgebung umspannen — ein Analyst sollte nicht drei separate Zugangsdaten für souveräne Cloud, MoD-Cloud und air-gapped Enklave benötigen. Föderierte Identität mit claims-basierter Autorisierung, verankert in einem souveränen Cloud-Identitätsanbieter und (über genehmigte Cross-Domain-Mechanismen) in höhere Klassifizierungsstufen projiziert, ist das Standardmuster. Das harte Problem ist der Anmeldedaten-Lebenszyklus über den Air-Gap.

Regionale Deployment-Topologie. Souveräne Cloud-Regionen sind dünner gesät als kommerzielle Regionen. Ein Multi-Region-Active-Active-Deployment, das in kommerziellem AWS trivial ist, wird in GovCloud (zwei Regionen) oder Bleu (anfänglich eine) zu einer sorgfältigen Designaufgabe. Die Failure-Domain-Mathematik ändert sich: regionale Resilienz bedeutet oft hybride Resilienz, mit einem souveränen Cloud-Primary, der zu einem On-Prem-Secondary in derselben Jurisdiktion failovert. Siehe Multi-Cloud-Verteidigungsstrategie für Details zum Resilienz-Muster.

8. Vendor-Lock-in und Exit-Planung

Souveräne Cloud-Lock-in ist schwerer als kommerzieller Cloud-Lock-in, weil die Substitutionsmenge kleiner ist. Es gibt fünf praktikable EU-souveräne Optionen. Es gibt zwei reale GovCloud-Stufen-US-Optionen. Der Hebel, den ein einzelner Anbieter über einen gefangenen Verteidigungskunden hat, ist entsprechend größer.

Die Minderung hat drei Schichten.

Infrastrukturabstraktionen. Terraform mit anbieterunabhängigen Modulen oder Crossplane auf Kubernetes lässt das Deployment-Artefakt einen Anbieterwechsel überleben. Die schwierigere Disziplin ist, anbieter-proprietäre Dienste zu vermeiden, wo eine portable Alternative existiert — Verwendung von verwaltetem Kubernetes (EKS, AKS, OVH Managed Kubernetes) statt anbieterspezifischem PaaS, S3-kompatibler Objektspeicher statt nativer Blob-APIs, PostgreSQL oder Open-Source-Datenengines statt anbieter-proprietärer Datenbanken. Die Kosten für Portabilität sind real, aber begrenzt; die Kosten für späte Migration sind unbegrenzt.

Die Exit-Übung. Die „GovCloud verlassen"-Übung — tatsächlich eine Tabletop- oder Pilot-Migration einer unkritischen Workload aus der gewählten souveränen Cloud zu einem anderen souveränen Anbieter oder zu On-Prem durchzuführen — macht die Lock-in-Kosten konkret. Verteidigungsorganisationen sollten diese Übung mindestens alle zwei Jahre pro Hauptworkload durchführen. Das Ergebnis ist ein dokumentiertes Migrationsrunbook mit Zeit- und Kostenschätzungen, das in das Beschaffungs-Risikoregister und den BCP/DR-Plan einfließt.

Vertragsklauseln. Die Beschaffung sollte maschinenlesbaren Datenexport innerhalb eines definierten Fensters, IP-Rechte an der Deployment-Automatisierung, keinen Aufschlag auf Egress zum Zweck des Anbieter-Exits und Übergangsunterstützungsbedingungen vorschreiben. Hier konvergieren ITAR-freie Software-Lieferung und Anbieter-Exit-Sprache: das Ziel ist in beiden Fällen, souveräne Optionalität unabhängig von der fortgesetzten Kooperation eines einzelnen ausländischen Anbieters zu erhalten.

Souveräne Cloud, gut umgesetzt, ist keine einzelne Beschaffungsentscheidung, sondern eine Portfoliohaltung: explizite Pro-Workload-Platzierung, bewusster stufenübergreifender Transferentwurf, Infrastrukturabstraktionen, die den Exit erhalten, und eine wiederkehrende Übung, um zu verifizieren, dass der Exit tatsächlich funktioniert. Die Anbieter werden weiterhin souveräne Labels hinzufügen. Die Architektur bestimmt, ob diese Labels etwas bedeuten.