Man nehme: Server, Netzwerk, ein Rechenzentrum. Darüber eine Schicht Virtualisierung. Darüber eine Container-Plattform, weil ohne ja heute nichts mehr geht. Darüber ein paar PaaS-Dienste, damit auch die bequemen Kollegen mitkommen. Und über alles sprenkeln wir noch ein bisschen Verwaltungs- und Managementschicht — fertig ist die souveräne Cloud.
So liest sich das Rezept auf den ersten Folien. In der Praxis stolpert das Vorhaben aber selten an einer Zutat. Es stolpert an einer Stelle, die niemand sexy findet, die in keinem Pitch-Deck auftaucht und an der trotzdem alles entschieden wird, bevor der erste Tenant auch nur einen Workload deployt — an der Landing Zone.
Im Mai 2026 halte ich auf der Cloudland in Soltau einen 45-Minuten-Slot zu genau diesem Thema. Wer es nicht nach Soltau schafft, oder wer sich vorab einlesen mag: hier die kondensierte Schreibversion.
Das Bild, mit dem ich auf der Bühne anfange, ist nicht zufällig der Berliner Flughafen. Wer sich an die BER-Geschichte erinnert: Scope ab Tag 1 maximal, Abhängigkeiten unterschätzt, vierzehn Jahre zu spät. Eine souveräne Cloud kann man sich genauso totbauen — und der Punkt, an dem das passiert, ist selten eine einzelne Fehlentscheidung. Es ist die Summe von Entscheidungen, die nie getroffen wurden, weil sie unterschätzt waren. Außerdem passt das mit der Landing Zone und einem Flughafen irgendwie sehr gut.
Souveränität ist nicht eine Frage, sondern drei
Wenn jemand „souveräne Cloud“ sagt, meint er meistens Datensouveränität. Das ist die Dimension, die aus regulatorischer Sicht im Vordergrund steht: Ich bestimme, wo meine Daten liegen, wer darauf zugreift und unter welchem Recht sie verarbeitet werden. Soweit klar. Was in der Diskussion oft fehlt, sind die anderen zwei Dimensionen — und wenn man die nicht mitdenkt, wird die erste wertlos.
Betriebssouveränität ist die Frage, wer die Infrastruktur tatsächlich betreibt. Wer fährt 24/7-Bereitschaft, wer hat Zugang zu produktiven Systemen, wie werden Incidents gehandhabt. Infrastruktursouveränität geht eine Schicht tiefer: auf welcher Hardware, mit welcher Software, in welchem Rechenzentrum läuft das Ding eigentlich.
Alle drei müssen gleichzeitig stimmen. Daten in deutsche Rechenzentren legen, aber den Betrieb von einem US-Hyperscaler-Tochterunternehmen managen lassen, ist Datensouveränität auf dem Papier — und Betriebssouveränität in der Realität nicht. Genauso wenig hilft eigene Hardware, wenn niemand den Betrieb dahinter trägt.
Warum überhaupt der Aufwand? Vier Treiber, die sich nicht wegverhandeln lassen: der US CLOUD Act, der DSGVO-Anspruch auf belastbare Verarbeitungskontrolle, BSI-Grundschutz als Betriebsanforderung statt als Audit-Show, und föderale Strukturen mit verteilten Zuständigkeiten und ohne zentrales Mandat. Das ist nicht der böse Wille der Hyperscaler — es ist strukturell.
Eine Cloud ist kein Produkt, sondern ein Stapel von Entscheidungen
Wer eine souveräne Cloud-Plattform aufbaut, hat vier Schichten zu bedienen, jede mit eigener Technologie, eigenen Betriebsanforderungen, eigenen Fallen. Hardware unten — Server, Netzwerk, Rechenzentrum. Virtualisierung und IaaS darüber: VM-Management, Software-Defined Storage, Software-Defined Network. Container-Plattform dann — Kubernetes, Operator-Framework, Image-Registry. PaaS und Kundenservices ganz oben — Managed Databases, S3-kompatibler Storage, Funktions-Plattformen.
Jede dieser Schichten verdient ihre eigene Diskussion. Die Hardware-Frage allein — VMware nach Broadcom, OpenShift im Enterprise-Betrieb, OpenStack mit lückigem Reifegrad — ist Stoff für einen eigenen Beitrag. Hier soll das nicht das Thema sein.
Was in der Praxis aber zuerst weh tut, sind nicht die Schichten als solche. Es ist, was zwischen ihnen passiert.
Cloud-Native fragt die falsche Frage
Cloud-Native als Pattern-Set ist großartig. Ehrlich. Für Anwendungen, die schnell deployt, schnell skaliert, schnell wieder verworfen werden müssen, gibt es kaum einen besseren Werkzeugkasten. Self-Service, Operator-Pattern, Microservice-Schnitt, GitOps. Funktioniert.
Das Problem dabei: Cloud-Native ist gebaut für Deploy-Speed. Eine souveräne Cloud-Plattform für mehrere Tenants braucht zuerst eine andere Antwort — die auf Tenant-Isolation. An genau dieser Stelle endet das mitgelieferte Pattern-Set abrupt.
Konkretes Beispiel. Ein Plattform-Team rollt einen MongoDB-Operator aus, damit jeder Tenant per Self-Service eine Datenbank anlegen kann. Funktioniert. Drei Tenants — Behörde X, Behörde Y, Ministerium Z — bekommen ihre eigene MongoDB-Instanz. Der Operator deployed cluster-weit, weil er als Standard-Operator-Pattern so gedacht ist. Was niemand auf dem Schirm hat: Der Operator schreibt seine Monitoring-Daten an einen gemeinsamen Endpunkt. Tenant A sieht über das Standard-Dashboard die Metriken von Tenant B.
Das Bild dazu: Hausmeister mit Generalschlüssel, der Fotos in einen gemeinsamen WhatsApp-Chat postet. In einer Wohnanlage geht das vielleicht durch. In einer Behörden-Cloud nicht.
Eine Plattform mit reinen Cloud-Native-Mustern für Multi-Tenant-Betrieb zu bauen ist — um es freundlich zu formulieren — wie ein Wolkenkratzer aus IKEA-Möbeln. Die Anleitung fehlt ab Seite drei, und am Ende fehlt immer eine Schraube. Operator kennen keinen Tenant-Begriff. Standard-Cluster-Rollen kennen keinen Tenant-Begriff. Standard-Monitoring kennt keinen Tenant-Begriff.
Was funktioniert: jeden PaaS-Dienst, jeden Operator, jede Komponente mit der gleichen Frage anfassen — wurde das ursprünglich für Multi-Tenant gebaut? Wenn nein, ist die Antwort nicht „dann lassen wir es weg“, sondern „dann muss eine Tenant-Isolations-Schicht drumherum, oder wir nehmen ein Produkt, das es kann.“ Genau diese Komponenten-Prüfung gehört in ein Architektur-Assessment, bevor die Plattform live geht — nicht danach.
Bevor sie landet, steht die Landing Zone
Landing Zone trägt ihren Namen nicht zufällig: Sie ist der Ort, an dem etwas landen soll. Bei Flughäfen entscheidet sich am Boden, ob die Maschine sauber aufsetzt — und das hängt weniger vom Piloten ab als von Entscheidungen, die lange vor dem ersten Anflug getroffen wurden. In einer Cloud-Plattform ist es nicht anders.
Der Begriff kommt aus dem AWS-Universum und heißt dort meistens „die richtige Account-Struktur plus ein paar Guardrails“. In einer souveränen Cloud ist die Aufgabe etwas größer. Eine Landing Zone ist die Summe aller Entscheidungen, die getroffen werden müssen, bevor der erste Tenant auch nur einen Workload deployt — und gleichzeitig der Rahmen, in dem mehrere getrennte Compliance-Welten in derselben Plattform leben können, ohne sich gegenseitig zu zertrampeln.
Vier Achsen, die dabei alle gleichzeitig sitzen müssen.
IAM ist die erste — und zwar nicht das Standard-„wer darf was“ aus Identity-Provider-Foliensätzen, sondern das tiefer liegende „wer darf entscheiden, wer was darf“. In einer Multi-Tenant-Plattform mit föderaler Struktur ist das die schwierigste Frage. Plattform-Admins brauchen Zugriff für den Betrieb, dürfen aber inhaltlich nicht in Tenant-Daten schauen. Tenant-Admins regeln ihre eigene Zugriffs-Hierarchie, dürfen aber nicht aus ihrem Tenant ausbrechen. Beide Linien sauber getrennt, mit Audit-Trail.
Netzwerk ist die zweite. Segmentierung, Firewall-Policies, Routing, Peering — und in einer Behörden-Cloud-Realität zusätzlich Dual-Stack, weil v4-überall historisch gewachsen ist und v6 sich nicht einfach drüberlegen lässt. Pro Tenant ein eigener Netz-Bereich, pro Compliance-Klasse eigene Segmentierungs-Regeln.
Compliance-Boundaries sind die dritte Achse. Wo hört Tenant A auf, wo fängt Tenant B an — und nicht nur daten-technisch, sondern auch organisatorisch. Wer ist im Audit-Sinne Verantwortlicher, wer ist Auftragsverarbeiter? An welcher Stelle wechselt die Haftung? Das sind nicht nur Architektur-Fragen, das sind Vertrags- und Governance-Fragen, die sich in der Architektur abbilden müssen.
Onboarding-Prozess ist die vierte. Wie kommt ein neuer Tenant rein, technisch und organisatorisch? Welche Konfigurations-Templates werden gezogen, welche Genehmigungen müssen vorliegen, wer schaltet frei?
Konkretes Beispiel, an dem man sieht, wie schnell diese vier Achsen ineinander greifen: „Bring your own IP“. Ein Tenant kommt mit einer existierenden Public-IP-Range und will sie in der neuen Plattform mitnutzen. Klingt harmlos — eine zusätzliche Route, ein DNS-Eintrag, fertig. In der Realität ist das ein vollständiges Regelwerk pro Tenant: eigene Routing-Tabelle, eigene Firewall-Policies, eigene Egress-Pfade, eigene Compliance-Bewertung. Jeder Tenant baut so seine eigene kleine Cloud in der Cloud — und das Plattform-Team pflegt am Ende N+1 Regelwerke statt eines.
Die Lehre: Die vier Achsen müssen vor dem ersten Tenant-Onboarding stehen, nicht parallel und nicht nachträglich. Eine Landing Zone, die nach dem ersten Tenant noch verändert wird, ist keine Landing Zone — sie ist ein wandernder Compliance-Rand.
Eine souveräne Cloud scheitert selten an der Technik. Sie scheitert an Governance.
Wo die Komplexität wirklich sitzt
In den Plattform-Mandaten, die ich gesehen habe, sitzt die Komplexität nicht da, wo man sie zuerst vermutet. Technik ist das einfache Teil. Was man baut, ist relativ klar beherrschbar — Architektur-Diagramme lassen sich zeichnen, Plattform-Komponenten lassen sich evaluieren, Pipelines lassen sich aufsetzen.
Was wirklich Zeit kostet, ist Governance. Wer entscheidet, wer koordiniert, wer haftet. Wie mehrere Tenant-Organisationen in derselben Plattform leben, ohne sich gegenseitig zu blockieren. Wie ein Architektur-Board die hundertste Tenant-Sonderlocke noch sauber abarbeitet, ohne in Beliebigkeit zu kippen. Wie ein Onboarding-Prozess in einer Verwaltungs-Realität funktioniert, in der drei verschiedene Beschaffungsregelwerke gleichzeitig gelten.
Mein Schätzwert nach mehreren Mandaten in dieser Welt: Technik 30 Prozent, alles andere 70 Prozent. Das sind keine Zahlen aus einer Studie, sondern Erfahrungswerte. Sie können in deinem Vorhaben abweichen. Was selten abweicht, ist die Verteilung — eine souveräne Cloud scheitert nicht am Cluster.
Mehr zu Architektur und Governance in souveränen Cloud-Projekten → /leistungen/cloud-architektur/
Bildnachweis — Beitragsbild „Baustelle des Berliner Flughafens BER, 29.03.2010″: Foto: Robert Aehnelt, CC BY-SA 3.0, via Wikimedia Commons. Foto unverändert übernommen. Diagramme: eigene Werke.
