Cloud-Migration für Banken: Der Finanzsektor braucht einen anderen Ansatz

Warum Cloud-Migration für Banken anders ist

Gartner prognostiziert, dass bis 2028 über 60 % aller Bankworkloads in der Public Cloud laufen werden — ein dramatischer Anstieg gegenüber heute (Gartner Research). Doch die Migrationsgeschwindigkeit im Bankensektor liegt deutlich unter der anderer Branchen. Der Grund: drei strukturelle Hemmnisse, die erst überwunden werden müssen.

Das erste Hemmnis ist die regulatorische Komplexität. Banken operieren unter einem dichten Netz von Anforderungen: KWG, MaRisk, BAIT (Bankaufsichtliche Anforderungen an die IT), DORA, GDPR, und für große Institute auch die EBA-Leitlinien zu Auslagerung und IKT-Risiken. Jede Auslagerung in die Cloud ist potenziell meldepflichtig.

Das zweite Hemmnis sind technische Altlasten. Kernbankensysteme (oft COBOL-basiert, IBM Mainframe) wurden in den 1980er und 1990er Jahren gebaut — lange bevor APIs, Microservices oder Cloud-Architekturen existierten. Die Entflechtung dieser Systeme erfordert Jahre sorgfältiger Planung.

Das dritte Hemmnis ist die Risikoaversion. Das Leitungsorgan einer Bank trägt persönliche Haftung für IT-Ausfälle, die Kunden oder den Markt schädigen. Diese Haftung schafft einen starken Anreiz, den Status quo beizubehalten.

Schritt 1: Regulatorische Vorbereitung und BaFin-Kommunikation

Bevor eine einzige Workload in die Cloud migriert wird, muss der regulatorische Rahmen stehen. Die relevanten Pflichten im deutschen Bankensektor:

Wesentliche Auslagerung (§ 25b KWG / AT 9 MaRisk)

Eine Auslagerung ist wesentlich, wenn sie Aktivitäten betrifft, die wesentlich für den Geschäftsbetrieb sind oder das Risikoprofil der Bank erheblich beeinflussen. Wesentliche Auslagerungen müssen der BaFin vorab angezeigt werden. Die Anzeige muss Angaben zum Anbieter, zur Art der Dienstleistung, zu Risiken und Kontrollmaßnahmen enthalten.

Auslagerungsregister

DORA Art. 28 verpflichtet Finanzinstitute zur Führung eines vollständigen Registers aller IKT-Drittanbieter-Vereinbarungen. Das Register muss unterscheiden zwischen Vereinbarungen für kritische/wichtige Funktionen und solchen für nicht-kritische Funktionen. AWS bietet hierfür Templates und Unterstützung durch den AWS Financial Services Competency Partner.

BAIT-Compliance für Cloud-Infrastruktur

Die Bankaufsichtlichen Anforderungen an die IT (BAIT) der BaFin regeln die IT-Governance, das IT-Risikomanagement und die Informationssicherheit für Kreditinstitute. Für Cloud-Umgebungen bedeutet das: ein dediziertes Cloud-Sicherheitskonzept, regelmäßige Penetrationstests und eine vollständige Inventarisierung aller Cloud-Ressourcen.

Schritt 2: Discovery und Datenklassifizierung

Vor der Migration steht das vollständige Inventory der zu migrierenden Workloads und ihrer Daten. Das ist im Bankensektor besonders aufwendig, weil historisch gewachsene Systeme selten vollständig dokumentiert sind.

AWS bietet hierfür zwei zentrale Werkzeuge:

• AWS Application Discovery Service: Scannt on-premises Infrastruktur, erkennt Server, Prozesse, Netzwerkverbindungen und Abhängigkeiten. Das Ergebnis ist ein vollständiges Dependency-Mapping — unverzichtbar für das Verständnis, welche Systeme zusammen migriert werden müssen.
• Amazon Macie: Scannt S3-Buckets und erkennt automatisch sensitive Daten (PII, Finanzdaten, Zugangsdaten). Für Banken besonders relevant: Macie kann IBAN-Nummern, Kreditkartendaten und andere bankspezifische Datenmuster erkennen.

Das Datenklassifizierungsschema für Banken sollte mindestens vier Stufen umfassen:

Schritt 3: Migrationsstrategie — Die 7 R im FSI-Kontext

Die klassische 7-R-Migrationsstrategie (Retire, Retain, Rehost, Relocate, Replatform, Refactor, Repurchase) gilt auch für den Bankensektor — aber mit fachspezifischen Modifikationen:

1. Retire (Stilllegen): Bankensysteme sind selten vollständig abschaltbar. Selbst scheinbar veraltete Systeme halten oft rechtlich relevante Daten aus abgeschlossenen Verträgen (Aufbewahrungspflicht: 10 Jahre). Digitale Archivierung in Amazon S3 Glacier Instant Retrieval mit Compliance-Lock ist die typische Alternative.
2. Retain (Behalten): Kernbankensysteme auf IBM z/OS oder AS/400 werden häufig vorerst retained. AWS Outposts oder VMware Cloud on AWS ermöglichen eine Hybridarchitektur, bei der moderne Cloud-Services die Altsysteme erweitern, ohne sie sofort ablösen zu müssen.
3. Rehost (Lift & Shift): Einfachste Migrationsoption für unkritische Windows- und Linux-Server. AWS Application Migration Service (MGN) repliziert Server automatisch in AWS und ermöglicht ein Cutover mit minimalem Downtime-Fenster.
4. Replatform: Datenbanken (Oracle, SQL Server) werden auf Amazon RDS oder Amazon Aurora umgestellt. Das AWS Schema Conversion Tool (SCT) und der AWS Database Migration Service (DMS) automatisieren Schema- und Datenmigration. Relevant für regulatorische Anforderungen: Multi-AZ-Deployments sichern hohe Verfügbarkeit.
5. Refactor/Re-Architect: Langfristig der wichtigste Schritt — monolithische Kernbankanwendungen werden in Microservices aufgebrochen. Im Bankensektor erfordert das eine enge Koordination mit dem Kernbankensystem-Hersteller und typischerweise einen mehrjährigen Horizont.
6. Repurchase: Wechsel von Self-hosted zu SaaS (z. B. Salesforce für CRM, Workday für HR). Im Bankensektor durch strenge Datenlokalitätsanforderungen eingeschränkt — europäische SaaS-Anbieter bevorzugt.
7. Relocate: VMware-basierte Workloads können nahtlos über VMware Cloud on AWS in die Cloud verschoben werden — ohne Rekonfiguration, ohne neue Betriebsmodelle.

Audit-Trails: Zehnjährige Nachvollziehbarkeit auf AWS

Banken müssen Transaktionen und Systemzugriffe über lange Zeiträume nachvollziehbar halten. Die Anforderungen variieren: Kreditakten 10 Jahre, Zahlungsverkehrsdaten 5 Jahre, Wertpapiertransaktionen 7 Jahre (MiFID II). Auf AWS gibt es dafür einen abgestuften Ansatz:

AWS CloudTrail mit S3 Object Lock

CloudTrail protokolliert alle API-Aufrufe in AWS unveränderlich. In Kombination mit S3 Object Lock (Compliance Mode) können diese Logs für die vorgeschriebene Aufbewahrungsdauer gesperrt werden — kein Administrator kann sie löschen oder modifizieren. Das erfüllt die Anforderungen der MaRisk AT 7.2 an die Integrität von Protokolldaten.

Amazon CloudWatch Logs

Anwendungs- und Systemlogs werden in CloudWatch Logs aggregiert. Log Groups können mit unveränderlichen Retention Policies und KMS-Verschlüsselung konfiguriert werden. Für bankspezifische Anforderungen: Log-Daten können automatisch in S3 Glacier für Langzeitarchivierung verlagert werden.

Amazon Security Lake

Zentralisiert Security-Logs aus AWS-Services und Drittquellen in einem standardisierten Format (OCSF — Open Cybersecurity Schema Framework). Ermöglicht effiziente Suche und Analyse über lange Zeiträume — relevant für Forensik nach Sicherheitsvorfällen und für regulatorische Anfragen.

AWS MAP für den Finanzsektor

Das AWS Migration Acceleration Program (MAP) ist das strukturierte Migrationsprogramm von AWS, das speziell für komplexe Enterprise-Migrationen entwickelt wurde. Für den Finanzsektor bietet MAP folgende Leistungen:

MAP enthält auch finanzielle Unterstützung: Migration Credits reduzieren die AWS-Kosten während der Migrationsphase. Für große Bankenmigrationsprojekte können diese Credits erheblich sein. Als AWS Premier Partner mit Migration Competency führt Storm Reply MAP-Projekte im Finanzsektor durch und koordiniert die Beantragung der Credits.

Die Finanzielle Realität: TCO-Vergleich on-premises vs. AWS

Der häufigste Einwand gegen Cloud-Migration im Bankensektor ist das Kostenargument: „Wir haben die Hardware bereits abgeschrieben — warum sollten wir für etwas zahlen, das wir bereits besitzen?" Dieses Argument übersieht mehrere Kostenfaktoren:

• Versteckte Betriebskosten: Energie, Kühlung, Raummiete für Rechenzentren, Personalkosten für Systemadministratoren und Security-Teams. Gartner schätzt, dass die wahren Betriebskosten von on-premises Infrastruktur häufig um 40–60 % unterschätzt werden.
• Compliance-Kosten: BSI-Grundschutz-Zertifizierungen, Penetrationstests, Schwachstellenmanagement — all das muss on-premises eigenverantwortlich und damit kostenpflichtig durchgeführt werden. Auf AWS sind viele dieser Compliance-Leistungen im Service-Preis enthalten oder werden durch vorgefertigte Compliance-Tools erheblich günstiger.
• Innovations-Gap-Kosten: Banken, die nicht in die Cloud migrieren, haben keinen Zugang zu AWS-KI-Services (Amazon Bedrock, SageMaker), Echtzeit-Datenverarbeitung (Kinesis) oder globalem CDN. Der Wettbewerbsnachteil gegenüber Cloud-nativen Neobanken ist schwer quantifizierbar, aber real.

Häufig gestellte Fragen zur Cloud-Migration im Bankensektor

Muss eine Bank die BaFin vor der Cloud-Migration informieren?

Ja. Nach § 25b KWG und MaRisk AT 9 müssen wesentliche Auslagerungen — dazu zählt Cloud-Hosting kritischer Anwendungen — der BaFin angezeigt werden. Seit DORA gelten zusätzlich die Anforderungen aus Art. 28 DORA für IKT-Drittanbieter-Verträge.

Was ist das AWS Migration Acceleration Program (MAP) für den Finanzsektor?

MAP ist ein strukturiertes Migrationsprogramm mit drei Phasen (Assess, Mobilize, Migrate/Modernize), FSI-spezifischen Playbooks und finanziellen Migration Credits. AWS Premier Partner wie Storm Reply führen MAP-Projekte durch und koordinieren die Beantragung der Credits.

Wie wird Datenklassifizierung bei der Bank-Cloud-Migration umgesetzt?

Banken implementieren ein mindestens vierstufiges Klassifizierungsschema (öffentlich, intern, vertraulich, streng vertraulich). Amazon Macie erkennt sensitive Daten in S3 automatisch. AWS Config Rules stellen sicher, dass Daten nicht in ungesicherte Speicher gelangen.

Wie lange dauert ein typisches Cloud-Migrationsprojekt für eine mittelgroße Bank?

Typischerweise 18–36 Monate für eine vollständige Migration nicht-kritischer Workloads. Kernbankensysteme erfordern oft einen längeren Horizont (3–7 Jahre) mit parallelen Modernisierungsschritten. Storm Reply empfiehlt einen iterativen Ansatz: erste Erfolge innerhalb von 6 Monaten, dann schrittweise Expansion.