Auf eine zentralisierte Cloud-Infrastruktur zu setzen, erhöht das Ausfallrisiko digitaler Geschäftsprozesse. Je stärker Anwendungen, Daten und Betriebsmodelle bei einem einzelnen Hyperscaler konzentriert sind, desto größer ist die Wirkung einzelner Störungen auf zentrale digitale Geschäftsprozesse.

Mehrere Ausfälle großer Cloud-Anbieter im Jahr 2025 haben diese Abhängigkeit deutlich gemacht. Sie betreffen genau das Szenario, für das Business-Continuity-Konzepte gedacht sind: den Ausfall zentraler IT-Services. Diese Konzepte greifen jedoch meist nur innerhalb der Plattform, nicht bei einem Ausfall der Plattform selbst.

Datenintensive Workloads als Realitätstest

Datenmengen wachsen heute im Normalbetrieb. Anwendungen laufen dauerhaft, erzeugen kontinuierlich neue Daten, Logs, Versionen und Replikate. Hinzu kommen Backups, Analysen und zunehmend auch KI-Workloads. Cloud-Infrastrukturen stehen dadurch permanent unter Last. Ausfälle treffen Systeme dadurch nicht mehr im Leerlauf, sondern während laufender Datenverarbeitung. Das erschwert den Wiederanlauf, weil Daten- und Systemzustände nicht abgeschlossen sind und zunächst abgeglichen werden müssen. Ein Prozess, der Zeit kostet und den Betrieb verzögert.

Dauerlast erfordert Cloud-Modelle, bei denen Datenzugriffe und Replikation auch bei hohem Volumen stabil bleiben. Datenhaltung und Metadatenverarbeitung müssen so organisiert sein, dass sie nicht an einzelne Steuerungs- oder Kontrollkomponenten gebunden sind. Auf diese Weise bleibt der Betrieb auch bei weiterem Wachstum berechenbar und Business Continuity ist im laufenden Betrieb verankert.

Portabilität als Voraussetzung für belastbare RTO und RPO

RTO und RPO legen fest, wie schnell Systeme nach einem Ausfall wieder verfügbar sein müssen und wie aktuell die dabei nutzbaren Daten sein sollen. In vielen Cloud-Umgebungen hängen Betrieb, Zugriff und Sicherheit von anbietergebundenen Komponenten wie Identitätsdiensten, Schlüsselverwaltung und Automatisierung ab. Fällt diese Umgebung aus, können Anwendungen nicht unmittelbar an anderer Stelle weiterlaufen. Wiederanlaufzeiten verlängern sich, weil Abhängigkeiten zuerst technisch aufgelöst und Betriebsfunktionen neu bereitgestellt werden müssen. Architekturen, die Datenzugriff und Betrieb auf allgemein nutzbaren Schnittstellen aufbauen und diese Abhängigkeiten vermeiden, ermöglichen einen echten Wiederanlauf. RTO und RPO bleiben dadurch kontrollierbar, weil Verfügbarkeit nicht an ein einzelnes Cloud-Ökosystem gebunden ist.

Verteilte Infrastruktur statt gebündelter Abhängigkeiten

Bei Hyperscalern werden Daten und Workloads in der Regel innerhalb klar definierter Regionen betrieben. Auch wenn mehrere Zonen existieren, bleibt der Betrieb häufig an regionale oder übergreifende Steuerungsebenen gebunden. Für Business Continuity bedeutet das: Der Ausfall einer Region oder eines zentralen Dienstes erfordert aktive Wiederanlaufprozesse, Umschaltungen oder Neu-Provisionierung. Verfügbarkeit wird hergestellt, nicht fortgesetzt.

Verteilte Cloud-Infrastrukturen verfolgen einen anderen Ansatz. Daten werden parallel über mehrere voneinander unabhängige Rechenzentren hinweg vorgehalten und kontinuierlich synchronisiert. Anwendungen sind nicht an einen primären Standort gebunden, sondern greifen auf einen Datenbestand zu, der an mehreren Standorten gleichzeitig verfügbar ist. Fällt ein Rechenzentrum oder eine Region aus, übernehmen andere Standorte den Betrieb, ohne dass ein klassischer Recovery-Prozess ausgelöst werden muss.

Sovereignty-by-Design als Grundlage echter Redundanz

Bei globalen Hyperscalern ist Redundanz primär auf Infrastruktur beschränkt. Daten können mehrfach vorhanden sein, operative Kontrolle bleibt jedoch zentralisiert. Steuerung, Schlüsselverwaltung und Identitätsdienste sind global organisiert und damit gemeinsame Abhängigkeiten. Im Störungsfall wirkt sich diese Bündelung direkt auf Zugriff und Betrieb aus, unabhängig davon, wo Daten physisch liegen.

Europäische Cloud-Alternativen verfolgen einen anderen Ansatz. Betrieb, Schlüsselverwaltung und Governance sind eigenständig organisiert und im europäischen Rechtsraum verankert. Dadurch entsteht eine zusätzliche Redundanzebene oberhalb der Infrastruktur. Selbst wenn externe Plattformdienste eingeschränkt sind, bleiben Zugriff, Betrieb und Entscheidungsfähigkeit erhalten. Für Business Continuity bedeutet das: Ausfallsicherheit endet nicht bei Datenkopien, sondern schließt Kontrolle und Handlungsfähigkeit ausdrücklich mit ein.

Business Continuity als Architekturfrage

Cloud-Ausfälle sind kein Ausnahmefall, sondern ein Realitätscheck für Business Continuity. Resilienz entscheidet sich dabei nicht im Recovery-Plan, sondern darin, wie stark der laufende Betrieb an ein einzelnes Cloud-Ökosystem gebunden ist. Cloud-Alternativen, die Abhängigkeiten strukturell reduzieren, ermöglichen Unternehmen nicht nur robustere Infrastrukturen, sondern auch mehr digitale Souveränität über Betrieb, Daten und Kontrolle.

Ein Beitrag von Christian Claussen.

Christian Claussen ist General Partner beim europäischen Venture-Capital-Fonds Ventech und seit mehr als 30 Jahren in der Tech-Investmentszene aktiv.

Weitere Informationen zu Ventech finden Sie hier.