Cloud macht Betrieb nicht einfacher – sie macht ihn teilbar

These: Cloud verändert nicht, ob jemand Betrieb macht. Cloud verändert nur, wer ihn macht, wie sichtbar er ist – und wie teuer es wird, ihn zu ignorieren.

„Serverless“, „managed“, „as a Service“ – die Sprache der Cloud klingt, als würde Betrieb allmählich verschwinden. Das ist eine der teuersten Fehlübersetzungen der Digitalisierung. Betrieb verschwindet nicht. Er verlagert sich, er wird unsichtbarer, er wechselt manchmal die Organisation – aber jemand patcht weiterhin Systeme, überwacht Lastspitzen, plant Kapazitäten, verwaltet Zugriffsrechte, testet Wiederherstellung und trägt die Rechnung. Wer glaubt, mit dem Klick auf „Cloud“ sei das Betriebsthema erledigt, hat nur die Sichtbarkeit verloren, nicht die Verantwortung.

Genau darüber möchte ich in diesem Beitrag schreiben: warum Betrieb im Cloud-Zeitalter nicht kleiner wird, sondern anders verteilt werden muss – und warum diese Verteilung bewusst gestaltet werden sollte, statt sich zufällig zu ergeben.

Was die Lünendonk-Studie zeigt – und was sie unterbelichtet lässt #

Anfang des Jahres habe ich gemeinsam mit Christian Leinweber von MaibornWolff einen Beitrag zur Lünendonk-Studie 2026 „Digitale Souveränität – Vom Risiko zur Resilienz“ beigesteuert. Es ging um unsere Arbeit am Adaptiven Intelligenten System (AIS) – der Lern- und Lehrumgebung, die das FWU im Auftrag der Länder für allgemeinbildende Schulen betreibt. Die Studie selbst liefert einen guten Blick auf den Stand digitaler Souveränität in DACH: 155 Interviews mit IT-Verantwortlichen, GRC- und Security-Rollen, Einkauf und C-Level. Ein Ergebnis hat mich nicht überrascht, ist mir aber trotzdem hängen geblieben: Beim Ausbau digitaler Souveränität wollen Unternehmen externe Partner am häufigsten für Weiterbildung (95 %), Cloud-Migration (94 %) und den Aufbau von Governance-Strukturen (86 %) hinzuziehen – für den laufenden IT-Betrieb dagegen nur 47 Prozent. Betrieb ist damit der Bereich, den Organisationen am seltensten gezielt stärken wollen. Dabei entscheidet sich Souveränität am Ende genau dort: im Ernstfall, im Incident, in dem Moment, in dem ein Provider eine Entscheidung trifft, die nicht die eigene ist.

Wie real dieser Moment sein kann, zeigt die Studie am Beispiel eines Ereignisses aus dem Juli 2025: Vor dem französischen Senat musste der Chefjustiziar von Microsoft France einräumen, dass es keine Garantie dafür gibt, dass EU-Daten nicht in die USA übermittelt werden. 83 Prozent der befragten Unternehmen halten ein „Kill-Switch“-Szenario – dass ein Provider den Zugang zu kritischen Diensten einseitig einschränkt – für ein realistisches Risiko. Nur 57 Prozent haben dafür überhaupt eine Exit-Strategie. Diese Lücke zwischen wahrgenommenem Risiko und tatsächlicher Betriebsfähigkeit ist für mich der Kern des Themas: Souveränität wird zu oft als Beschaffungs- oder Architekturfrage behandelt und zu selten als Betriebsfrage.

In meinem Beitrag zur Studie habe ich versucht, genau diesen Punkt für den Bildungsbereich zu setzen. Wir bauen AIS bewusst „cloud native“ auf offenen Technologien wie Kubernetes. Das ermöglicht eine herstellerunabhängige Betriebsinfrastruktur mit vergleichbarer Qualität – ohne auf professionellen, arbeitsteiligen Betrieb zu verzichten. Als Informatiker und Ingenieur ist es für mich naheliegend, Redundanzen zu vermeiden und Komplexität zu reduzieren oder bewusst zu verteilen, statt sie zu verstecken. Was die Studie für mein Empfinden noch stärker hätte herausarbeiten können: Digitale Souveränität ohne belastbares Betriebsmodell bleibt eine Absichtserklärung. Der Rest dieses Beitrags ist mein Versuch, das nachzuliefern – an vier Stellen, die mir in der Praxis am meisten Kopfzerbrechen bereiten.

BSI Grundschutz und C5: Verantwortung verschieben, nicht Aufwand wegzaubern #

Zwei Rahmenwerke tauchen in fast jedem Beschaffungsgespräch auf: der BSI IT-Grundschutz und der Cloud Computing Compliance Criteria Catalogue (C5) des BSI. Grundschutz ist ein prozessorientiertes Rahmenwerk für die eigene Organisation – Bausteine, Schutzbedarfsfeststellung, Maßnahmenkataloge. C5 ist ein Anforderungskatalog speziell für Cloud-Anbieter, geprüft durch ein Testat eines Wirtschaftsprüfers, der die Umsetzung von Kontrollen zu Sicherheit, Verfügbarkeit und Transparenz bestätigt.

Mein Fazit dazu ist unverändert: Man sollte möglichst viel auf Ebene des Providers lösen. Der klassische Vergleichsfall ist Kubernetes. Wer einen eigenen Cluster betreibt, verantwortet Node-Patching, Zertifikatsrotation, Etcd-Backups, Netzwerksegmentierung, CVE-Monitoring der Control-Plane-Komponenten und die Wiederherstellung im Ernstfall – Tag für Tag, auch am Wochenende. Wer stattdessen einen managed Kubernetes-Dienst eines C5-testierten Providers nutzt, verschiebt genau diese Aufgaben auf eine Organisation, die sie für hunderte Kunden gleichzeitig professionalisiert hat und regelmäßig extern geprüft wird. Das ist in aller Regel sicherer, billiger und zuverlässiger, als es jede einzelne Organisation für sich selbst leisten könnte.

Aber dieser Effekt tritt nicht automatisch ein. Der Aufwand verschwindet nicht, er verschiebt sich nur – und das ist mir wichtig zu ergänzen, weil es in vielen Beschaffungsentscheidungen unterschlagen wird. Ein C5-Testat ist eine Momentaufnahme, keine laufende Garantie; es muss regelmäßig erneuert und tatsächlich gelesen werden, nicht nur abgeheftet. Grundschutz-Bausteine auf die konkrete Cloud-Architektur zu mappen ist reale, wiederkehrende Arbeit, keine Formalie. Und die Verantwortung endet an der Grenze dessen, was der Provider liefert: Anwendungssicherheit, Konfiguration der eigenen Workloads, Identitäts- und Rechtemanagement der eigenen Nutzerinnen und Nutzer, Datenklassifizierung. Das bleibt immer bei einem selbst, egal wie gut das darunterliegende C5-Testat ist. Realistisch draufschauen heißt für mich: Provider-Verantwortung reduziert Aufwand spürbar, sie ersetzt aber nie die eigene Sorgfaltspflicht, Testate zu lesen, Kontrollen zu prüfen und die eigene Schicht sauber zu halten. Wer das ignoriert, tauscht echte Sicherheit gegen ein gutes Gefühl.

IT-Sicherheit im KI-Zeitalter: Schneller finden heißt schneller reagieren müssen #

Ein Aspekt, der mir in der öffentlichen Debatte zu KI und Sicherheit oft zu negativ gerahmt wird: dass durch KI-gestützte Code-Analyse und automatisiertes Fuzzing heute mehr Schwachstellen gefunden werden als früher. Das ist zunächst eine gute Nachricht, keine schlechte. Diese Lücken waren vorher auch schon da – sie waren nur unentdeckt, was nicht sicherer ist, sondern nur unsichtbarer. Mehr gefundene Lücken bedeuten mehr Chancen, sie zu schließen, bevor sie ausgenutzt werden.

Der Haken ist die Kehrseite derselben Entwicklung: Wenn Angreifende dieselben Werkzeuge nutzen, um Schwachstellen zu finden und Exploits zu automatisieren, verkürzt sich das Zeitfenster zwischen Bekanntwerden einer Lücke und ihrer aktiven Ausnutzung dramatisch. Genau deshalb wird Reaktionsgeschwindigkeit zur eigentlichen Sicherheitseigenschaft – wichtiger als jede einzelne Präventivmaßnahme. Und das gilt für zwei Ebenen gleichermaßen, die in der Praxis oft unterschiedlich ernst genommen werden:

• Die Supply Chain: verwendete Pakete, Basis-Images, Infrastrukturkomponenten und externe Dienste. Hier braucht es lückenlose Software Bills of Materials, automatisiertes Dependency-Scanning und – vor allem – die organisatorische Fähigkeit, ein kritisches Update nicht erst im nächsten Sprint, sondern innerhalb von Stunden auszurollen.
• Der eigene Code: Hier ist die Versuchung groß, sich hinter der Supply Chain zu verstecken, weil die eigene Codebasis kleiner und vertrauter wirkt. Genau das macht sie zu einem blinden Fleck. Auch selbst geschriebener Code braucht kontinuierliches Scanning, Reviews und – wenn eine Lücke gefunden wird – denselben Anspruch an schnellen Rollout wie bei einer fremden Abhängigkeit.

Die entscheidende Fähigkeit ist deshalb nicht „möglichst wenige Lücken haben“ – das ist eine Illusion – sondern: Wenn etwas gefunden wird, muss der schnellstmögliche Rollout möglich sein. Im Idealfall automatisiert, ausgelöst durch eine CI/CD-Pipeline, ohne manuelle Sonderfreigaben, die im Ernstfall Stunden kosten. Und im Idealfall abgesichert durch vollständige End-to-End-Tests, die genug Vertrauen schaffen, um einen Notfall-Patch ohne tagelange manuelle Nachprüfung produktiv zu bringen. Wer diese Fähigkeit nicht hat, verliert im KI-Zeitalter nicht wegen einer einzelnen Schwachstelle – sondern weil zwischen Fund und Fix zu viel Zeit vergeht.

Das Projekt PCI: gemeinsamer Betrieb statt 16 Sonderwege #

Ein konkretes Beispiel dafür, wie man Betriebsverantwortung bewusst bündelt, ist das Projekt PCI – Pädagogische Cloud-Infrastruktur, das ich mit Interesse und vielen Wünschen begleite. Die PCI ist eine länderübergreifende Initiative im Rahmen des DigitalPakt Schule, angeführt von Hamburg, gemeinsam mit Berlin, Bremen, Hessen, Nordrhein-Westfalen und Rheinland-Pfalz. Das Ziel: eine gemeinsame, souveräne Cloud-Betriebsplattform für Bildungsanwendungen, die so leistungsfähig ist wie die Angebote großer Hyperscaler, aber unter gemeinsamer, öffentlicher Kontrolle bleibt.

Gemeinsamer Betrieb ist kein Selbstzweck – er soll am Ende genau dort ankommen: bei Kindern, die zusammen lernen.

Technisch bekommen Anwendungen in der PCI eigene, logisch getrennte Umgebungen. Zentrale Dienste wie Cluster-Betrieb, Sicherheitsmechanismen und Monitoring liefert die PCI als gemeinsame Basis, während die Verantwortung für die Fachanwendungen bei den Ländern und Anbietern bleibt. Erstmals wird hier länderübergreifend diskutiert und festgelegt, welche Mindestkriterien für Hyperscaler und andere Cloud-Anbieter gelten sollen. Betriebsumgebungen werden standardisiert und gehärtet – dokumentiert in Abstimmung mit den Landesdatenschutzbehörden. Interoperabilität und die konsequente Vermeidung von Vendor-Lock-in sind dabei keine Kür, sondern erklärtes Ziel.

Was mir an PCI besonders gefällt, ist die Grundhaltung: Föderalismus wird nicht als Ausrede genutzt, jede Redundanz einzeln zu bauen, sondern als Anforderung an intelligentes Design verstanden. Die Länder bleiben im Fahrersitz für landesspezifische Ausgestaltungen – aber bei den immer gleichen Betriebsgrundlagen wird nicht mehr sechzehnmal das Rad neu erfunden. Für mich ist PCI ein direktes Beispiel für die These dieses Beitrags: Man kann Betrieb bündeln, professionalisieren und teilweise an eine gemeinsame Plattform abgeben – aber man kann ihn nicht abschaffen. Jemand betreibt die PCI, und diese Aufgabe braucht genauso viel Sorgfalt wie der Betrieb jeder einzelnen Anwendung vorher. Und die Anwendungen, die auf der PCI laufen, sind damit nicht aus der Betriebsverantwortung entlassen: PCI übernimmt die unteren Schichten – Infrastruktur, Cluster-Betrieb, gemeinsame Sicherheitsmechanismen. Die oberen Schichten aus dem Schichtenmodell weiter unten in diesem Beitrag – von der eigenen Konfiguration bis zu Kosten und Governance – bleiben bei den Fachanwendungen selbst.

Die Herausforderungen von Cloud: dynamisches Pricing und SaaS-Pricing #

Der vielleicht am meisten unterschätzte Betriebsaspekt ist gar keine technische, sondern eine ökonomische Frage: Gut gemachte Cloud darf nicht teurer sein als eine klassische On-Prem-Lösung mit vergleichbaren Scale-Out-Optionen. Das klingt banal, wird in der Praxis aber regelmäßig ignoriert – oft, weil niemand nachrechnet, sondern „Cloud“ zum Selbstzweck wird.

Zwei Maßnahmen entscheiden dabei besonders:

1. Konsequent runter- und nicht nur hochskalieren. Hochskalieren bei Lastspitzen fällt fast allen leicht, weil es sichtbar und dringlich ist. Runterskalieren – nachts, an Wochenenden, in den Ferien – wird viel seltener konsequent umgesetzt, obwohl genau hier der wirtschaftliche Vorteil der Cloud gegenüber fest dimensionierter On-Prem-Hardware liegt. Ungenutzte, aber weiterlaufende Kapazität ist im Cloud-Modell schlicht verschenktes Geld.
2. Dauerhaft benötigte Ressourcen gesondert einkaufen. Für Grundlast, die ohnehin permanent gebraucht wird, lohnt sich On-Demand-Pricing selten. Reserved Instances oder vergleichbare Commitment-Modelle sind hier oft deutlich günstiger – vorausgesetzt, man kennt die eigene Grundlast tatsächlich und bucht nicht aus Bequemlichkeit alles auf Abruf.

Cloud darf nie Selbstzweck sein. Deckt eine klassische Lösung alle realistischen Lastspitzen ab und ist dabei genauso resilient, sicher und komfortabel wie ihr Cloud-Pendant – aber günstiger –, dann stimmt etwas nicht. Mit der Architektur, der Beschaffung oder beidem. Zum eigentlichen Problem wird dynamisches Pricing dort, wo eine Organisation einer klassischen Haushaltslogik mit fest geplanten Jahresbudgets folgen muss. Variable Kosten treffen auf starre Budgets – diese Kombination braucht genaues, kontinuierliches Monitoring und laufende Kostensteuerung. Nicht als einmaliges Projekt, sondern als Daueraufgabe.

Und hier liegt die eigentliche Gefahr: Kostendruck darf nie dazu führen, dass Reichweite, Nutzungsfrequenz, Nutzungsintensität oder sinnvolle Funktionen eines Angebots beschnitten werden, nur um zusätzliche Infrastrukturkosten zu vermeiden. Ein Bildungsangebot, das aus Kostengründen künstlich gedrosselt wird, hat sein eigentliches Ziel verfehlt – auch wenn die Cloud-Rechnung am Monatsende gut aussieht. Kostenkontrolle ist eine Betriebsdisziplin. Sie darf nie zur Produktentscheidung durch die Hintertür werden.

Infobox: Ein ganzheitliches Betriebsmodell #

Ein ganzheitliches Betriebsmodell entsteht nicht von selbst. Es wird aus einzelnen, bewusst ausgewählten Bausteinen zusammengesetzt – fünf davon beschreibe ich hier, vom Fundament bis zur Governance.

Ganz unten steht die Infrastruktur, im Idealfall als managed Kubernetes statt als selbst gepflegter Cluster. Darauf setzen Managed Services auf: Datenbank als Dienst (DBaaS), automatisches Skalieren, Infrastructure as Code, damit Umgebungen reproduzierbar und nicht handgepflegt sind. Die nächste Schicht sorgt für Beobachtbarkeit und Wiederherstellbarkeit: Monitoring und Logging, Backup und Restore sowie GitOps-Werkzeuge wie ArgoCD oder Flux, damit ein Zielzustand jederzeit automatisiert wiederhergestellt werden kann. Darüber liegt Sicherheit und Identität: Identity- und Access-Management, sauberes Secrets-Management und automatisierte Patch-Rollouts. Ganz oben steht Governance und Kosten: FinOps und Cost-Monitoring, Kapazitätsplanung und – nicht zu vergessen – eine dokumentierte Exit-Strategie für den Fall, dass ein Provider- oder Anbieterwechsel nötig wird.

Der Trick ist nicht, jede Schicht selbst zu bauen. Der Trick ist, für jede Schicht bewusst zu entscheiden, wie viel davon ein geprüfter Provider übernimmt und wie viel eigene Steuerung zwingend bleibt – und diese Entscheidung zu dokumentieren, statt sie stillschweigend treffen zu lassen.

Cloud macht Betrieb nicht einfacher – sie macht ihn teilbar #

Wenn ich das für mich zusammenfasse: Cloud bedeutet nicht, dass Betrieb einfacher wird. Sie erlaubt aber, die Komplexität von Betrieb auf verschiedene Schultern zu verteilen – auf Provider mit C5-Testat und Skaleneffekten, auf gemeinsame Plattformen wie PCI, auf automatisierte Pipelines statt manuelle Handgriffe. Das ist ein echter Fortschritt. Aber Verteilen ist nicht dasselbe wie Verschwinden.

Wer Cloud als Ersatz für Betrieb verkauft, verspricht etwas, das nicht eingehalten wird. Wer Cloud als Werkzeug versteht, um Betrieb professioneller, geprüfter und ökonomisch sinnvoller zu verteilen, nutzt sie richtig. Genau diese Unterscheidung entscheidet am Ende darüber, ob aus digitaler Souveränität mehr wird als eine gute Absicht in einer Studie.