Warum Ausfälle trotzdem passieren – wenn Redundanz nicht mehr reicht

Multi-Cloud klingt sicher – aber nur, wenn man richtig hinschaut

Viele Teams verteilen ihre Anwendungen bewusst auf mehrere Cloud-Anbieter. Das Ziel: Ausfälle bei einem Provider sollen keine Auswirkungen haben. Railway hat genau das gemacht. Ihre Workloads liefen auf AWS, Google Cloud und der eigenen Infrastruktur. Trotzdem ging alles schief.

Am 19. Mai 2026 sperrte Google Cloud das Konto von Railway ohne Vorwarnung. Die eigentlichen Anwendungen blieben dabei komplett unberührt. Trotzdem war Railway für alle Nutzer plötzlich nicht mehr erreichbar.

Der unsichtbare Hebel: Woher die Proxies wissen, wohin sie senden sollen

Jede Anfrage trifft zuerst auf Edge-Proxys. Diese entscheiden, an welchen Server sie den Traffic weiterleiten. Dafür brauchen sie aktuelle Informationen – vor allem, wo sich die jeweilige Anwendung gerade befindet.

Diese Informationen kommen aus dem Control Plane. Railway hatte ihn komplett bei Google Cloud liegen. Als das Konto gesperrt wurde, stand auch dieser zentrale Dienst still. Die Proxys konnten noch etwa 35 Minuten mit zwischengespeicherten Daten arbeiten. Danach wussten sie nicht mehr, wohin sie die Anfragen schicken sollten.

Das Ergebnis: Jede Anfrage endete mit einem 404-Fehler. Dabei liefen die Anwendungen auf AWS und der eigenen Hardware problemlos weiter.

Was noch schiefging: Eine Kettenreaktion

Plötzlich trafen massenhaft fehlerhafte Anfragen bei GitHub ein. Das System erkannte das als möglichen Angriff und sperrte Railways OAuth-Zugänge. Nutzer konnten sich nicht mehr einloggen. Neue Deployments waren nicht mehr möglich – selbst nachdem der Control Plane wieder lief.

Redundanz allein reicht nicht

Railway hatte die Workloads verteilt. Der Control Plane blieb jedoch an einem Ort. Genau dieser Punkt wurde zum Single Point of Failure. Eine automatische Sicherheitsmaßnahme von Google Cloud hat damit die gesamte Routing-Logik lahmgelegt.

Solche Abhängigkeiten fallen oft erst dann auf, wenn es ernst wird. Gerade bei Multi-Cloud-Strategien wird gerne angenommen, dass verteilte Systeme auch automatisch resilient sind. Das stimmt nur, wenn auch der Control Plane entsprechend verteilt ist.

Was daraus für die eigene Architektur folgt

• Control Plane und Data Plane sind nicht gleich. Wer nur die Anwendungen verteilt, hat noch lange keine echte Ausfallsicherheit.
• Caching hilft nur kurz. 35 Minuten Pufferzeit sind besser als nichts, aber danach ist Schluss. Langfristig braucht es echte Redundanz, nicht nur Zeitgewinn.
• Kettenreaktionen sind schwer zu stoppen. Ein Ausfall kann schnell weitere Probleme auslösen – etwa bei externen Diensten wie GitHub.
• Automatisierte Systeme der Provider kennen. Viele Ausfälle entstehen durch Sicherheitsmaßnahmen. Wer weiß, was diese auslöst und frühzeitig Kontakt aufnehmen kann, kann Schaden deutlich reduzieren.

Was Railway jetzt ändert

Railway hat angekündigt, den Control Plane nicht mehr allein bei Google Cloud zu belassen. Künftig soll er auch auf AWS und der eigenen Infrastruktur laufen. Damit sollen solche Abhängigkeiten künftig vermieden werden.

Für Teams, die mit Multi-Cloud arbeiten, zeigt dieses Beispiel: Redundanz muss man gezielt planen. Gerade bei Routing und Service-Discovery gibt在