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
Eines vorweg: Multi-Region-Failover klingt auf PowerPoint-Folien heroisch. In Architekturdiagrammen sieht es 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.
Doch wie sich zeigte, bleibt dieser Traum 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? Die zahlen kräftig dafür.
Warum es verdammt schwer ist
1. Es ist teuer. 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'." Mit anderen Worten: Resilienz skaliert nicht mit Architekturdiagrammen - sie skaliert mit dem Budget.
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. Sie müssen üben, nicht nur planen
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 harte Wahrheit: Die meisten Unternehmen üben 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 - wenn AWS einbricht, fühlt es sich fast okay an, weil man nicht allein ist. Ein paar Nutzer waren brutal 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 - 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 - sich irgendwann schon zusammenreißt.
Die große Lektion: Zuverlässigkeit ist nicht nur Technik
Die Feuerübung von gestern drehte sich nicht nur um Server oder Cloud-Architektur - es ging um organisatorische Prioritäten. Die Engineers waren bereit. Die Systeme? Nicht so sehr. Und das Budget? Fehlanzeige.
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. Cloud-Mehrwertdienste sind bequem - aber über Regionen hinweg 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."
Das ist der Traum. Keine PowerPoint-Vision von Five-Nines, sondern ein ruhiges, vorbereitetes Team, das Zuverlässigkeit wie eine Gewohnheit behandelt - nicht wie einen verzweifelten letzten Versuch.