Multi-Region-Failover: Warum es schwieriger ist, als die meisten Diagramme vermuten lassen

Gestern Morgen tippten Engineers auf der ganzen Welt eine Phrase in Google, als hinge ihr Job davon ab, denn für einen Moment tat er das tatsächlich: "Wie man Multi-Region-Failover auf AWS einrichtet."

Ein größerer Ausfall traf die AWS-Region US-East-1, erneut, und wie eine Dominokette aus digitalem Chaos gingen Dienste wie OpenAI, Snapchat, Canva, Duolingo, Perplexity und sogar Coinbase offline. Und schon nippten zuvor entspannte DevOps-Teams plötzlich an dreifachen Espressi, blätterten durch Slack-Alerts und versuchten sich zu erinnern, ob ihre Infrastrukturdiagramme Wunschdenken waren oder tatsächlich funktionierten.

Wie ein Engineer es formulierte: "Wir sind in 37 Minuten von selbstbewusst über panisch zu seltsam philosophisch übergegangen." Genau diese Stimmung.

Die Illusion der Einsatzbereitschaft

Multi-Region-Failover klingt auf PowerPoint-Folien heroisch und sieht in Architekturdiagrammen wunderschön aus. Man stellt sich Server vor, die in weit entfernten, klimatisierten Rechenzentren vor sich hin summen und nur darauf warten, wie ein digitaler Stunt-Double einzuspringen, wenn es schiefgeht.

Wie sich zeigte, bleibt dieser Traum aber oft genau das, ein Traum. Hinter den Kulissen zeigt sich, dass viele Unternehmen längst nicht so "resilient" sind, wie sie glauben. Und die, die es sind, zahlen kräftig dafür.

Warum es verdammt schwer ist

1. Es ist richtig teuer

Sie wollen jederzeit spontan die Region wechseln können? Dann müssen Sie Ihre Infrastruktur verdoppeln oder verdreifachen und die Wartung bezahlen. Engineers an der Front witzelten gestern, "dreifach ist am besten", aber im Finance-Team lacht darüber niemand.

Ein Senior Engineer schrieb: "Kunden verlangen immer den besten DR-Workflow, aber sobald wir die Kosten nennen, wird der Ausfall plötzlich 'unwahrscheinlich'." Resilienz hängt also am Budget, egal wie gut die Architekturdiagramme aussehen.

2. Nicht jeder Dienst unterstützt Failover

Sie denken, Ihr cleveres Multi-Region-Setup macht Sie sicher? Schön. Erklären Sie mal, was Sie tun, wenn Docker Hub ausfällt oder Ihr Identity-Provider ausschließlich in US-East-1 liegt. Oder wenn Ihre Build-Pipeline abstürzt, weil sie kein Dependency-Repo erreicht. Jemand merkte an: "Chaos Engineering klingt jetzt gar nicht mehr so abwegig", und ehrlich gesagt ist es wahrscheinlich längst überfällig.

Mehrere Engineers stießen an Grenzen, bei denen Dienste wie ECR, IAM Identity Center oder sogar Datadogs PrivateLink schlicht nicht die Region wechseln konnten, weil sie es einfach nicht unterstützen. Ein Nutzer berichtete grimmig: "Unsere neue interne Dokumentationsplattform ist ausgefallen, genau die, auf die wir unsere Notfallpläne verschoben hatten." Das ist Scheitern mit poetischer Note.

3. Drittanbieter spielen nicht mit

Selbst wenn Ihr Stack über mehrere Regionen hinweg felsenfest steht, reicht ein einziger wackliger Anbieter, um alles lahmzulegen. "Unsere Infra lief einwandfrei", berichtete ein Team, "aber Twilio war down, und unsere Nutzer konnten sich nicht einloggen. Es spielt keine Rolle, wie resilient wir sind, wenn unsere Integrationen es nicht sind."

Sie können eine perfekte Failover-Architektur haben, aber wenn Ihr Feature-Flag-Anbieter, Login-Dienst oder Analytics-Vendor am Ende ist, sind Sie es auch.

4. Üben Sie Ihre Failover regelmäßig

Failover ist nichts, das man einmal einrichtet und dann vergisst. Eines der besser vorbereiteten Teams gab zu, dass es absichtlich regelmäßig zwischen Regionen wechselt, nur um Routine aufzubauen. Ein Kommentar brachte es auf den Punkt: "Wenn Sie nicht regelmäßig hin- und herwechseln, wird es im Ernstfall nicht funktionieren."

Die meisten Unternehmen üben aber nicht. Sie haben Region-Failover theoretisch eingerichtet, aber ungetestet. Wenn AWS stolpert, merken sie, dass sie immer noch an der Region kleben wie an einer schlechten Beziehung, aus der sie längst hätten aussteigen wollen.

Wenn "Ausfall" bedeutet, dass alle betroffen sind

Und hier wird es kurios, denn wenn AWS einbricht, fühlt es sich fast okay an, weil man nicht allein ist. Ein paar Nutzer waren erschreckend ehrlich: "Unser DR-Plan besteht im Grunde nur darin, zu warten, bis AWS sich selbst repariert."

Ein Kommentator sagte sogar: "Wenn AWS ausfällt, geht das Internet down, also haben Kunden Verständnis, wenn wir auch ausfallen." Geteiltes Leid ist halbes Leid, und wenn alle kaputt sind, fühlt sich der eigene Ausfall weniger katastrophal an.

Diese Haltung fand sich in Dutzenden Kommentaren wieder. So sehr Unternehmen von 99,999 % Verfügbarkeit träumen, so oft winken sie bei echten Investitionen ab, wenn diese nur einen schlechten Tag alle zwei Jahre verhindern. Stattdessen verlassen sie sich darauf, dass AWS oder irgendjemand sonst sich irgendwann schon zusammenreißt.

Zuverlässigkeit ist am Ende eine Budgetfrage

Die Feuerübung von gestern drehte sich weniger um Server oder Cloud-Architektur als um organisatorische Prioritäten. Die Engineers waren bereit, die Systeme weit weniger, und das Budget fehlte ganz.

Jemand brachte es perfekt auf den Punkt: "Mein CTO fragte, warum wir betroffen waren. Ich sagte: 'Weil du die DR-Lösung nicht bezahlen wolltest, um die ich seit drei Jahren bitte.'" Autsch.

Der Ausfall legte die Kluft zwischen technischer Machbarkeit und unternehmerischer Bereitschaft offen. Failover-Pfeile zwischen Regionen zu zeichnen ist einfach, sie zu finanzieren deutlich schwerer.

Was also jetzt?

Eine Wunderwaffe gibt es hier nicht. Aber aus dem Chaos kristallisierten sich einige Lehren heraus:

• Üben Sie Ihre Failover, und zwar wirklich.
• Investieren Sie in Primitives, denn Cloud-Mehrwertdienste sind bequem, über Regionen hinweg aber oft fragil.
• Prüfen Sie Drittanbieter-Abhängigkeiten und gehen Sie davon aus, dass mindestens eine Sie im Stich lässt.
• Fordern Sie realistische Budgets, oder seien Sie ehrlich darüber, was passiert, wenn die Cloud ins Wanken gerät.
• Dokumentieren Sie offline. Vertrauen Sie uns einfach in diesem Punkt.

Eine der besten Zusammenfassungen kam von einem Team, das seit über einem Jahrzehnt für genau solche Tage baut. Sie schrieben: "Heute war kein Spaß, aber es war keine Panik. Es hat Jahre gedauert, hierher zu kommen, aber jetzt können wir einzelne Dienste bei Bedarf per Failover aus einer Region herausnehmen."

So sieht der Traum in Wirklichkeit aus: ein ruhiges, vorbereitetes Team, für das Zuverlässigkeit eine Gewohnheit ist, weit weg von PowerPoint-Visionen mit Five-Nines und von verzweifelten letzten Versuchen.