Wissensraum · Deep Dive 15 von 27
Warum Architektur entscheidend ist – nicht das Provider-Versprechen
Was dieser Deep Dive Ihnen zeigt
Warum Cloud-Resilienz unter DORA mehr verlangt als Verfügbarkeits-SLAs – und welche Anforderungen an Exit-Strategien, Auditierbarkeit und Drittanbieter-Steuerung bestehen.
Cloud-Infrastrukturen werden häufig mit hoher Verfügbarkeit gleichgesetzt. DORA stellt jedoch klar: Die Nutzung von Cloud-Services garantiert keine automatische Resilienz.
Cloud kann ein wirksamer Baustein operativer Resilienz sein – sofern die zugrunde liegende Architektur entsprechend gestaltet ist. Die Verantwortung für Verfügbarkeit, Wiederanlauf und Steuerbarkeit verbleibt stets beim auslagernden Unternehmen, nicht beim Cloud-Provider.
Betrieb in einer einzigen Zone oder Region
Zentrale Abhängigkeiten
Backups in derselben Zone oder Region
Einordnung
Fällt die Zone oder Region aus, sind Systeme und Daten gleichzeitig betroffen.
Nutzung mehrerer Availability Zones
Redundante Komponenten
Erste belastbare Resilienzschicht
Einordnung
Schützt vor lokalen Störungen, nicht jedoch vor regionalen oder systemischen Ausfällen.
Ausfallsicherheit über Regionen hinweg
Getrennte Kontroll- und Wiederanlaufpfade
Dezentral gespeicherte Backups
Klare Trennung kritischer Funktionen
Hinweis DORA schreibt keine Multi-Cloud-Architektur vor. Unternehmen müssen jedoch nachvollziehbar begründen, warum ihre gewählte Architektur für das jeweilige Risikoprofil ausreichend ist.
Transparenz über technische Abhängigkeiten
Dokumentierte und realistische Recovery-Strategien
Regelmäßig getestete Failover-Mechanismen
Exit- und Substitutionsstrategien zur Reduktion von Provider-Abhängigkeiten
Gesicherte Datenportabilität
Transparenz über Subdienstleister des Cloud-Providers
Einbindung der Cloud-Architektur in Governance- und Risikosteuerung
Backups in derselben Zone oder Region („verdeckte Single Points of Failure“)
Failover-Mechanismen, die nie realistisch getestet wurden
Unzureichend segmentierte IAM-Strukturen in Cloud-Umgebungen
Fehlende Exit- oder Fallback-Konzepte bei Provider-Ausfällen
Mangelnde Überwachung kritischer Zonen und Komponenten
Nicht dokumentierte Abhängigkeiten zwischen Microservices
Ausgangslage
Ein FinTech betreibt seine Systeme vollständig auf einer Public-Cloud-Plattform. Zwei Availability Zones und automatisiertes Failover vermitteln den Eindruck hoher Resilienz.
Was passiert
Eine regionale Störung führt dazu, dass beide Zonen gleichzeitig beeinträchtigt sind, das automatische Failover nicht greift und Datenbank-Replikate inkonsistent werden.
Die Analyse zeigt
Backups liegen ebenfalls in derselben Region
Keine dokumentierte manuelle Recovery-Prozedur vorhanden
Ein Cold-Standby in einer anderen Region wurde nie eingerichtet
Konsequenzen
Mehrstündiger Systemausfall
Potenziell meldepflichtiger Incident
Anforderung einer detaillierten Architekturübersicht durch die Aufsicht
Erhebliche Reputationsschäden
Praxis-Impuls
Cloud-Resilienz entsteht nicht durch Vertragszusagen oder Marketing-Versprechen. Stellen Sie die Frage: Haben wir unseren Cloud-Failover je unter realen Bedingungen getestet – nicht simuliert, sondern tatsächlich durchgeführt? Unter DORA gilt: Resilienz ist gestaltet – nicht ausgelagert.
Was bleibt
Cloud-Resilienz ist nicht Verfügbarkeit, sondern Kontinuität. Unter DORA gilt: Ihr Geschäft muss weiterlaufen, wenn der Cloud-Provider ausfällt. Das bedeutet: dezentralisierte Architektur, Backup-Pfade, nachweisbare Recovery-Szenarien – nicht nur SLA-Versprechen.
Exit-Fähigkeit ist ein Architektur-Problem. Wenn Sie heute aus der Cloud aussteigen müssten, wie lange würde es dauern? Wie viele Daten sind im proprietären Format gebunden? Unter DORA müssen Sie das vorausdenken, nicht nachdenken.
Drittanbieter-Abhängigkeiten sind Ihre Abhängigkeiten. Der Cloud-Provider ist nicht extern – für Ihre Risikobewertung ist er Teil Ihrer kritischen Infrastruktur. DORA verlangt: dokumentieren, bewerten, monitoren, kontrollieren, testen – regelmäßig.
Auditierbarkeit ist eine Vertragsminimalanforderung. Generische Datenschutzerklärungen genügen nicht mehr. Sie müssen nachweisen können: Wer hatte Zugriff, wann, von wo, mit welchen Berechtigungen – und der Provider muss das überprüfbar machen.