Was ist Sovereign Cloud und wie baut man eine (Open Source)

Eine Sovereign Cloud ist eine Infrastruktur, bei der Sie die rechtliche, operative und technische Kontrolle über Ihre Daten und Systeme behalten, statt diese Kontrolle von jemand anderem zu mieten. Die Daten liegen dort, wo Sie es bestimmen, die Verschlüsselungsschlüssel halten Sie selbst, und keine fremde Jurisdiktion kann unbemerkt auf Ihre Systeme zugreifen. Für Organisationen in Europa, und speziell in Deutschland, hat sich das von einem Nice-to-have zu einer Anforderung auf Vorstandsebene entwickelt, getrieben von DSGVO, NIS2, DORA und der Reichweite des US CLOUD Act.

Die gute Nachricht: Es gibt nicht das eine „richtige” Sovereign-Cloud-Produkt zum Kauf. Eine souveräne Private Cloud lässt sich auf viele Arten aufbauen, fast vollständig auf Basis von Open Source und offenen Standards. Dieser Leitfaden erklärt, was der Begriff tatsächlich bedeutet, und führt anschließend durch die reale Landschaft der Aufbaumöglichkeiten, sodass Sie den Ansatz an Ihren Workloads ausrichten können statt am Marketing eines Anbieters.

Was „souverän” wirklich bedeutet

Datenresidenz (wo die Bytes physisch liegen) ist nur ein Teil. Echte digitale Souveränität verbindet mehrere Aspekte miteinander:

• Jurisdiktionskontrolle - Ihre Daten bleiben außerhalb der Reichweite fremden Rechts, im Einklang mit EU-Regimen wie DSGVO, NIS2, DORA und dem EU Data Act.
• Schlüsselkontrolle - Sie halten die Verschlüsselungsschlüssel (BYOK oder vollständig HYOK), nicht der Plattformbetreiber.
• Operative Kontrolle - Sie entscheiden, wer auf die Umgebung zugreifen, sie ändern und auditieren darf.
• Portabilität - offene Standardschnittstellen (Kubernetes API, OCI, S3) bedeuten, dass Sie ohne Neuentwicklung wechseln oder umziehen können.
• Transparenz - Open-Source-Komponenten, die Sie inspizieren können, plus optionales Confidential Computing (Intel TDX, AMD SEV-SNP) für den Schutz zur Laufzeit.

Frameworks, die Sie beim Zuschnitt eines Projekts kennen sollten: Gaia-X und seine Trust-Framework-Labels, das kommende EUCS-Zertifizierungsschema der ENISA, der BSI-C5-Katalog in Deutschland und der community-getriebene Sovereign Cloud Stack (SCS). Sie geben Ihnen ein gemeinsames Vokabular mit Auditoren und Beschaffung.

Das große Missverständnis

Ein verbreiteter Mythos lautet: „Private Cloud heißt OpenStack” oder „Sie brauchen Proxmox.” Beides stimmt nicht. Private Cloud und IaaS sind Kategorien, keine Produkte. Die richtige Frage ist nicht welches Tool, sondern welche Control Plane zu Ihrer Größe, Ihrem Team und Ihrer Compliance-Aufstellung passt. Es gibt mindestens drei glaubwürdige Architekturen, und eine Sovereign Cloud kann auf jeder von ihnen aufgebaut werden.

Weg 1: Eine vollständige IaaS-Control-Plane

Das ist das klassische „Baue deine eigene Cloud”-Modell: Eine Control Plane abstrahiert gepoolte Compute-, Storage- und Netzwerkressourcen zu einer Self-Service-, mandantenfähigen Infrastruktur mit APIs, Quotas und Tenancy. Sie eignet sich für größere Bestände, Service-Provider und Teams, die wirklich cloudartige Elastizität auf eigener Hardware benötigen.

Open-Source-Optionen in dieser Kategorie sind:

• OpenStack - die vollständigste IaaS-Control-Plane, inzwischen unter der OpenInfra Foundation (die 2025 der Linux Foundation beitrat). Das Rückgrat vieler europäischer Sovereign Clouds.
• Apache CloudStack - eine ausgereifte, einfacher zu betreibende IaaS der Apache Software Foundation.
• OpenNebula - leichtgewichtig, gut geeignet für Edge und mittelgroße Private Clouds.
• Sovereign Cloud Stack (SCS) - offene Standards und Referenzimplementierung, eigens für Souveränität konzipiert, häufig auf OpenStack und Kubernetes aufgesetzt.

OpenStack ist häufig die führende VMware-Alternative für Organisationen, die vollständige IaaS ohne Lizenz-Lock-in wollen.

Weg 2: Ein Hypervisor- oder HCI-Stack

Wenn Sie hauptsächlich virtuelle Maschinen betreiben und operative Einfachheit über Hyperscale-Elastizität stellen, ist ein Hypervisor- oder hyperkonvergenter Stack oft die bessere Wahl. Diese liefern VM-Lifecycle, Clustering und Storage ohne den operativen Ballast einer vollständigen IaaS-Control-Plane.

• Proxmox VE - enorm beliebte Open-Source-Virtualisierungs- und HCI-Plattform, KVM plus LXC, zunehmend als VMware-Ersatz im Einsatz.
• oVirt - das Upstream-Projekt für Enterprise-Virtualisierungsmanagement, KVM-basiert.
• XCP-ng - der offene, Xen-basierte Hypervisor (XAPI), eine direkte Alternative für Nutzer von Citrix Hypervisor.
• Harvester - HCI auf Basis von Kubernetes und KubeVirt, die zu Weg 3 überleitet.

Unter all diesen liegen dieselben Linux-Grundlagen: KVM und libvirt für KVM-basierte Stacks, das Xen Project für XCP-ng und Ceph als bevorzugte Software-defined-Storage-Schicht.

Weg 3: Kubernetes-nativ, wo Kubernetes die Cloud ist

Ein wachsendes Muster besteht darin, eine traditionelle IaaS-Schicht ganz zu überspringen und Kubernetes selbst zur Cloud zu machen. Container sind die primäre Einheit, und VMs laufen bei Bedarf innerhalb von Kubernetes. Das passt zu cloud-nativen Organisationen und Platform-Engineering-Teams.

• KubeVirt - betreibt VMs als vollwertige Kubernetes-Workloads neben Containern.
• OpenShift Virtualization (und sein Upstream OKD Virtualization) - Enterprise-Distribution derselben Idee.
• Cluster API (CAPI) - deklarativer Cluster-Lifecycle, der Cluster selbst als verwaltete Ressourcen behandelt.
• Harvester, Incus - HCI- und System-Container-Optionen, die dieses Modell ergänzen.

Hier ist die „Control Plane” die Kubernetes API selbst, wobei das breitere CNCF-Ökosystem (Cilium für Networking, Rook/Ceph oder Longhorn für Storage, OpenBao oder Vault für Secrets) den Rest abdeckt.

Die Wahl zwischen ihnen

Es gibt keinen universellen Sieger. Eine grobe Orientierung:

• Großer mandantenfähiger Bestand oder Service-Provider-Maßstab: tendieren Sie zu OpenStack / CloudStack / SCS (Weg 1).
• VM-zentrierte Workloads, kleineres Team, schnelle Time-to-Value: tendieren Sie zu Proxmox VE / oVirt / XCP-ng (Weg 2).
• Cloud-native, Container-first, Platform-Engineering-Kultur: tendieren Sie zu einem Kubernetes-nativen KubeVirt-/Harvester-Ansatz (Weg 3).
• Viele reale Umgebungen sind Hybride, zum Beispiel OpenStack für IaaS mit darauf laufendem Kubernetes.

Die Schichten rund um die Control Plane

Egal, welchen Weg Sie wählen, Souveränität hängt von den unterstützenden Schichten ab, und auch diese sind Open-Source-first:

• Storage: Ceph, Rook, Longhorn, MinIO (S3-kompatibel) - Ihre Daten, auf Ihrer Hardware, über CSI und die S3 API.
• Networking und Security: Cilium (eBPF), Calico, WireGuard, plus Zero-Trust-Identität mit SPIFFE/SPIRE und mTLS.
• Secrets und Schlüssel: OpenBao oder HashiCorp Vault für BYOK/HYOK.
• Infrastructure as Code: OpenTofu, Terraform, Pulumi, Crossplane, Ansible und Nix, damit die gesamte Plattform reproduzierbar und auditierbar ist.
• GitOps und Delivery: Argo CD oder Flux, mit Tekton, GitHub Actions, GitLab CI oder Jenkins für Builds.
• Observability: OpenTelemetry, Prometheus und der Grafana-LGTM-Stack, alle auf offenen Standards, sodass Telemetrie portabel bleibt.

Diese offenen Standards (Kubernetes API, OCI, CSI/CNI, OpenTelemetry, S3) sind es, die eine Sovereign Cloud wirklich portabel halten, statt sie zu einer neuen Variante von Lock-in zu machen.

FAQ

Ist Sovereign Cloud dasselbe wie Datenresidenz?

Nein. Datenresidenz bedeutet, dass Ihre Daten in einer gewählten Region liegen. Souveränität fügt darüber hinaus Schlüsselkontrolle, operative Kontrolle, jurisdiktionellen Schutz und Portabilität hinzu.

Muss ich OpenStack betreiben, um souverän zu sein?

Nein. OpenStack ist eine ausgezeichnete Option, aber Apache CloudStack, OpenNebula, Proxmox VE, oVirt, XCP-ng und Kubernetes-native Stacks (KubeVirt, Harvester) können alle eine Sovereign Cloud tragen.

Ist Open Source dafür tatsächlich sicher?

Ja, und es ist in der Regel die sicherere Wahl für Souveränität. Open Source ist inspizierbar, vermeidet Vendor-Lock-in und wird von neutraler Governance getragen (Linux Foundation, CNCF, OpenInfra, Apache).

Kann ich private KI in einer Sovereign Cloud betreiben?

Ja. Selbst gehostete Inferenz (vLLM, Ollama, llama.cpp) mit Vector-Stores (pgvector, Qdrant) und PII-Redaction (Presidio) erlaubt Ihnen den Betrieb privater LLMs und RAG, bei denen Prompts und Gewichte Ihre Umgebung nie verlassen.

Wo passt Confidential Computing hinein?

Intel TDX und AMD SEV-SNP schützen Daten während der Nutzung, sodass selbst der Plattformbetreiber den Speicher der Workloads nicht lesen kann. Nützlich für Workloads mit höchsten Sicherheitsanforderungen.

Bauen Sie sie mit dem richtigen Partner

Eine Sovereign Cloud ist eine Architekturentscheidung, kein Produktkauf, und der schwierigste Teil besteht darin, den Ansatz an Ihre Workloads, Ihre Größe und Ihre Compliance-Verpflichtungen anzupassen. Rapid Solutions ist eine Engineering-Beratung und ein Managed-Services-Unternehmen (kein Cloud-Anbieter) mit Büros in Amsterdam und Dubai. Wir entwerfen und betreiben souveräne Private Clouds über das gesamte Open-Source-Ökosystem hinweg, OpenStack und CloudStack, Proxmox VE und Harvester oder Kubernetes-natives KubeVirt, mit verfügbarer EU-Datenresidenz als Fähigkeit und einem einfachen Prinzip durchgehend: Ihre Daten, Ihre Schlüssel, Ihre Kontrolle.

Ob Sie von Grund auf bauen oder uns Ihr bestehendes Setup souverän verwalten lassen möchten, nehmen Sie Kontakt mit Rapid Solutions auf, um den richtigen Ansatz zu bestimmen.