Moderne Cloud-Strategien: Eigenbetrieb, Hybrid oder Multi-Cloud

Eigene Infrastruktur, Hybrid und Multi-Cloud

Eine eigene Infrastruktur bietet vollständige Datenhoheit, eine bekannte Lastkurve und planbare Kosten. Sie eignet sich vor allem für Workloads mit konstanter Auslastung, klaren Schutzanforderungen oder engen regulatorischen Vorgaben. Grenzen zeigt dieses Modell bei Lastspitzen, schnellen Erweiterungen oder neuen Standorten, wenn Kapazitäten nur mit Vorlauf aufgebaut werden können. Workloads mit konstanter Auslastung, hoher Schutzbedarfsklasse oder regulatorischen Auflagen passen weiter in das eigene Rechenzentrum.

Hybride Modelle koppeln das eigene Rechenzentrum an einen oder mehrere Public-Cloud-Dienste. Sensible Daten und stabile Kernsysteme bleiben intern, während elastische oder experimentelle Workloads in die Cloud wandern. Das erlaubt schrittweise Modernisierung, ohne Altsysteme sofort ablösen zu müssen.

Multi-Cloud-Setups verteilen Anwendungen auf mehrere Hyperscaler. Treibend sind Abhängigkeitsvermeidung, regionale Verfügbarkeit und die Wahl der jeweils geeigneten Plattform pro Workload. Datenbanken bei einem Anbieter, KI-Dienste bei einem anderen, Netzwerk und Identity bei einem dritten Provider. Der Vorteil ist Wahlfreiheit, der Preis dafür sind höhere Anforderungen an Governance, Identity, Kostensteuerung und Beobachtbarkeit.

In der Praxis überlagern sich die Modelle. Konzern-IT betreibt typischerweise mehrere Welten parallel. Ein klassisches Rechenzentrum für ältere Systeme, eine private Cloud-Plattform auf Kubernetes-Basis, mehrere Cloud Service Provider (CSP) für SaaS und neue Eigenentwicklungen, dazu eine Reihe spezialisierter SaaS-Anbieter. Die eigentliche strategische Frage ist dann, wie diese Landschaft konsistent betrieben, abgesichert und auditierbar gemacht wird.

Treiber jeneits der Kostendiskussion

Die klassische Begründung für Cloud-Migration lautet Kostenflexibilität und Geschwindigkeit. In den letzten Jahren haben sich die Treiber verschoben. Verschiedene Themen prägen die Plattformwahl 2026:

Datensouveränität und Resilienz: Geopolitische Spannungen und neue Anforderungen wie aus DSGVO, EU AI Act und ISO 42001 zwingen Unternehmen zur erneuten Bewertung ihrer Cloud-Standorte und Subprozessoren. Workloads mit hoher Schutzbedarfsklasse verlagern sich in souveräne Cloud-Angebote oder zurück in das eigene Rechenzentrum. Marktanalysten sprechen hier vom Effekt Geopatriation.

KI-Workloads: Training und Inferenz haben unterschiedliche Lastprofile. Training erfordert kurzfristig große GPU-Pools, Inferenz konstante Latenzen über lange Zeiträume. Token-Kosten fallen, das Nutzungsvolumen steigt überproportional, die Gesamtausgaben für KI-Infrastruktur wachsen. Die Plattform muss beide Lastformen ohne andere äußere Beeinflussung bedienen.

Lieferketten-Sicherheit: Auch die Lieferkettensicherheit rückt in den Vordergrund. Mit NIS2 steigen die Anforderungen an Risikomanagement, Meldeprozesse und Transparenz über Dienstleister und Subprozessoren. Für Unternehmen wird damit nicht nur der einzelne Provider wichtig, sondern die gesamte Kette dahinter.

Compliance-Granularität: Pauschale Provider-Testate, zum Beispiel BSI C5, decken den Provider ab, nicht den Tenant. Konfiguration, Schlüssel und Protokollierung weist der Betreiber separat nach. Prüfer 2026 erwarten Service-Granularität.

Architekturprinzipien für belastbare Multi-Cloud-Plattformen

Verschiedene Bausteine unterscheiden eine ad-hoc gewachsene Cloud-Landschaft von einer planbaren Plattform. Ein zentraler Identity-Provider mit konsistenter Föderation auf alle Hyperscaler und SaaS-Tenants reduziert die Zahl der Audit-Trails. Vorfall-Forensik nimmt einen einzigen Pfad und Berechtigungen lassen sich an einer Stelle ändern. Getrennte Identity-Stacks pro Cloud-Anbieter erzeugen Doppelarbeit und blinde Flecken im Audit.

Cloud-agnostische Werkzeuge bilden die zweite Schicht: Kubernetes für Container-Workloads, Terraform für Infrastructure-as-Code (IaC), OpenShift oder ein vergleichbarer Plattform-Layer für die Anwendungs-Runtime. Anwendungen werden einmal verpackt und müssen nicht pro Provider neu entwickelt werden. Eigene Schlüsselhoheit gilt für Datenklassen mit hohem Schutzbedarf. Customer-Managed Keys über einen External Key Manager oder eine dedizierte HSM-Anbindung verschaffen im Prüfbericht und im Schadensfall Handlungsspielraum. Provider-Managed Keys decken niedrigere Datenklassen mit geringem Verwaltungsaufwand ab.

Konfigurations-Evidenz gehört in den laufenden Prozess. Cloud Security Posture Management beobachtet die Konfiguration über alle Cloud-Umgebungen hinweg und meldet Abweichungen vom Soll-Stand. Ein einmaliges Audit-Datum bleibt eine Punkt-in-Time-Aussage, die produktive Cloud verändert sich täglich. Ein C5-Testat im Ordner ersetzt keinen Audit-Trail im Tenant.

Drei Compliance-Regime parallel bedienen

In Deutschland spielen für viele Unternehmen vor allem NIS2, BSI-C5 und je nach Branche KRITIS eine Rolle. Diese Anforderungen überschneiden sich teilweise, setzen aber unterschiedliche Schwerpunkte. KRITIS verpflichtet Betreiber kritischer Anlagen zu zweijährlichen Prüfungen mit definierter Tiefe und Sektorbezug. NIS2 zieht den Pflichtkreis über die bisherigen KRITIS-Schwellen hinaus, führt für erhebliche Vorfälle eine 24-Stunden-Frühwarnung ein und macht die Lieferkettensicherheit zum eigenständigen Prüfgegenstand. C5 wirkt eine Ebene tiefer als Mindestkontroll-Katalog für Cloud-Provider, dokumentiert über ein Testat Typ 1 oder Typ 2.

In der Praxis überlappen sich die Anforderungen zu rund zwei Dritteln. Genau das verbleibende Drittel produziert die meisten Findings. Die 24-Stunden-Uhr nach NIS2 beginnt, sobald der Betreiber Kenntnis von einem erheblichen Vorfall erhält. Provider-Alarme zählen dabei lediglich als ein möglicher Auslöser. KRITIS-Sektorvorgaben kennen abweichende Fristen, je nach Anlage und Schadensszenario. C5 wiederum verpflichtet den Provider zur Information seiner Kunden. Den eigentlichen Meldepfad an das BSI verantwortet der Betreiber selbst.

Cloud-Architekturen in KRITIS-Nähe wirken technisch belastbar. Im Audit fallen oft dieselben organisatorischen Lücken auf. Schnittstellen zwischen IT-Sicherheit, Compliance und Fachbereich bleiben undokumentiert, Meldepfade ungeübt, SaaS-Inventare lückenhaft. Mit NIS2 rückt die Lieferkette ins Zentrum der Prüfung. Drei Hyperscaler und ein Dutzend SaaS-Dienste ergeben in einem typischen Multi-Cloud-Setup rund fünfzig Lieferkettenpunkte, die fortlaufend dokumentiert und geprüft werden müssen. Ohne ein zentrales Auslagerungs-Register, das die Subprozessoren-Listen der Provider monatlich abgleicht und vertragliche Änderungsanzeigen einfordert, bleibt die Lieferkettenfrage im Audit unbeantwortet.

Datenarchitektur als Voraussetzung für KI-Workloads

KI-Projekte überleben den Sprung aus dem Pilotbetrieb in den produktiven Betrieb nur mit belastbarer Datenarchitektur. Modelle und Rechenleistung sind selten der Engpass. Punktintegrationen zwischen ERP, CRM, IoT-Sensorik und Datenplattformen erzeugen Abhängigkeiten, die mit jeder neuen Datenquelle wachsen. Eine Änderung an einem ERP-Feld kann mehrere Pipelines unbemerkt stören.

Cloud-Migration löst dieses Problem nicht automatisch. Ein ERP-Wechsel nach S/4HANA Cloud und der parallele Aufbau einer Cloud-Datenplattform verschieben zunächst nur den Ort. Ohne zentralen Integrations-Layer bleibt jede neue Datenquelle ein Einzelprojekt mit eigenem Zeitplan.

Belastbare KI-Plattformen folgen mehreren Architekturprinzipien, die im Produktivbetrieb über die Modellqualität entscheiden:

Integrations-Layer statt Punktverbindungen: Event-Streaming-Plattformen entkoppeln Datenquellen voneinander. Neue Systeme abonnieren Datenströme über definierte Topics, ohne dass bestehende Schnittstellen verändert werden müssen. Apache Kafka oder Cloud-native Pendants liefern dafür den technischen Unterbau.

Getrennte Umgebungen für Training und Inferenz: Trainingsjobs erzeugen Lastspitzen mit hohem GPU-Bedarf, produktive Inferenz braucht konstante Latenzen über lange Zeiträume. Eine gemeinsame Infrastruktur bedient beide Lastformen unzureichend und gefährdet im Ernstfall den produktiven Betrieb.

Datenmonitoring zusätzlich zum Systemmonitoring: Ein laufender Service garantiert keine gleichbleibende Datenqualität. Eine kontinuierliche Qualitätsprüfung auf Feldebene erkennt Veränderungen früh, bevor sie als fehlerhafte Modellausgabe sichtbar werden.

Technisch implementierte Governance: Rollen, Zugriffsrechte und Audit-Logs gehören in die Plattform selbst. Compliance-Dokumente ohne technische Durchsetzung sind im Audit wertlos.

Typische Schwachstellen in gewachsenen Setups

Bestimmte Muster wiederholen sich in Cloud-Projekten unabhängig von Branche und Größe. Pauschale Provider-Aussagen ohne Service-Granularität gehören zu den verlässlichsten Audit-Findings. Eine Aufstellung wir nutzen drei C5-zertifizierte Provider ohne konkrete Service-Liste pro Anlage produziert im KRITIS-Audit Beanstandungen, lange bevor die eigentliche Tiefenprüfung beginnt. Ähnlich häufig taucht der SaaS-Schatten auf. Marketing-Tools, HR-Plattformen, Legal-Lösungen und Analyse-Dienste landen im laufenden Betrieb in der Cloud, ohne im zentralen Auslagerungs-Inventar zu stehen. Spätestens bei der nächsten Schutzbedarfsfeststellung wird die Lücke sichtbar.

Identity-Stacks pro Anbieter erzeugen eine eigene Klasse von Problemen. Drei Hyperscaler und vier SaaS-Tenants mit eigenen Identity-Lösungen ergeben sieben Audit-Logs, deren Korrelation im Vorfallsfall aufwendig oder unmöglich wird. Personengebundenes Integrationswissen bleibt unsichtbar, solange die betreffenden Mitarbeiter erreichbar sind. Schnittstellen funktionieren, da diese Personen die Abhängigkeiten kennen. Ein Stellenwechsel reißt eine operative Lücke, die mit dokumentierter Architektur ausbleibt.

Geübte Vorfall-Meldepfade bleiben essenziell. Ein Eskalations-Runbook im Intranet ersetzt keine eingespielte Meldekette. Ohne eingerichteten internen Bewertungspfad verbrennt die Organisation einen Großteil der 24-Stunden-Frist mit organisatorischer Klärung.

Architekturmuster mit Audit-Robustheit

In der Praxis erweisen sich mehrere Architekturmuster als belastbar gegenüber den wiederkehrenden Fragen der KRITIS-Prüfer:

Service-granulare Inventare bilden die Basis. Jede Anlage erhält eine Liste der produktiv genutzten Cloud-Services mit Datenklasse, Standort und Testat-Nachweis. Damit lassen sich Prüferfragen direkt beantworten, bevor die formale Sichtung in eine Detail-Recherche umschlägt.

Ein vollständiges Auslagerungs-Inventar schließt SaaS-Tools mit ein. Marketing-Plattformen, HR-Systeme, Legal-Lösungen und Analyse-Dienste werden vor der produktiven Nutzung erfasst und mit Schutzbedarf, Verantwortlichkeit und Vertragsdaten hinterlegt. Eine spätere Schutzbedarfsfeststellung zeigt dann ein konsistentes Bild.

Ein zentraler Identity-Backbone reduziert die Audit-Komplexität. Hyperscaler und SaaS-Tenants föderieren ihre Identitäten über einen gemeinsamen Identity-Provider, sodass die Forensik nach einem Vorfall einen einzigen Korrelations-Pfad nutzt.

Dokumentiertes Integrationswissen sichert die operative Stabilität. Schnittstellen, Abhängigkeiten und Eskalationswege werden in einem zentralen Architektur-Repository gepflegt, das unabhängig von Einzelpersonen verfügbar ist. Stellenwechsel verlaufen dann ohne Betriebsstörung.

Geübte Vorfall-Meldepfade entscheiden über die 24-Stunden-Frist nach NIS2. Eine quartalsweise Übung mit Vertretungsregelung und Backup-Kommunikation hält Rollen und Reaktionswege präsent, sodass die Meldung an das BSI im Ernstfall innerhalb der vorgegebenen Zeit erfolgt.

Rollen und Verantwortung in der Plattform organisation

Cloud-Strategie ist eine Verbundleistung mehrerer Rollen. Die operative Plattformverantwortung verteilt sich auf mehrere Profile, deren Aufgaben sich in einer gemeinsamen Roadmap zusammenfinden und ineinandergreifen.

Der CIO orchestriert Geschwindigkeit, Kosten und Zukunftssicherheit der Gesamtplattform. Mit der Verschiebung Richtung KI-Workloads kommt eine neue Aufgabe hinzu, denn gemischte Teams aus Menschen und KI-Agenten benötigen eigene Identitäten, definierte Zugriffsrechte und einen vollständigen Audit-Trail. Der CISO setzt diese Anforderungen technisch um. Er verantwortet Auditfähigkeit, Identity-Architektur, Schlüsselhoheit und die Vorfall-Meldekette. Multi-Cloud-Setups erfordern dabei eine zusätzliche Abstraktionsebene, die Provider-übergreifende Logiken und Tools auf ein gemeinsames Steuerungsmodell führt.

Datenschutzbeauftragter (DPO) und Chief Compliance Officer (CCO) arbeiten an Nachweisbarkeit. Eine technische Plattform mit zentralem Evidenz-Layer liefert beiden eine Live-Sicht auf den Compliance-Stand pro Service und ersetzt wöchentliche Excel-Listen durch fortlaufende Telemetrie. Den strukturellen Unterbau liefert der Enterprise Architect, der wiederholbare Muster in die Architektur einbringt. Mit seiner Arbeit erhalten drei Hyperscaler und ein Dutzend SaaS-Dienste eine gemeinsame Architektursprache und bleiben langfristig wartbar.

Eine gemeinsame Plattform-Roadmap verbindet die Rollen zu einem wirksamen Steuerungsverbund. Sie koordiniert Entscheidungen über Anbieter, Schnittstellen und Compliance-Anforderungen und hält die Plattform unter durchgängiger Kontrolle.

Plattform-Roadmap statt Migrationsliste

Die Plattformfrage ist 2026 eine zusammengesetzte Entscheidung. Workload-Verteilung, Identity-Modell, Schlüsselhoheit, Compliance-Architektur und Datenintegration ergeben gemeinsam das Plattformprofil. Unternehmen, die jede dieser Ebenen einzeln planen und an einer zentralen Roadmap zusammenführen, gewinnen Steuerungstiefe und schaffen die strukturelle Basis für skalierbare KI-Workloads und belastbare Audits. Erfolgreiche Plattformstrategien beginnen daher mit der Architekturentscheidung und führen die Migration der Workloads erst im zweiten Schritt durch.