Cloud 3.0: Souveräne, hybride und intelligente Operationen

Die erste große Welle der Cloud‑Migration betonte die elastische öffentliche Infrastruktur.
Im Jahr 2026 treffen Organisationen differenziertere Entscheidungen. Der Grund liegt darin, dass die einst dominierenden Kostenvorteile öffentlicher Clouds durch steigende Anforderungen an Latenz, Datensouveränität und Energiebilanz relativiert werden.
KI‑Workloads, Datenschutzregeln, Energiekosten und geopolitische Risiken fördern Kombinationen aus Public Cloud, privater Infrastruktur, souveränen Diensten und Edge Computing. Damit können Unternehmen die Stärken jeder Umgebung gezielt nutzen, anstatt alles an einem einzigen Anbieter zu binden.

„Cloud 3.0“ ist ein nützliches Branchenlabel für diese Entwicklung, kein einzelnes Produkt oder allgemein vereinbarter Standard.

Warum sich Cloud‑Strategien diversifizieren

Drei Druckpunkte sind besonders bedeutend:

• Inferenzökonomie: Wiederholte KI‑Inferenz kann in der Public Cloud teuer sein. Der Grund ist das Pay‑as‑you‑go‑Modell: Jede einzelne Anfrage wird abgerechnet, sodass bei Millionen von Aufrufen pro Tag die kumulierten Kosten schnell die Amortisationsgrenze eigener Hardware überschreiten. Ein Workload mit Millionen von Inferenzaufrufen pro Tag kann auf eigener Hardware günstiger sein, sobald die Auslastung hoch genug ist, da die Kosten pro Nutzungseinheit sinken.

• Datensouveränität: Datenschutz‑ und sektorspezifische Regeln können einschränken, wo Daten gespeichert, verarbeitet oder übertragen werden. Anforderungen unterscheiden sich nach Jurisdiktion und Sensibilität des Workloads. Zum Beispiel legen die EU‑Datenschutzrichtlinie (GDPR), das deutsche BDSG und sektorspezifische Regeln wie HIPAA im Gesundheitswesen unterschiedliche Einschränkungen für verschiedene Organisationen fest. Verstöße führen zu hohen Geldstrafen und zu einem Vertrauensverlust bei Kunden, weshalb die Architektur zwingend an den rechtlichen Rahmen angepasst werden muss.

• Geopolitisches und Lieferkettenrisiko: Organisationen suchen zunehmend nach mehr Kontrolle über kritische Dienste und Hardware. Repatriierung ist eine mögliche Reaktion, kann aber auch die Betriebsverantwortung und Kapitalausgaben erhöhen. Einseitige Abhängigkeit von ausländischen Anbietern birgt das Risiko plötzlicher Lieferengpässe oder politischer Sanktionen, während die Rückverlagerung die interne Komplexität und den Wartungsaufwand deutlich steigert.

Cloud 3.0 als Architekturmuster

Merkmal	Frühere Cloud‑Praxis	Cloud‑3.0‑Muster
Fokus	Elastizität und Liefergeschwindigkeit	Resilienz, Souveränität und Workload‑Eignung
Deployment	Public oder Hybrid Cloud	Public, Private, Sovereign und Edge‑Kombinationen
Sicherheit	Netzwerkgrenzen plus Identität	Zero‑Trust und workload‑level Kontrollen
KI‑Optimierung	Allzweck‑Compute	Hardware‑ und latenzgerechte Inferenzplatzierung
Governance	Zentrale Richtlinien	Richtlinien, die auch Jurisdiktionen berücksichtigen

Souveräne Cloud

Eine souveräne Cloud ist darauf ausgelegt, bestimmte Daten und Operationen unter definierten rechtlichen, betrieblichen oder Eigentumskontrollen zu halten. Das genaue Versprechen unterscheidet sich zwischen Anbietern, daher sind Verträge und technische Belege entscheidender als das Label.

Hybride KI‑Infrastruktur

Ein praktisches Deployment könnte folgende Aspekte umfassen:

• Public Cloud für Kurzfristkapazität und Entwicklung;
• Private Infrastruktur für sensible oder vorhersagbare Workloads;
• Souveräne Dienste, wenn juristische Kontrollen sie erfordern;
• Edge‑Systeme, wo Latenz, Konnektivität oder lokale Verarbeitung relevant sind.

Das Betreiben dieser Umgebungen konsistent zu gestalten ist eine Herausforderung. Identität, Beobachtbarkeit, Datenbewegung, Modellversionen und Reaktionen auf Vorfälle müssen sicher über verschiedene Grenzen hinweg verwaltet werden, denn ein isoliertes Sicherheitsvorfall in einer Domäne darf nicht unbemerkt in eine andere übergreifen. verhindert ein einheitliches Identitäts-Fabric kombiniert mit einer zentralen Telemetrie-Plattform blinde Flecken und ermöglicht eine koordinierte Incident-Response über alle Segmente hinweg.

Das Edge‑Imperativ

Edge‑Verarbeitung kann Rundreise‑Latenz reduzieren und einige Daten nahe an ihrem Quellort behalten. Sie ist nützlich für industrielle Steuerung, Robotik und lokale Analyse, aber Edge‑Sites haben begrenzte Energieversorgung, physische Aussetzungen und Wartungsmöglichkeiten. Latenzverbesserungen sind je nach Workload und Netzwerk‑Konfiguration spezifisch, kein allgemeines Merkmal von Edge‑KI.

Intelligente Operationen

KI‑gestützte Operationen können Alarmsignale zusammenfassen, Kapazitätsbedarf vorhersagen, ungewöhnliches Verhalten identifizieren und Abhilfemaßnahmen vorschlagen. Autonome Änderungen erfordern jedoch Sicherheitsvorkehrungen, da eine falsche Aktion sich schnell über ein verteiltes System ausbreiten kann. Der operative Vorteil entsteht aus besserer Orchestrierung und Rückmeldung, nicht aus dem vollständigen Ersatz menschlicher Entscheider durch autonome Agenten.

Die Architekturverschiebung

Ein dauerhafter Cloud‑3.0‑Design kombiniert häufig:

1. Hybride und souveräne Integration: Klar definierte Platzierungsregeln für Daten und Workloads, dokumentiert und durch Richtlinien erzwungen.
2. Edge‑aware Connectivity: Lokale Verarbeitung, wo Latenz oder Widerstandskraft es rechtfertigen.
3. Absichtsorientierte Bereitstellung: Richtlinienbasierte Infrastruktur, die überprüft und reproduziert werden kann.

Durch die konsequente Umsetzung dieser drei Säulen entsteht ein flexibles Fundament, das sowohl regulatorischen Vorgaben als auch betrieblichen Anforderungen gerecht wird.

Das Trilemma

Teams balancieren oft drei Ziele gleichzeitig:

• Leistung: Latenz, Durchsatz und Verfügbarkeit.
• Datenschutz und Souveränität: Residenz, Kontrolle und Compliance.
• Wirtschaftlichkeit: Gesamtkosten, einschließlich Personal‑ und Betriebskosten.

Diese Ziele ziehen häufig in unterschiedliche Richtungen. Zum Beispiel muss ein DSGVO‑regulierter EU‑Workload möglicherweise bei einem souveränen Cloud‑Anbieter laufen, um Datenschutzanforderungen zu erfüllen. Dieser souveräne Anbieter bietet möglicherweise weniger GPU‑Instanztypen als ein Hyperscaler, was zu höherer Inferenzlatenz und weniger wettbewerbsfähigen Kosten führt. Die Organisation akzeptiert diese Kompromisse, weil das Risiko einer Datenschutzverletzung – und die daraus resultierenden Bußgelder sowie Imageschäden – die zusätzlichen Betriebskosten überwiegt. Es gibt keine universelle Konfiguration, die alle drei gleichzeitig maximiert.

Die Hyperscaler‑Response

Große Cloud‑Anbieter bieten regionale Kontrollen, souveräne Varianten, private Deployments und KI‑Infrastrukturdienste an. AWS hat EU Sovereign Cloud, Google Cloud Sovereign Controls, und Microsoft Azure Sovereign Landing Zones. Diese Optionen können einige Risiken reduzieren, ohne die Anbieterabhängigkeit vollständig zu eliminieren. In der Praxis beobachten Unternehmen ein Portfolio‑Modell: Mission‑kritische, regulierte Workloads landen in souveränen oder privaten Zonen, während experimentelle und burst‑intensive Aufgaben in den öffentlichen Hyperscalern verbleiben, um Agilität und Kosteneffizienz zu wahren. Die strategische Verschiebung geht also von „alle Workloads an einem Ort“ hin zur gezielten Auswahl des passendsten Deployment‑Modells für jeden Anwendungsfall.

Literaturhinweise

• NIST. (2011). The NIST Definition of Cloud Computing, SP 800-145. https://doi.org/10.6028/NIST.SP.800-145
• European Union Agency for Cybersecurity (ENISA). (2023). Cloud Cybersecurity Market Analysis. https://www.enisa.europa.eu/publications/cloud-cybersecurity-market-analysis
• European Commission. (2022). EU Cloud Rulebook. https://digital-strategy.ec.europa.eu/en/library/eu-cloud-rulebook
• Verordnung (EU) 2016/679 (DSGVO). https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679
• NIST. (2020). Zero Trust Architecture, SP 800-207. https://doi.org/10.6028/NIST.SP.800-207
• IDC. (2024). Worldwide Sovereign Cloud Forecast, 2024–2028. https://www.idc.com