Sovereign Cloud Stack (SCS): Der föderierte Standard für digitale Cloud-Souveränität

Die wachsende Konzentration kritischer Unternehmens-IT auf wenige außereuropäische Hyperscaler stellt Vorstände, CIOs und Behördenleitungen vor ein tiefgreifendes strategisches Dilemma. Was vor einigen Jahren als schneller Weg zur flexiblen Skalierung begann, entpuppt sich in vielen Bilanzen als schwer kalkulierbares Kosten- und Rechtsrisiko. Einseitige Preiserhöhungen, proprietäre Schnittstellenbarrieren und der extraterritoriale Durchgriff des US CLOUD Act sowie FISA Section 702 setzen europäische Organisationen unter massiven Handlungsdruck.

Gleichzeitig scheiterten frühere Versuche, eine eigene Private Cloud auf Basis freier Software aufzubauen, in der Praxis häufig an der enormen Komplexität des Dauerbetriebs. Wer OpenStack, Ceph und Kubernetes ohne übergreifende Blaupause in Eigenregie integrierte, schuf oft eine fragile Insellösung, deren Wartung hochspezialisierte Entwicklerteams band und bei jedem Release-Wechsel erhebliche Ausfallrisiken barg.

Genau diese Lücke zwischen monopolistischer Public Cloud und isoliertem Eigenbau schließt der Sovereign Cloud Stack (SCS). Initiiert durch die Open Source Business Alliance (OSBA), gefördert durch das Bundesministerium für Wirtschaft und Klimaschutz (BMWK) und weitergeführt im Forum Digitale Souveränität, definiert SCS keinen weiteren proprietären Cloud-Anbieter, sondern einen zertifizierten, quelloffenen Referenzstandard für föderierte Rechenzentren in ganz Europa.

Das Monopol-Dilemma: Warum US-Hyperscaler und OpenStack-Inseln an Grenzen stoßen

Um die architektonische Tragweite des Sovereign Cloud Stack einzuordnen, lohnt eine nüchterne Analyse der technischen Bindungsmechanismen bei AWS, Microsoft Azure und Google Cloud. Diese Plattformen erzeugen ihren Lock-in längst nicht mehr auf der Ebene einfacher virtueller Maschinen, sondern über proprietäre Verwaltungs-, Identitäts- und Plattformdienste. Sobald Entwicklungsteams herstellerspezifische IAM-Rollen, ereignisgesteuerte Serverless-Pipelines oder proprietäre Datenbank-Wrapper einbinden, verliert die Anwendung ihre Migrationsfähigkeit.

Hinzu kommt eine Preisarchitektur, die den Datenabzug wirtschaftlich bestraft. Hohe Gebühren für ausgehenden Netzwerkverkehr (Egress Fees) sorgen dafür, dass selbst Unternehmen, die ihre Container-Workloads theoretisch auf eine andere Plattform verschieben könnten, vor den Transferkosten für Terabytes oder Petabytes an Produktivdaten zurückschrecken. In regulierten Branchen kollidiert diese faktische Unbeweglichkeit frontal mit den verschärften Aufsichtsanforderungen an die digitale Betriebsstabilität.

Auf der anderen Seite litten regionale europäische Rechenzentrumsbetreiber lange unter einer starken Fragmentierung. Zwar verfügten viele Mittelstandshoster über erstklassige Colocation-Flächen und moderne Hardware, doch jeder Anbieter pflegte eigene Management-Konsolen, abweichende Netzwerk-APIs und inkompatible VM-Flavors. Für den CIO eines Industrieunternehmens war es schlicht unmöglich, zwei europäische Provider im Aktiv-Aktiv-Verbund zu koppeln, ohne sämtliche Bereitstellungsskripte doppelt zu entwickeln.

Der Sovereign Cloud Stack überwindet diese historische Zersplitterung durch verbindliche Normierung. Indem sich sowohl öffentliche europäische Cloud-Provider als auch interne Unternehmensrechenzentren auf exakt denselben Software-Stack, identische API-Verhaltensweisen und automatisierte Konformitätstests verpflichten, entsteht erstmals ein einheitlicher europäischer Cloud-Wirtschaftsraum. Wie sich dieses Modell in die übergeordnete europäische Datenraum-Strategie einfügt, beleuchtet unser Leitfaden zu Gaia-X und digitaler Souveränität im Mittelstand.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Sovereignty by Design im Enterprise-Einsatz, zu openDesk Verwaltung im Enterprise-Einsatz sowie zu Microsoft EA Verhandlung im Enterprise-Einsatz.

Technischer Deep-Dive: Der modulare Schichtenaufbau von Ceph über OpenStack bis Cluster-API

Architektonisch gliedert sich der Sovereign Cloud Stack in vier präzise aufeinander abgestimmte Schichten: Software-Defined Storage, Infrastructure as a Service (IaaS), Container as a Service (KaaS/CaaS) sowie den automatisierten Day-2-Betriebs- und Telemetrie-Layer. Jede Schicht basiert ausschließlich auf upstream-konformer Open-Source-Software unter freien Lizenzen wie Apache 2.0, sodass keinerlei lizenzrechtliche Abhängigkeiten zu Einzelherstellern bestehen.

Das Fundament bildet ein verteilter, selbstheilender Speicher-Layer auf Basis von Ceph. Über das RADOS-Protokoll und das moderne BlueStore-Backend fasst Ceph lokale Enterprise-NVMe-Laufwerke über zahlreiche Serverknoten hinweg zu hochverfügbaren Speicher-Pools zusammen. Dabei stellt RBD (RADOS Block Device) latenzarmen Blockspeicher für virtuelle Maschinen und Datenbanken bereit, während das RADOS Gateway (RGW) eine vollständig S3- und Swift-kompatible Objektspeicherschnittstelle für Cloud-Native-Anwendungen und Backup-Archive liefert.

OpenStack IaaS mit OVN-Netzwerkvirtualisierung und normierten Flavors

Auf der darüberliegenden IaaS-Ebene orchestriert ein gehärtetes OpenStack-System sämtliche Rechen-, Netzwerk- und Speicherressourcen. Als Hypervisor agiert KVM auf einem aktuellen Ubuntu- oder Debian-Linux-Kernel. Die Netzwerkvirtualisierung erfolgt über OpenStack Neutron in Verbindung mit Open Virtual Network (OVN) und Open vSwitch, wodurch mandantengetrennte Virtual Private Clouds (VPCs), verteilte virtuelle Router, Sicherheitsgruppen und Load-Balancer via Octavia vollständig softwaredefiniert und ohne proprietäre Hardware-Appliances bereitgestellt werden.

Der entscheidende Mehrwert des SCS-Standards auf dieser Schicht liegt in den verbindlichen Spezifikationen für Flavors, Image-Metadaten und API-Profile. Während in unregulierten OpenStack-Clouds jeder Betreiber eigene Namen für CPU- und RAM-Größen vergibt, schreibt SCS eine präzise Nomenklatur vor (beispielsweise für dedizierte Kerne, Überbuchungsfaktoren, lokalen NVMe-Scratch-Speicher oder GPU-Beschleuniger). Ein OpenTofu- oder Terraform-Skript läuft dadurch ohne Änderung einer einzigen Zeile gegen jede SCS-zertifizierte Cloud.

„Wahre Cloud-Souveränität entscheidet sich nicht im Marketing-Prospekt, sondern im Stresstest eines Provider-Wechsels: Nur wenn OpenTofu-Manifeste, Kubernetes-Cluster-APIs und Ceph-Storage-Klassen über Rechenzentrumsgrenzen hinweg bit-identisch funktionieren, besitzt der CIO echte Verhandlungsmacht.“

Welche Leistungsreserven ein solcher softwaredefinierter Speicher- und Netzwerkunterbau auf moderner Hardware freisetzt, zeigen wir detailliert in unserer Referenzarchitektur zur Rechenzentrums-Autarkie mit Ceph und NVMe-over-Fabrics. Durch die Kombination aus 100-GbE-Netzwerk-Fabrics und kryptografischer Verschlüsselung ruhender wie bewegter Daten erfüllt der IaaS-Layer selbst strengste Anforderungen für Verschlusssachen und Finanztransaktionen.

Kubernetes KaaS via Cluster-API und Day-2-Automatisierung mit OSISM und Zuul

Auf der Container-Orchestrierungsebene (KaaS) verabschiedet sich der Sovereign Cloud Stack von starren, schwer wartbaren Einzelinstallationen und setzt konsequent auf den CNCF-Standard Cluster-API (CAPI) in Verbindung mit dem OpenStack-Provider (CAPO). In dieser Architektur verwaltet ein übergeordneter Management-Cluster die Lebenszyklen beliebig vieler Mandanten-Kubernetes-Cluster deklarativ über Kubernetes-eigene YAML-Manifeste.

Benötigt ein Entwicklungsteam einen neuen Produktiv-Cluster, erstellt der CAPI-Controller vollautomatisch die erforderlichen OpenStack-Netze, Sicherheitsgruppen, Octavia-Load-Balancer und Worker-Nodes, installiert ein CNCF-zertifiziertes Vanilla-Kubernetes inklusive Cilium- oder Calico-CNI sowie Cinder-CSI-Storage-Treiber und übergibt das fertige Kubeconfig-Zertifikat binnen Minuten. Rolling-Upgrades auf neue Kubernetes-Versionen, automatisches Node-Scaling und der Ersatz ausgefallener Knoten laufen vollautomatisch ohne menschlichen Eingriff ab.

Ebenso konsequent löst SCS das historische Problem des Day-2-Betriebs durch den Einsatz des Open Source Infrastructure & Service Manager (OSISM). OSISM kapselt sämtliche Infrastrukturdienste (OpenStack via Kolla-Ansible, Ceph via Ceph-Ansible, Monitoring via Prometheus, Grafana und NetBox) in versionierte Container-Images und steuert alle Konfigurationsänderungen streng deklarativ über GitOps-Workflows und das Continuous-Integration-System Zuul.

Jede Änderung an der Cloud-Konfiguration durchläuft in Zuul zunächst automatisierte Syntax-, Sicherheits- und Integrationstests, bevor sie ohne Unterbrechung der laufenden Mandanten-Workloads in die Produktion ausgerollt wird. Ergänzt wird dies durch das kontinuierliche SCS-Compliance-Tooling: Automatisierte Test-Suites prüfen zertifizierte Provider-Umgebungen fortlaufend gegen die offiziellen SCS-Qualitäts- und Sicherheitsstandards, während Keycloak mit OpenID Connect und SAML 2.0 für eine föderierte, mehrfaktor-gesicherte Identitätsverwaltung sorgt.

Architektur- und Souveränitätsvergleich: US-Hyperscaler, OpenStack-Insel und SCS-Föderation

Für eine fundierte Architekturentscheidung im Vorstand reicht es nicht aus, lediglich Lizenzpreise oder Feature-Listen gegenüberzustellen. Entscheidend ist die Bewertung der langfristigen Betriebs-, Rechts- und Wechselrisiken über den gesamten Lebenszyklus geschäftskritischer Applikationen hinweg.

Die folgende Bloomberg-Radar-Matrix vergleicht die drei relevanten Betriebsmodelle anhand der fünf zentralen Dimensionen eines europäischen Enterprise-CIOs: den proprietären US-Hyperscaler, die isolierte Inhouse-OpenStack-Eigenentwicklung und den zertifizierten Sovereign Cloud Stack im föderierten Verbund:

Die Gegenüberstellung verdeutlicht, warum der Sovereign Cloud Stack weit mehr ist als eine technische Distributionssammlung. Während isolierte Open-Source-Projekte oft daran scheitern, dass jedes Unternehmen das Rad für Deployment, Monitoring und Upgrades neu erfindet, überträgt SCS das industrielle Prinzip geteilter Referenzarchitekturen auf den europäischen Rechenzentrumsmarkt.

Alle beteiligten Provider und Großanwender entwickeln die OSISM-Playbooks, Cluster-API-Templates und Sicherheits-Baselines gemeinsam im offenen Upstream weiter. Findet ein Ingenieur bei einem beteiligten Cloud-Anbieter einen Performance-Engpass im Ceph-Netzwerkstack oder härtet eine Keystone-Richtlinie für ein BSI-Audit, profitieren wenige Tage später sämtliche anderen SCS-Betreiber automatisch von dieser Verbesserung.

Vollkostenrechnung über 60 Monate: Warum Standardisierung und Föderation die TCO senken

In Gesprächen mit dem Finanzvorstand (CFO) wird häufig die Frage gestellt, ob eine souveräne Cloud-Architektur mit den Skaleneffekten globaler US-Plattformen wirtschaftlich konkurrieren kann. Eine detaillierte Vollkostenrechnung (Total Cost of Ownership) über 60 Monate zeigt, dass für kontinuierlich laufende Enterprise-Workloads ab einer mittleren Grundlast das Gegenteil der Fall ist: Die vermeintlich günstige Public Cloud entwickelt sich durch Zusatzgebühren zum Kostentreiber.

Betrachten wir als realistisches Referenzszenario eine produktive Unternehmensumgebung mit 1.500 vCPUs, 6 Terabyte Arbeitsspeicher, 250 Terabyte hochverfügbarem NVMe-Blockspeicher, 500 Terabyte S3-Objektspeicher und einem monatlichen ausgehenden Datentransfer von 80 Terabyte über mehrere vernetzte Unternehmensstandorte und Partner-Schnittstellen. In einer typischen US-Hyperscaler-Umgebung summieren sich Compute-Instanzen (selbst mit dreijährigen Reserved Instances), Managed-Kubernetes-Aufschläge, IOPS-provisionierter Blockspeicher, NAT-Gateway-Gebühren und Egress-Traffic schnell auf 68.000 bis 75.000 Euro pro Monat.

Über den Betrachtungszeitraum von fünf Jahren (60 Monaten) entsteht beim Hyperscaler damit eine kumulierte OPEX-Gesamtbelastung von rund 4,35 Millionen Euro. Noch schwerer wiegt für die kaufmännische Risikobewertung, dass am Ende dieser Laufzeit keinerlei eigene Infrastrukturwerte vorhanden sind und ein Anbieterwechsel aufgrund proprietärer PaaS-Abhängigkeiten zusätzliche Migrations- und Refactoring-Kosten in sechsstelliger Höhe auslösen würde.

Wird exakt dieselbe Workload-Landschaft auf einer hybriden SCS-Architektur abgebildet, bei der 70 Prozent der vorhersagbaren Grundlast auf eigener oder geleaster Colocation-Hardware mit OSISM-Enterprise-Support laufen und 30 Prozent als elastische Spitzenlast über zertifizierte europäische SCS-Provider wie PlusServer oder wavestack bezogen werden, sinken die Gesamtkosten über 60 Monate inklusive Hardware-Abschreibung, Strom, Rackspace und Betriebspersonal auf rund 2,48 Millionen Euro.

Das Unternehmen erzielt damit einen direkten TCO-Vorteil von 1,87 Millionen Euro (rund 43 Prozent Kostenreduktion), eliminiert sämtliche unberechenbaren Egress-Gebühren und gewinnt durch die standardisierte API-Schicht die Freiheit, externe Cloud-Kapazitäten jederzeit im echten Preiswettbewerb zwischen verschiedenen europäischen Anbietern auszuschreiben. Eine vertiefende kaufmännische Modellrechnung bietet unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche und regulatorische Resilienz unter DORA, NIS-2 und Data Act

Ein wesentlicher Vorzug des Sovereign Cloud Stack liegt in seiner organisatorischen Flexibilität. Da derselbe Software-Stack sowohl im eigenen Serverraum als auch bei öffentlichen europäischen Cloud-Providern läuft, müssen sich IT-Entscheider nicht länger binär zwischen vollständigem Eigenbetrieb und totalem Outsourcing entscheiden, sondern können aus drei klaren Bereitstellungsmodellen wählen.

Erstens (Public Sovereign Cloud): Unternehmen, die keine eigene Rechenzentrums-Hardware betreiben möchten oder schnelle Projektkapazitäten benötigen, buchen zertifizierte SCS-Umgebungen direkt als Managed Public Cloud bei europäischen Anbietern wie PlusServer, wavestack oder dNation beziehungsweise kompatiblen europäischen Plattformen wie STACKIT und OVHcloud. Die Abrechnung erfolgt nutzungsbasiert, während dank CAPI und standardisierter OpenStack-APIs jederzeit die volle Wechselbarkeit gewahrt bleibt.

Zweitens (Private SCS im Eigenbetrieb): Konzerne, KRITIS-Betreiber, Banken und Behörden mit hohen Datenschutzanforderungen installieren die SCS-Referenzarchitektur über OSISM auf eigenen Bare-Metal-Servern in ihren Colocation-Racks. Durch kommerzielle Enterprise-Subscriptions spezialisierter deutscher Systemhäuser (wie B1 Systems, Cloud&Heat oder Garloff-Partnerstrukturen) erhalten interne Betriebsteams garantierte 24/7-SLAs und geprüfte Upgrade-Pfade ohne Lizenzgebühren pro CPU-Kern.

Drittens (Föderierte Hybrid-Cloud): Die Königsklasse für resiliente Enterprise-Architekturen verbindet den internen SCS-Cluster über einheitliche Identity-Föderation (Keycloak) und standardisierte OpenTofu-Pipelines mit einem oder mehreren externen SCS-Providern. So verbleiben hochsensible Kerndatenbanken im eigenen Rechenzentrum, während rechenintensive Entwicklungs-, KI- oder Web-Workloads dynamisch in die europäische Partner-Cloud skalieren und bei einem Standortausfall sofort umgeschwenkt werden können.

Mit dieser föderierten Architektur beantworten CIOs zugleich die drängendsten Fragen der europäischen Aufsichtsbehörden. Artikel 28 und 30 der EU-Finanzmarktverordnung DORA (Digital Operational Resilience Act) verlangen von Finanzinstituten und deren kritischen IKT-Dienstleistern nicht nur die Vermeidung einseitiger Anbieter-Konzentrationsrisiken, sondern auch dokumentierte, in der Praxis getestete Ausstiegsstrategien.

Parallel dazu verpflichtet Kapitel VI des europäischen Data Act (Verordnung EU 2023/2854) Cloud-Anbieter zur Herstellung funktionaler Äquivalenz und zur Abschaffung von Wechselgebühren. Während proprietäre Hyperscaler diese Vorgaben oft nur widerwillig auf der untersten Infrastrukturebene umsetzen, ist die schrankenlose Interoperabilität im Sovereign Cloud Stack bereits bis in die Kubernetes- und Service-Schicht hinein technisch verankert und nach BSI C5 sowie IT-Grundschutz (SYS.1.5 und SYS.1.6) auditierbar.

Der 4-Phasen-Umsetzungsfahrplan: Vom Hyperscaler-Audit zum föderierten SCS-Betrieb

Die Einführung des Sovereign Cloud Stack erfordert keinen riskanten Big-Bang-Umzug aller Bestandsanwendungen an einem einzigen Wochenende. Erfolgreiche CIOs setzen stattdessen auf eine schrittweise Transformation über sechs bis zwölf Monate, bei der zunächst neue Cloud-Native-Workloads auf der souveränen Plattform landen und bestehende Abhängigkeiten systematisch abgebaut werden.

Phase 1 (Monat 1 bis 2): Applikations-Audit, Lock-in-Triage und Sourcing-Entscheidung

Zu Beginn katalogisiert das Architektur-Team sämtliche bestehenden Cloud- und Virtualisierungs-Workloads hinsichtlich ihrer technischen Kopplung. Standardisierte Container-Anwendungen, Linux-VMs und PostgreSQL-Datenbanken werden als schnelle Migrationskandidaten (Quick Wins) markiert, während Applikationen mit tiefen Bindungen an proprietäre AWS- oder Azure-PaaS-Dienste für eine schrittweise Entkopplung über offene CNCF-Alternativen eingeplant werden.

Phase 2 (Monat 3 bis 4): Pilotierung auf einer SCS-zertifizierten Provider-Plattform

Noch bevor eigene Hardware beschafft wird, startet das Team einen produktionsnahen Proof of Concept bei einem zertifizierten europäischen SCS-Public-Cloud-Provider. Innerhalb weniger Tage richten die DevOps-Ingenieure über OpenTofu und Cluster-API die ersten standardisierten Kubernetes-Cluster ein, binden das zentrale Unternehmens-Keycloak an und validieren die bestehenden GitLab- oder GitHub-CI/CD-Pipelines, Monitoring-Dashboards (Prometheus/Grafana) sowie S3-Backup-Routinen unter realen Bedingungen.

Phase 3 (Monat 5 bis 8): Aufbau der Private-SCS-Instanz via OSISM und Workload-Migration

Sofern die TCO- und Datenschutzanalyse für einen hybriden Eigenanteil spricht, erfolgt nun die Installation des internen SCS-Clusters auf dedizierter Server-Hardware mit 25/100-GbE-Netzwerk und NVMe-Ceph-Storage mithilfe des OSISM-Frameworks. Anschließend ziehen die produktiven Container- und VM-Workloads in geordneten Wellen auf die neue Umgebung um, während das Betriebsteam die automatisierten Zuul-Upgrade-Pipelines im Regelbetrieb verankert.

Phase 4 (Monat 9 bis 12): Föderierter Failover-Stresstest und DORA-Exit-Zertifizierung

Im letzten Schritt beweist die neue Architektur ihre strategische Überlegenheit: Das Unternehmen führt eine reale Failover- und Migrationsübung durch, bei der ein kompletter Anwendungs-Stack per Knopfdruck zwischen dem internen SCS-Rechenzentrum und dem externen europäischen SCS-Provider verschoben wird. Das erfolgreiche Testprotokoll dient zugleich der internen Revision und der Finanz- bzw. BSI-Aufsicht als belastbarer Nachweis gelebter digitaler Resilienz.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur SCS-Strategie

1. Wie hoch ist unser realer Lock-in-Grad durch proprietäre PaaS- und IAM-Dienste beim aktuellen Cloud-Anbieter?

Beauftragen Sie Ihre Chefarchitekten mit einer schonungslosen Inventur: Welche Anwendungen nutzen den Hyperscaler lediglich für virtuelle Maschinen und Kubernetes, und wo sind Geschäftslogiken untrennbar mit proprietären Cloud-Datenbanken, Messaging-Queues oder IAM-Richtlinien verwoben? Erst diese Transparenz zeigt, wie hoch die tatsächlichen Wechselkosten im Ernstfall ausfallen.

2. Können wir gegenüber Aufsichtsbehörden (BaFin, BSI) einen technisch getesteten Cloud-Exit nachweisen?

Unter DORA und NIS-2 genügen theoretische Absichtserklärungen in Verträgen nicht mehr. Prüfen Sie, ob Ihr Team in der Lage ist, einen kritischen Produktiv-Service innerhalb eines definierten Zeitfensters auf eine unabhängige Infrastruktur eines Zweitanbieters umzuziehen, ohne dass dabei Datenverluste oder wochenlange Code-Anpassungen entstehen.

3. Warum sollten wir eine proprietäre oder isolierte Cloud bauen, wenn mit SCS ein zertifizierter Standard bereitsteht?

Hinterfragen Sie interne Bestrebungen, eigene OpenStack- oder Kubernetes-Plattformen von Grund auf manuell zusammenzustellen. Durch die Nutzung des vorkonfigurierten OSISM- und SCS-Referenzstacks sparen Sie tausende Personenstunden bei Integration, Härtung und Release-Tests und sichern sich den Zugang zu einem breiten europäischen Experten- und Provider-Markt.

4. Wie hoch sind unsere jährlichen Ausgaben für Egress-Traffic und Überprovisionierung bei US-Hyperscalern?

Fordern Sie vom Cloud-FinOps-Team eine Aufschlüsselung aller Netzwerk-, Snapshot-, API-Request- und Support-Aufschläge der letzten zwölf Monate an. In fast allen gewachsenen Enterprise-Umgebungen machen diese verdeckten Nebenkosten 25 bis 40 Prozent der Gesamtrechnung aus und lassen sich durch eine hybride SCS-Architektur drastisch abschmelzen.

5. Welche Governance-Regeln verhindern, dass neue Softwareprojekte erneut in proprietäre Abhängigkeiten laufen?

Verankern Sie in Ihren unternehmensweiten Architektur-Richtlinien den Grundsatz, dass neue Applikationen primär gegen offene CNCF-Standards, Cluster-API, S3-kompatiblen Objektspeicher und PostgreSQL entwickelt werden müssen. Nur wer die Portabilität bereits im Pflichtenheft vorschreibt, bewahrt seine digitale Souveränität dauerhaft.

Strategisches Fazit: Vom goldenen Käfig zur föderierten europäischen Cloud-Allianz

Die Diskussion um digitale Souveränität hat die Phase politischer Sonntagsreden endgültig hinter sich gelassen. Angesichts verschärfter geopolitischer Spannungen, explodierender Lizenz- und Cloud-Tarife sowie strenger Haftungsregeln unter DORA, NIS-2 und dem EU Data Act ist die technologische Unabhängigkeit der eigenen IT-Infrastruktur zur harten Pflichtaufgabe jeder Unternehmensführung geworden.

Der Sovereign Cloud Stack liefert europäischen CIOs genau das Werkzeug, das hierfür jahrelang fehlte: Er verbindet die Innovationskraft und Lizenzfreiheit führender Open-Source-Projekte wie OpenStack, Ceph und Kubernetes mit der industriellen Verlässlichkeit standardisierter GitOps-Betriebsprozesse und zertifizierter Multi-Provider-Föderation. Wer heute auf SCS setzt, entscheidet sich gegen digitale Erpressbarkeit und legt das Fundament für eine hochverfügbare, wirtschaftliche und uneingeschränkt souveräne Unternehmens-IT.

Häufig gestellte Fragen (FAQ) zum Sovereign Cloud Stack (SCS)