Warum Cloud-Ausfälle zu irrationalen Multi-Cloud-Entscheidungen führen

AWS fällt aus. LinkedIn explodiert. Diskussionen über amerikanische Cloud-Anbieter, europäische Alternativen, Datensouveränität.

In den Strategie-Meetings der Unternehmen? Stille.

Die Diskussion ist lauter als die Handlung. Das erste Signal, etwas stimmt hier nicht.

Multi-Cloud ist ein sinnvolles Architektur-Prinzip, aber nicht als spontane Reaktion auf einen einzelnen Ausfall.

Die Frage, die niemand beantworten will

Wenn dann jemand kommt und Multi-Cloud fordert, stellen wir eine einfache Frage: "Was genau ist das Problem, das wir lösen wollen?"

Meistens kommt dann erstmal Stille.

Also bohren wir weiter: "Wie viele Stunden Ausfall hattet ihr tatsächlich?"

Die Antwort ist fast immer: kaum welche. Dann rechnen wir gemeinsam durch, was Multi-Cloud oder ein Provider-Wechsel kosten würde. Nicht nur Lizenzkosten, sondern Komplexität, Team-Kapazität, Betrieb, Schulungen.

Plötzlich wird klar: Wir reden über eine Lösung für ein Problem, das wir nicht haben.

Die Rechnung, die keiner machen will

Multi-Cloud aus Angst kostet. Doppelte Infrastrukturkosten, mehr Leute im Betrieb, eventuell mehr Entwickler für Anpassungen.

Richtig geplant bringt Multi-Cloud Mehrwert, etwa für regulatorische Trennung, Geo-Redundanz oder Datenhoheit. Aber dafür braucht es eine bewusste Architekturentscheidung, keine Reflexreaktion.

Der AWS Route 53 Dienst hat eine SLA von 100% Verfügbarkeit. Trotzdem gab es am 20. Oktober 2025 Ausfälle. Ein internes Subsystem für Load Balancer Health-Checks löste DNS-Probleme aus. Der DNS-Server hielt, was er versprach. Das nachgelagerte System nicht.

Multi-Cloud hätte hier nicht geholfen. Was geholfen hätte: DNS-TTLs auf 5-10 Minuten statt höher setzen.

Oder OVH im März 2021: Ein Brand im Rechenzentrum in Straßburg. Physische Zerstörung von Servern. Tausende Websites offline.

Spektakulär. Unvergesslich. Überall in den Nachrichten.

Beim AWS-Ausfall hätten niedrigere DNS-TTLs geholfen. Beim OVH-Brand hätten Backups in einer anderen Region geholfen. Beides grundlegende Best Practices.

Warum pragmatische Lösungen sich schlecht verkaufen

Viele CTOs wollen nach so einem Vorfall etwas Großes präsentieren. "Wir haben jetzt eine Multi-Cloud-Strategie" klingt im Board-Meeting besser als "Wir haben unsere DNS-TTLs angepasst".

Technik richtig verkaufen

Wir übersetzen es in Business-Sprache. Statt "Wir passen TTLs an" sagen wir: "Wir implementieren ein Resilience-Framework mit messbaren Verbesserungen der Recovery-Zeit."

Dann rechnen wir vor: Multi-Cloud kostet ein Vielfaches im Jahr. Diese Maßnahmen kosten einen Bruchteil davon und reduzieren das tatsächliche Risiko effektiver, basierend auf realen Ausfallmustern.

Zahlen schlagen Emotionen.

Die unbequeme Wahrheit

Die allermeisten Ausfälle sind eigene Fehler. Die Deployment-Pipelines der großen Anbieter sind ausgereift. Teams, die ihre Deployments nicht im Griff haben, denen fliegt während dem Deployment eher mal was um die Ohren.

Eine saubere Codebase, ein guter Prozess, automatische Tests mit Quality Gates helfen hier ungemein.

Teilweise werden Betriebsteams einfach ins kalte Wasser geworfen: Hier ist ein neues System, wir wechseln in die Cloud, macht mal. Dabei entstehen technische Schulden, die es später zu lösen gibt.

Warum fokussieren sich dann so viele auf die seltenen Provider-Ausfälle?

Die Psychologie der Machtlosigkeit

Bei Provider-Ausfällen besteht Machtlosigkeit. Das ist wie Flugangst. Es passiert selten was, aber wenn es passiert, ist es überall in den Medien.

Diese Angst ist irrational, weil wir nicht eingreifen können. Eine Art Machtverlust.

Die Verfügbarkeitsheuristik erklärt das: Wir bewerten Risiken basierend auf der Leichtigkeit, mit der wir uns an ähnliche Vorfälle erinnern. Spektakuläre Cloud-Ausfälle bleiben im Gedächtnis und beeinflussen künftige Entscheidungen unverhältnismäßig stark.

Ein AWS-Ausfall macht Schlagzeilen. Ihr fehlerhaftes Deployment nicht.

Das Problem sind nicht die Provider. Das Problem sind wir.

Drei Schritte vor Multi-Cloud

Bevor Unternehmen über Multi-Cloud nachdenken, sollten sie drei Dinge machen:

Observability und Monitoring aufbauen. Wenn Sie nicht sehen, was in Ihrem System passiert, können Sie nicht reagieren. Prometheus, Grafana, strukturiertes Logging. Die Basics müssen sitzen. Sie müssen wissen, wann etwas schiefgeht, bevor Ihre Kunden es merken.

Deployment-Prozesse automatisieren und absichern. Infrastructure as Code mit Terraform oder ähnlichem, automatisierte Tests, Quality Gates in der Pipeline. Die meisten Probleme entstehen hier. Wenn Ihre Deployments nicht sauber laufen, ist Multi-Cloud nur ein weiterer Ort, an dem Sie Fehler machen können.

Chaos Engineering betreiben. Testen Sie aktiv, was passiert, wenn Dinge ausfallen. Simulieren Sie Availability-Zone-Ausfälle, kill Pods, testen Sie Ihre Failover-Mechanismen. Wenn Sie nicht wissen, wie Ihr System unter Stress reagiert, wissen Sie nicht, ob Ihre Redundanz überhaupt funktioniert.

Erst wenn diese drei Punkte stehen, macht es Sinn, über Multi-Cloud nachzudenken.

Wann Multi-Cloud tatsächlich Sinn macht

Es gibt Situationen, wo Multi-Cloud oder extreme Redundanz berechtigt ist. Wenn jede Minute Ausfall direkt messbare Millionenverluste bedeutet: Finanzhandel, kritische Infrastruktur, große E-Commerce-Plattformen am Black Friday.

Oder wenn regulatorische Anforderungen es verlangen, etwa im Gesundheitswesen oder bei Behörden mit Datensouveränitäts-Vorgaben.

Dann rechnet sich Multi-Cloud.

Aber selbst da gilt: Erst die Basics machen. Monitoring, Observability, automatisierte Failover-Mechanismen innerhalb eines Providers. Die meisten Ausfälle entstehen nicht durch Provider-Probleme, sondern durch eigene Fehler.

Die Grenze ist dort, wo die Business-Impact-Analyse zeigt, die Kosten der Lösung sind niedriger als der erwartete Schaden mal Eintrittswahrscheinlichkeit.

Alles andere ist Bauchgefühl.

Cloud-Resilienz entsteht durch bessere Architektur

Werner Vogels hat es auf den Punkt gebracht: "Everything fails, all the time."

In der Cloud passieren Ausfälle. Die Frage ist, wie gehen wir damit um und sind wir vorbereitet?

Wir bei DMoove entwickeln Cloud-Strategien auf Basis realer Daten statt Ängste. Wir rechnen durch, was tatsächlich Sinn macht. Wir bauen Systeme, die resilient sind, weil sie richtig gebaut sind, nicht weil sie überall verteilt sind.

Am Ende zählt nicht, wie viele Cloud-Anbieter Sie haben. Sondern wie gut Sie mit Ausfällen umgehen können, wenn sie passieren.

Cloud-Resilienz entsteht nicht automatisch durch mehr Clouds, sondern durch bessere Architekturentscheidungen. Multi-Cloud ist dabei ein Baustein, wenn Sie sie gezielt einsetzen.