- Funktionen
- Pricing

Diese Seite wurde von unseren Experten auf Englisch verfasst und mithilfe einer KI übersetzt, um einen schnellen Zugriff zu ermöglichen! Die Originalversion findest du hier.
Finanzinstitute müssen nachweisen, dass sie sicher in der Cloud arbeiten können, ohne von einem einzigen Technologieanbieter abhängig zu sein. Was passiert, wenn dein Cloud-Anbieter ausfällt oder du umziehen musst?
Früher war das eine theoretische Frage. Seit Januar 2025 ist es jedoch eine gesetzliche Anforderung.
Der Digital Operational Resilience Act (DORA) der EU verlangt von Banken, Versicherungen und Wertpapierfirmen, dass sie nachweisen, dass sie Störungen der cloud-Plattformen, auf die sie angewiesen sind, standhalten können, einschließlich der Aufrechterhaltung einer dokumentierten, getesteten Ausstiegsstrategie für jeden Technologieanbieter.
Für viele Unternehmen offenbart dies eine harte Wahrheit: Die meisten modernen cloud-basierten Implementierungen sind eng an einen einzigen Anbieter gebunden.
Wenn eine Aufsichtsbehörde fragt, wie du morgen von AWS wegkommen würdest, ist „das würden wir schon irgendwie hinbekommen“ keine akzeptable Antwort mehr.
Die meisten cloud-basierten Architekturen sind nicht portabel. Sie basieren auf anbieterspezifischen Diensten: AWS-Lambda-Funktionen, Azure-nativen Datenbanken und GCP-spezifischen Netzwerkkonfigurationen, wodurch tiefe, unsichtbare Abhängigkeiten entstehen. Mit der Zeit häufen sich diese Abhängigkeiten an.
Der Wechsel von einem einzelnen cloud-basierten Anbieter bedeutet nicht nur, ein Hosting-Konto zu wechseln. Es bedeutet, deine Anwendung neu zu gestalten.
Für eine regulierte Bank ist das riskant. Wenn eine Bank ihre Workloads nicht von einem Anbieter weg verlagern kann, kann sie keine Ausfallsicherheit gegenüber Ausfällen, regulatorischen Maßnahmen oder geopolitischen Störungen nachweisen.
Dies ist das Konzentrationsrisiko, für dessen Bewältigung DORA konzipiert wurde.
Im November 2025 stuften die EU-Aufsichtsbehörden 19 IKT-Anbieter im Rahmen von DORA als kritisch ein, darunter AWS, Microsoft Azure und Google Cloud. Diese Anbieter unterliegen nun einer direkten Aufsicht auf EU-Ebene.
Für Finanzunternehmen, die von ihnen abhängig sind, ist die Botschaft klar: Beweist, dass ihr nicht in der Falle sitzt.
Gemäß Artikel 28 der DORA müssen Finanzinstitute in der Lage sein, Verträge mit IKT-Anbietern zu kündigen, ohne dass es zu Dienstunterbrechungen kommt oder regulatorische Anforderungen verletzt werden. Das bedeutet, dass Institute:
Wenn Teams den Begriff „Ausstiegsstrategie“ hören, ist der erste Impuls oft, eine Multi-Cloud-Laufzeitumgebung einzuführen: Anwendungen gleichzeitig bei mehreren Anbietern ausführen.
In der Praxis ist dieser Ansatz teuer und komplex.
Die Ausführung von Produktions-Workloads über mehrere clouds hinweg erfordert doppelte Infrastruktur, doppelte Überwachung und doppelte Betriebsteams. Schlimmer noch: Die Anwendung selbst ist möglicherweise weiterhin von anbieterspezifischen Diensten abhängig. Echte Portabilität bleibt unerreichbar.
Was Finanzinstitute wirklich brauchen, ist standardisierte Portabilität: ein Bereitstellungsmodell, bei dem Anwendungen bei einem anderen Infrastrukturanbieter neu erstellt werden können, ohne das gesamte System neu zu entwerfen.
Upsun geht dieses Problem anders an.
Anstatt Anwendungen um einen bestimmten cloud-Anbieter herum zu entwickeln, standardisiert Upsun die Art und Weise, wie Anwendungen definiert und bereitgestellt werden. Die Grundlage dieses Ansatzes ist eine einzige Konfigurationsdatei: .upsun/config.yaml.
Diese Konfiguration definiert die gesamte Anwendungsumgebung:
Deine Infrastrukturdefinition ist nicht in einer cloud-basierten Konsole oder einer proprietären Orchestrierungsschicht eingeschlossen. Sie ist versioniert, überprüfbar und portabel.
Da die Konfiguration anbieterunabhängig ist, kann die Anwendungsumgebung auf jeder unterstützten Infrastruktur – einschließlich AWS, Azure, Google Cloud, IBM und OVHCloud – neu erstellt werden, ohne das Bereitstellungsmodell neu zu entwerfen.
Sollte eine Aufsichtsbehörde einen Wechsel verlangen oder ein Anbieter einen längeren Ausfall haben, kann die Anwendung unter Verwendung derselben Upsun-Konfiguration und des Git-basierten Workflows wiederhergestellt oder zu einem anderen unterstützten Anbieter migriert werden.
Artikel 28 der DORA verpflichtet Finanzunternehmen zur Aufrechterhaltung umsetzbarer Ausstiegsstrategien, während Artikel 30 spezifische Vertragsbestimmungen festlegt, die in Vereinbarungen mit IKT-Anbietern enthalten sein müssen und die Dienstkontinuität, Kündigungsrechte und Datenmigration abdecken.
Upsun bietet bereits einen DORA-Vertragsnachtrag an, um Finanzdienstleistungskunden bei der Erfüllung dieser Anforderungen zu unterstützen.
Aber die technische Seite ist genauso wichtig wie die vertragliche. DORA erwartet umsetzbare Ausstiegspläne, keine theoretischen.
Eine portable, versionskontrollierte Infrastrukturdefinition gibt Compliance-Teams etwas Konkretes an die Hand: Hier ist der Entwurf.
In Kombination mit den bestehenden Compliance-Zertifizierungen von Upsun – ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und der Validierung für IBM Cloud for Financial Services – ist Upsun darauf ausgelegt, Teams zu unterstützen, die in regulierten Umgebungen arbeiten.
Eine ehrliche Ausstiegsstrategie erfordert mehr als eine portable Konfigurationsdatei.
Der Wechsel einer Produktionsanwendung zwischen Cloud-Anbietern erfordert nach wie vor einen geplanten Migrationsprozess: Datenübertragung, erneute Integrationstests, DNS-Umstellung, performance-Validierung und Freigabe durch die Stakeholder.
Keine Plattform macht diesen Aufwand komplett überflüssig.
Was Upsun überflüssig macht, ist die Neugestaltung der Infrastruktur.
Dein Programm ändert sich nicht. Deine Build-Pipeline ändert sich nicht. Deine Service-Definitionen ändern sich nicht.
Der Migrationsaufwand konzentriert sich auf die operativen Schritte: Daten, Tests und Umstellung, nicht darauf, alles von Grund auf neu aufzubauen. Das ist eine grundlegend andere Ausgangsposition als die Umstellung von einer anbieterspezifischen Architektur.
Wenn du ein Finanzinstitut bist, das sich auf die Anforderungen der DORA-Exit-Strategie vorbereitet, fang hier an:
Bei Upsun beginnt die Antwort mit einer Datei, die sich bereits in deinem Git-Repository befindet.