Ein Fehler. Nicht das ganze System.

Wahrscheinlich nicht, und diese Antwort spart Ihnen oft einen sechsstelligen Betrag. Multi-Region heißt: Daten doppelt halten, Konflikte auflösen, den Schwenk regelmäßig proben, und alles zweimal betreiben. Das ist richtig, wenn ein Ausfall von Stunden das Geschäft bedroht oder ein Vertrag es fordert. Für die meisten Anwendungen liegt der größere Gewinn unterhalb davon: Verteilung über Zonen, die wirklich geprobt ist, ein Wiederanlauf mit gemessenen Werten, und ein Verhalten unter Teilausfall, das nicht alles mitnimmt. Der Artikel zum Regionsausfall rechnet das durch.

Nein, und die beiden Seiten gehören trotzdem zusammen. Observability beantwortet, ob und wo etwas kaputt ist – sehen. Diese Seite beantwortet, was passiert, während es kaputt ist – überleben. Ein System kann vorbildlich beobachtet und dabei fragil sein, und es kann robust sein, ohne dass jemand es merkt. In der Reihenfolge gilt: Ohne ein Minimum an Sichtbarkeit lässt sich kein Ausfall kontrolliert proben, deshalb fange ich manchmal dort an.

Mit begrenzter Reichweite und einer Abbruchbedingung, und in dieser Reihenfolge: erst auf einer Vorstufe, dann kontrolliert in Produktion, und nur wenn die Beobachtung stark genug ist, um früh abzubrechen. Der AWS Fault Injection Service macht genau das planbar – ein Versuch definiert vorher, was er anfasst, wie lange, und welche Bedingung ihn stoppt. Kein Versuch in Produktion ohne Ihre ausdrückliche Freigabe und ein Zeitfenster, das Sie bestimmen.

Ein Backup ist die halbe Antwort; die andere Hälfte ist der Restore, und der wird selten geübt. In der Probe fällt regelmäßig auf, was im Konzept nicht steht: ein Schlüssel, der im verlorenen Konto lag, eine Reihenfolge, in der Dienste starten müssen, eine Konfiguration, die nur auf der alten Maschine existierte, ein DNS-Eintrag mit langer Gültigkeit. Deshalb ist der ausgeführte Restore der Kern dieses Angebots und nicht eine Zeile im Bericht.

Nein, und das ist eine Festlegung, keine Kapazitätsfrage. Ich baue es auf, probe es mit Ihnen und übergebe es. Ausfallsicherheit, deren Wissen außerhalb des Unternehmens liegt, ist im Vorfall genau dort falsch. Wenn Sie dauerhafte Rufbereitschaft brauchen, brauchen Sie ein Team oder einen Dienstleister mit Schichtbetrieb, und beides bin ich nicht.

Weniger als der Ruf sagt, wenn man die Stufen trennt. Verteilung über Availability Zones kostet bei zustandslosen Diensten fast nichts und bei Datenbanken etwa das Doppelte für den Speicher. Was teuer wird, ist die zweite Region, und die ist selten nötig. Deshalb steht im Befund neben jeder Maßnahme, was sie im Monat kostet – die Kostenseite ist die Nachbarseite dazu, und dieselbe Person schreibt beide.

Ja, und oft leichter als bei einer verteilten Anwendung. Ein Monolith hat weniger Wege, auf denen ein Fehler sich ausbreitet; sein Problem ist meistens die Datenbank und ein Deployment, das ihn kurz ganz wegnimmt. Genau daran lässt sich arbeiten, ohne die Anwendung zu zerlegen: geprobter Datenbankschwenk, zwei Instanzen statt einer, Schemaänderungen in zwei Schritten. Ein Umbau auf Microservices ist keine Voraussetzung und selten die Antwort.

Die Muster gelten überall, die Werkzeuge nicht. Zeitlimits, Wiederholungen mit Streuung, idempotente Verarbeitung und ein geprobter Restore sind unabhängig vom Anbieter. Was ich konkret einrichte, kenne ich am besten auf AWS, und dort arbeite ich täglich. Läuft Ihr System woanders und nur ein Teil auf AWS, sage ich Ihnen im Erstgespräch, welcher Teil sich lohnt.