Sebastien Rousseau
Kontakt ›

Cloud Native Banking in 2026: Kubernetes, DORA, Sovereignty, and the End of the VM vs Container Divide

Cloud native for banks has matured from container adoption to regulated platform engineering: Kubernetes, VM coexistence, data portability, DORA supervision, cloud dependency reviews, and operational resilience now define the architecture.

6 Min. Lesezeit

Cloud-natives Banking 2026: Kubernetes, DORA, Souveränität und das Ende der Trennung zwischen VM und Container

Cloud-natives Banking ist 2026 keine Grundsatzdebatte mehr darüber, ob Banken Cloud nutzen dürfen. Es handelt sich um eine regulierte Disziplin des Platform Engineering: kritische Dienste über Container, virtuelle Maschinen (VM), Data Fabrics, AI/ML-Workloads und Cloud-Anbieter hinweg zu betreiben und gleichzeitig den Nachweis operativer Resilienz nach DORA (Digital Operational Resilience Act) und vergleichbaren Regimen zu erbringen. IBM bezeichnet 2026 als den ersten echten aufsichtlichen Belastungstest von DORA, mit Prüfungen der Cloud-Abhängigkeiten, Cybersicherheitsinspektionen, bedrohungsgeführten Penetrationstests und direkter Beaufsichtigung kritischer Drittanbieter (IBM).

Executive Summary / Kernaussagen

  • DORA hat die Cloud-Debatte verändert. 2026 bringt direkte EU-Beaufsichtigung kritischer Drittanbieter sowie gezielte Prüfungen der Abhängigkeiten von Cloud-Service-Anbietern bei Banken (IBM).
  • Kubernetes ist die Plattformebene, nicht die vollständige Antwort. Banken benötigen Kubernetes für Elastizität, Automatisierung und AI/ML-Workloads, brauchen aber zugleich die Koexistenz mit VMs, weil Kernbankensysteme, Zahlungsverkehr, Handel und Risikoanwendungen weiterhin auf gehärteten virtualisierten Beständen laufen (Red Hat).
  • Die Trennung zwischen VM und Container schließt sich. Red Hat positioniert OpenShift und Portworx als einheitliches Modell, in dem VMs und Container gemeinsame Richtlinien, Daten, Backup, Disaster Recovery und Governance-Kontrollen teilen (Red Hat).
  • Cloud-Souveränität ist heute eine Designvorgabe. Banken nutzen Souveränität, um jurisdiktionelle Kontrolle, operative Autonomie, Schlüsselkontrolle, Datenstandort und Cloud-Konzentrationsrisiken zu steuern (Red Hat).
  • KI hat Cloud-native dringlich gemacht. Betrugserkennung, Liquiditätsanalytik, Echtzeit-Personalisierung und regulatorisches Reporting verlangen zunehmend elastische Rechenleistung in der Nähe sensibler Daten (Red Hat).
  • Eine Exit-Strategie ist kein PDF. Nach den heutigen aufsichtlichen Erwartungen brauchen Banken erprobte Portabilität, Abhängigkeitskartierung, vertragliche Nachweise, Wiederherstellungsverfahren und realistische Migrationspfade für kritische Funktionen.
  • Das Architekturziel ist kontrolliertes Cloud-native. Die erfolgreiche Bankplattform stellt Entwicklerinnen und Entwicklern Self-Service-Auslieferung bereit und setzt gleichzeitig Audit, Verschlüsselung, Datenresidenz, Resilienztests, Funktionstrennung und Drittanbieter-Risikokontrollen automatisch durch.

Warum 2026 das Jahr der Cloud-nativen Aufsicht ist #

DORA gilt seit Januar 2025, doch erst 2026 wird die aufsichtliche Schlagkraft sichtbar. IBM weist darauf hin, dass die erste Liste kritischer Drittanbieter im November 2025 benannt wurde und 2026 die direkte Zusammenarbeit mit den europäischen Aufsichtsbehörden, Vertragsprüfungen, Vor-Ort-Inspektionen und Analysen der Cloud-Abhängigkeiten bringt (IBM).

Damit verschiebt sich die Beweislast. Eine Bank kann einen Cloud-Ausfall nicht mehr als bloßes Anbieterproblem darstellen. Das Finanzinstitut bleibt für die Resilienz kritischer Funktionen verantwortlich, auch wenn diese Funktionen von Hyperscalern, SaaS-Anbietern (Software as a Service), Datenplattformen und Managed-Security-Diensten abhängen.

Die Cloud-native Banking-Baseline 2026 #

1. Kubernetes als Betriebsschicht #

Kubernetes liefert Banken Bereitstellungsautomatisierung, Elastizität, Richtliniendurchsetzung, Container-Orchestrierung und eine einheitliche Abstraktion über Private Cloud, Public Cloud und souveräne Umgebungen hinweg. Für neue Workloads – insbesondere KI-gestützte Betrugserkennung, Echtzeit-Personalisierung, Liquiditätsanalytik und regulatorisches Reporting – ist dies zur natürlichen Steuerungsebene geworden (Red Hat).

Der Fehler liegt darin, Kubernetes als Endziel zu betrachten. Für Banken ist es das Substrat unterhalb einer governance-gesteuerten Entwicklerplattform.

2. Konvergenz von VM und Container #

Die meisten Banken können ihren Kernbestand nicht kurzfristig neu schreiben. Zahlungsverkehrs-Engines, Handelssysteme, Kredit-Scoring, Risikomodelle und Kernbankenplattformen hängen weiterhin von gehärteten VM-Beständen ab. Red Hat argumentiert, Banken benötigten eine einheitliche Plattform, auf der VMs und Container gemeinsam betrieben werden können, um Architekturduplikate abzubauen und Richtlinien, Speicher, Backup und Recovery-Kontrollen zu harmonisieren (Red Hat).

Dies ist die praktische Brücke zwischen Legacy-Resilienz und Cloud-nativer Geschwindigkeit. Sie erlaubt Banken, angrenzende Dienste zuerst zu migrieren, datenabhängige KI-Workloads in Datennähe zu platzieren und brüchige Neuentwicklungen kritischer Systeme zu vermeiden.

3. DORA-fähige operative Resilienz #

IBM nennt als aufsichtliche Schwerpunkte für 2026 unter anderem die Nachverfolgung von Defiziten bei ICT-Sicherheit (Information and Communication Technology) und Auslagerungen, Vor-Ort-Inspektionen zu Cybersicherheit und Drittanbieter-Risiken, bedrohungsgeführte Penetrationstests, Überprüfungen des ICT-Änderungsmanagements und Analysen der Cloud-Abhängigkeiten (IBM).

Das bedeutet: Resilienz muss prüfbar sein. Architekturdiagramme genügen nicht. Banken benötigen Nachweise aus Failover-Übungen, Vorfallssimulationen, Backup-Wiederherstellungen, Abhängigkeitskarten, Tests der Wiederanlaufzeiten und Governance-Workflows.

4. Souveränität als Plattformfähigkeit #

Cloud-Souveränität ist mehr als Datenresidenz. Sie umfasst rechtliche Kontrolle, operative Kontrolle, Kontrolle der Verschlüsselungsschlüssel, Jurisdiktion des Supportpersonals, Workload-Platzierung und die Fähigkeit, kritische Dienste fortzuführen, wenn ein globaler Anbieter oder ein geopolitischer Prozess Störungen verursacht. Red Hat fasst Souveränität als jurisdiktionelle Kontrolle und operative Autonomie für Banken auf, die mit divergierenden Regulierungen wie GDPR (General Data Protection Regulation), DORA und nationalen Cloud-Regeln konfrontiert sind (Red Hat).

Die Cloud-native Konsequenz: Workload-Routing, Secrets-Management, Schlüsselkontrolle, Datenklassifikation und Richtliniendurchsetzung müssen programmierbar sein.

Der Bank-Plattform-Stack #

Developer-Experience-Schicht #

Eine bankentaugliche Cloud-native Plattform sollte „paved roads" bereitstellen: Golden Paths, Templates, Service-Kataloge, automatisierte Deployment-Pipelines, Observability-Defaults, Policy-as-Code, eine standardisierte Secrets-Integration und freigegebene Datenpfade. Entwicklerinnen und Entwickler sollten nicht für jede Freigabe mit jedem Kontrolleigner verhandeln müssen.

Die Plattform muss den regelkonformen Pfad zum schnellsten Pfad machen. Nur dieses Modell skaliert über tausende Services hinweg.

Kontrollschicht #

Die Kontrollschicht umfasst Identität, Zugriffsverwaltung, Funktionstrennung, Verschlüsselung, Schlüsselverwahrung, Netzwerkrichtlinien, Image-Signierung, Software Bill of Materials, Schwachstellen-Gates, Runtime-Security, Logging und Nachweiserzeugung. Hier werden DORA, NIS2 (Network and Information Security Directive 2), GDPR, Auslagerungsregeln und interne Modellrisikorichtlinien zu ausführbaren Kontrollen.

An dieser Stelle scheitern viele Banken. Sie führen Container ein, lassen Kontrollen aber als manuelle Freigaben außerhalb der Plattform stehen.

Datenschicht #

Stateful Workloads sind der schwierigste Teil von Cloud-nativem Banking. Das Argument von Red Hat zur VM-/Container-Konvergenz beruht maßgeblich auf einer einheitlichen Data Fabric sowie auf richtliniengesteuertem Backup, Replikation, Failover und Recovery über VMs und Container hinweg (Red Hat).

Für Banken muss die Datenschicht drei Fragen beantworten: Wo liegen die Daten, wer kontrolliert die Schlüssel und wie erholt sich der Dienst, wenn die Infrastruktur ausfällt?

Architekturtabelle: Cloud-native für Banken #

Fähigkeit Cloud-natives Muster Bankaufsichtliche Kontrollanforderung Fehlermodus
Anwendungs-Auslieferung Kubernetes, GitOps, Templates Funktionstrennung, Änderungsnachweis, Rollback Schnelle, aber nicht auditierbare Releases
Legacy-Koexistenz Einheitliche VM-/Container-Plattform Konsistente Richtlinien und Migrationskontrolle Doppelte Bestände mit dupliziertem Risiko
Datendienste Stateful Operatoren und Data Fabric Residenz, Backup, Unveränderlichkeit, getestete Wiederherstellung Zustandslose Plattform mit zustandsbehafteter Fragilität
Resilienz Multi-Zone, Multi-Region, Failover DORA-Nachweise und Kartierung kritischer Funktionen Cloud-Ausfall als Anbieter-Ausrede
Souveränität Richtlinienbasierte Workload-Platzierung Nachweise zu Jurisdiktion und Schlüsselkontrolle Residenz ohne operative Autonomie
KI-Workloads Elastische Rechenleistung in Datennähe Modell-Governance, Datenminimierung, Audit Sensible Daten in nicht freigegebenen KI-Diensten

Was dies je Institutstyp bedeutet #

Tier-1-Universalbanken #

Tier-1-Banken sollten kontrollierte interne Plattformen über mehrere Clouds hinweg aufbauen, mit strikter Policy-as-Code, Datenklassifikation und Workload-Platzierung. Sie verfügen über genügend Skalierung, um Platform Engineering zu rechtfertigen, und Aufseher werden von ihnen tiefere Nachweise verlangen.

Mittelständische Banken #

Banken im mittleren Segment sollten standardisieren statt anpassen. Eine starke verwaltete Kubernetes-Plattform, eine disziplinierte Auswahl der Cloud-Anbieter, klare Exit-Strategien und automatisierte Nachweiserzeugung sind wertvoller als eine ausufernde Multi-Cloud-Ambition, die das Institut nicht betreiben kann.

Finanzmarktinfrastrukturen #

FMIs (Financial Market Infrastructures) brauchen vor allem den Nachweis von Resilienz. Sie sollten Cloud-native als Mittel zur Verbesserung von Wiederherstellung, Observability und kontrollierter Veränderung verstehen, nicht als reines Geschwindigkeitsspiel.

Fintechs und PSPs #

Fintechs und PSPs (Payment Service Provider) können sich rasch bewegen, dürfen aber ihr Kontrollmodell nicht überwachsen. Sobald sie systemrelevant werden, treffen sie dieselben Anforderungen an Resilienz, Drittanbieter-Risiko, Vorfallsmeldung und Datensouveränität.

Fazit #

Cloud-natives Banking ist 2026 eine Governance-Architektur. Kubernetes ist unverzichtbar, aber nicht hinreichend. Erfolgreich werden die Institute sein, die VMs und Container dort konvergieren lassen, wo es nötig ist, Cloud-native Muster für neue Workloads nutzen, Resilienz unter DORA nachweisen, Datensouveränität auf der Plattformebene steuern und Compliance so weit automatisieren, dass Entwicklerteams zügig liefern können, ohne ungesteuertes Risiko zu erzeugen.

Die alte Debatte war, ob Banken in die Cloud wechseln können. Die neue Debatte ist, ob Banken Cloud-native ausreichend sicher, ausreichend portabel und ausreichend belegbar betreiben können, um die Dienste zu führen, auf die es ankommt.

Häufig gestellte Fragen #

Verbietet DORA Banken die Nutzung von Cloud?

Nein. DORA untersagt die Cloud-Nutzung nicht. Es macht Finanzinstitute verantwortlich für ICT-Risiko, Drittanbieter-Abhängigkeiten, Vorfallsmeldungen, Resilienztests und die Governance kritischer Dienste, die auf Cloud- und andere ICT-Anbieter angewiesen sind (IBM).

Warum brauchen Banken noch VMs, wenn Kubernetes die Zukunft ist?

Banken betreiben weiterhin kritische Systeme auf VM-basierten Beständen, darunter Zahlungsverkehrs-Engines, Kernbankensysteme, Handelsanwendungen und Risikoplattformen. Ein einheitliches VM-/Container-Modell verringert Duplikation und erlaubt gleichzeitig eine schrittweise Migration (Red Hat).

Was ist eine tatsächliche Cloud-Exit-Strategie?

Eine echte Exit-Strategie umfasst ein Abhängigkeitsinventar, Datenexportverfahren, alternative Laufzeitoptionen, vertragliche Rechte, Wiederherstellungstests, Pläne zur Schlüsselkontrolle und einen realistischen Zeitplan für die Verlagerung oder Wiederherstellung kritischer Dienste.

Was ist der größte Cloud-native Fehler von Banken?

Der größte Fehler ist die Einführung von Containern ohne Plattformkontrollen. Wenn Kubernetes die Deployment-Geschwindigkeit erhöht, ohne Identität, Richtlinien, Audit, Datenresidenz, Wiederherstellung und Schwachstellenkontrollen durchzusetzen, beschleunigt es das Risiko, statt es zu mindern.

Quellen #

Zuletzt überprüft .

Zuletzt überprüft .