Zwischen Hyperscaler und Datensouveränität: Die neue Kunst der intelligenten Workload-Verteilung

Die IT-Infrastruktur europäischer Unternehmen steht unter doppeltem Druck.

Regulatorische Anforderungen von der DSGVO über NIS2 bis hin zu branchenspezifischen Pflichten wie DORA oder BaFin-Rundschreiben nehmen ebenso zu wie geopolitische Unsicherheiten, während der US CLOUD Act zusätzlich grundlegende Fragen zur Datensouveränität aufwirft.

Markus Fischer, Cloud Fellow bei Exxeta, erläutert, wie eine strukturierte Migrationsstrategie unter diesen Vorzeichen gelingt.

Die neue Cloud-Realität

IT-Verantwortliche diskutieren längst nicht mehr, ob sie in die Cloud gehen. Die entscheidende Frage lautet heute: Welche Workloads gehören in welche Umgebung? Denn die Infrastruktur muss gleichermaßen technologische Handlungsfreiheit und regulatorische Sicherheit gewährleisten, was einen kontinuierlichen Balanceakt bedeutet: zwischen globaler Skalierbarkeit und europäischer Souveränität, zwischen Effizienz und Kontrolle.

Workloads klassifizieren und gezielt verteilen

Dieser Balanceakt gelingt nur auf Basis einer fundierten Strategie. Die Realität zeigt jedoch, dass lediglich 74 Prozent der DACH-Unternehmen digitale Souveränität in ihrer IT- und Sourcing-Strategie verankert, und nur 57 Prozent verfügen über konkrete Exit-Strategien für den Anbieterwechsel. Das zeigt eine aktuelle Studie von Lünendonk und Exxeta. 

Eine belastbare Migrationsstrategie beginnt daher mit der systematischen Bestandsaufnahme: Welche Workloads existieren, wie geschäftskritisch sind sie und welchen regulatorischen Vorgaben unterliegen sie? Erst auf dieser Grundlage lassen sich tragfähige Architekturentscheidungen treffen, denn Bauchgefühl ist in diesem Kontext kein geeigneter Maßstab.

Strukturierte Klassifizierung

Vier Dimensionen haben sich dabei als Klassifizierungsrahmen bewährt:

1. Daten: Enthält der Workload personenbezogene, vertrauliche oder geschäftsrelevante Informationen?
2. Regulierung: Unterliegt er spezifischen Aufsichtspflichten, etwa BaFin, KRITIS oder NIS2?
3. Abhängigkeitsrisiko: Wie stark bindet die Lösung an bestimmte Anbieter oder proprietäre Schnittstellen?
4. Latenz & Verfügbarkeit: Sind niedrige Latenz oder hohe Ausfallsicherheit geschäftskritisch?

Verteilung der Workloads

Auf Basis dieser Klassifizierung ergibt sich für die meisten Unternehmen eine hybride oder Multi-Cloud-Strategie mit klarer innerer Logik: Nichtkritische Workloads – etwa Analytics-, Test- und Entwicklungsumgebungen – profitieren vom Innovationstempo der Hyperscaler und werden dort betrieben, während kritische oder streng regulierte Anwendungen wie ERP-Systeme oder Produktionssteuerung in souveräne Cloud-Umgebungen oder dedizierte europäische Rechenzentren mit Compliance-by-Design gehören.

Für einzelne Legacy- oder Compliance-Systeme kann darüber hinaus der Verbleib On-Premises die richtige Entscheidung sein. Dabei gilt allerdings: On-Prem bedeutet nicht automatisch sicherer, denn ohne kontinuierliche Wartung entstehen rasch kritische Sicherheitslücken.

Schnelltest — Wohin gehört mein Workload? Beantworten Sie diese sechs Fragen mit „Ja“ oder „Nein“: Enthält der Workload personenbezogene Daten? Unterliegt er Aufsicht durch BaFin, BSI oder DORA? Führt Ausfall zu Umsatzverlust? Besteht US-Bezug beim Anbieter (z. B. durch CLOUD Act)? Muss er 24/7 verfügbar sein? Ist Latenz < 50 ms erforderlich? Auswertung: Je mehr „Ja“-Antworten, desto stärker die Tendenz zur souveränen oder hybriden Umgebung – bei 0–2 „Ja“ genügt i.d.R. der Hyperscaler, bei 3 + sollte ein Dualmodell geprüft werden.

Hybride und Multi-Cloud-Umgebungen sicher steuern

Mit der Klassifizierung ist die strategische Grundlage gelegt. Im nächsten Schritt gilt es, unterschiedliche Cloud-Welten so miteinander zu verbinden, dass Netzwerke, Identitäten und Sicherheitsprozesse konsistent bleiben – ohne die Komplexität unkontrolliert wachsen zu lassen.

Architektur: Netzwerk und Connectivity

Das Grundprinzip einer bewährten Zielarchitektur ist eine hybride Cloud mit zwei klar getrennten Zonen. Sensible und regulierte Workloads laufen dabei in stärker kontrollierten Bereichen mit engeren Zugriffsrechten, strengeren Sicherheitsvorgaben, zentralem Logging und klar definierten Change-Prozessen, während weniger kritische Workloads stärker auf Self-Service setzen können. Allerdings auch dort ausschließlich innerhalb definierter Leitplanken, etwa mit rollenbasierter Zugriffskontrolle, Budgetgrenzen, Policies und automatisiertem Abbau ungenutzter Ressourcen.

Verbunden werden die Zonen über dedizierte private Leitungen wie Azure ExpressRoute oder AWS Direct Connect und damit bewusst nicht über das öffentliche Internet. Zusammengehalten wird das Ganze durch eine gemeinsame Governance-Plattform mit einheitlichem Logging, Infrastructure-as-Code und zentralem Monitoring. Die Zielarchitektur ist in diesem Sinne keine Frage des Entweder-oder, sondern das Ergebnis einer gezielten Kombination verschiedener Umgebungen mit klar definierten Rollen und Verantwortlichkeiten für jede Zone.

Da klassische VPN-Lösungen in diesem Kontext zunehmend an ihre Grenzen stoßen, setzt sich stattdessen das Zero-Trust-Modell durch. Dabei wird jede Verbindung unabhängig vom Netzwerkstandort explizit authentifiziert. Technologien wie Split-Horizon-DNS ergänzen diesen Ansatz, indem sie eine kontextabhängige Namensauflösung ermöglichen und Zugriffe damit konsistent steuerbar machen.

Identität und Zugriff

Netzwerkarchitektur allein reicht jedoch nicht aus, denn in verteilten Cloud-Umgebungen ist die Identitätsebene ebenso entscheidend. Single Sign-on und Federation sind heute Pflicht, um Identitäten konsistent über mehrere Clouds hinweg zu verwalten. Als bewährte Best Practices haben sich dabei drei Prinzipien etabliert: Least Privilege über alle Plattformen hinweg, kurzlebige Tokens statt statischer Zugangsdaten sowie ein zentraler Identity Provider als Single Source of Truth. Gerade in Multi-Cloud-Umgebungen entscheidet ein sauberes Identity-Design darüber, ob Sicherheit beherrschbar bleibt oder zur Komplexitätsfalle wird.

Kontrolle behalten: Governance in verteilten Strukturen

Wie Unternehmen die Kontrolle über gewachsene, verteilte Cloud-Strukturen behalten, ist eine der zentralen Herausforderungen in der Praxis. Sie wird dadurch verschärft, dass viele Architekturen nicht das Ergebnis eines durchdachten Designs, sondern organisch entstanden sind. Das Resultat: mehrere Cloud-Umgebungen, unterschiedliche Betriebsmodelle und inkonsistente Governance-Ansätze nebeneinander.

Im Wesentlichen helfen dabei drei Hebel. Erstens: eine einheitliche Steuerungsebene, denn Control-Plane-Lösungen wie Azure Arc, Google Anthos oder AWS Systems Manager bündeln alle Cloud-Ressourcen unter einer zentralen Oberfläche und schaffen damit die notwendige Transparenz. Zweitens: konsequente Automatisierung durch Policy-as-Code und Infrastructure-as-Code, bei der Regeln und Infrastruktur als Code definiert, geprüft und versioniert werden. Was nicht den Vorgaben entspricht, wird gar nicht erst ausgerollt und der gesamte Prozess revisionssicher dokumentiert. Drittens: standardisierte Templates für die gesamte Infrastrukturbereitstellung, etwa mit Terraform, OpenTofu oder den nativen Lösungen der Hyperscaler, sodass Abweichungen vom Soll-Zustand kontinuierlich erkannt und automatisiert behoben werden.

Oft unterschätzt wird dabei die organisatorische Dimension: Klare Verantwortlichkeiten pro Cloud-Umgebung – beispielsweise eine dedizierte Cloud für Storage, eine andere für Identity Management – sind ebenso unverzichtbar wie die technischen Maßnahmen, denn erst ihr Zusammenspiel macht verteilte Strukturen langfristig beherrschbar.

Typische Stolpersteine

Falle 1: Migration ohne Strategie

Viele Projekte starten direkt mit der technischen Umsetzung im Lift-and-Shift-Verfahren, ohne die Anforderungen an Verfügbarkeit, Compliance, Performance oder Skalierbarkeit systematisch vorab zu prüfen. Das spart kurzfristig Zeit, führt jedoch langfristig zu schwer kontrollierbaren Strukturen mit redundanten Ressourcen und steigenden Betriebskosten. Häufig zeigt sich erst im laufenden Betrieb, dass Workloads in einer ungeeigneten Umgebung gelandet sind und aufwendig umgebaut werden müssen. Der richtige Ansatz lautet daher konsequent: erst klassifizieren, dann migrieren.

Falle 2: Fehlerhafte IAM-Integration

Inkonsistente Identitätssynchronisation zwischen zentralen Verzeichnisdiensten und Cloud-IAM-Systemen gehört zu den häufigsten Ursachen für Sicherheitslücken in hybriden und Multi-Cloud-Architekturen. Veraltete Berechtigungen oder Konten, die in einer Umgebung deaktiviert, in einer anderen jedoch weiterhin aktiv sind, erhöhen nicht nur das Risiko unautorisierter Zugriffe, sondern erschweren auch Audits und Compliance-Nachweise erheblich. Abhilfe schaffen robuste Token-Caches, redundante Identity Provider und kontinuierliches IAM-Monitoring – verstanden als integraler Betriebsbestandteil, nicht als nachgelagerte Verwaltungsfunktion.

Fazit

Cloud-Migration ist keine rein technische Entscheidung, sondern vor allem eine strategische. Wer Workloads ohne vorherige Klassifizierung verlagert, riskiert teure Nacharbeiten, Kontrollverlust und Compliance-Lücken, während Unternehmen, die strukturiert vorgehen – von der Workload-Analyse über eine durchdachte Zonenarchitektur und konsequente Automatisierung bis hin zu klarer Governance – weit mehr gewinnen als eine stabile IT-Landschaft: Sie sichern die digitale Souveränität ihres Unternehmens nachhaltig ab.

Die entscheidende Frage lautet deshalb nicht mehr: Sollen wir migrieren? Sondern: Wie migrieren wir so, dass wir die Kontrolle behalten – heute und in Zukunft?