Multi-Region, Disaster Recovery und Edge Computing

Warum in mehr als einer Region betreiben

Abschnitt 0.7 (Server und die Cloud) hat Regionen (getrennte geografische Gebiete) und Availability Zones (unabhängige Rechenzentrumsgruppen innerhalb einer Region) eingeführt, und Abschnitt 10.1 hat gezeigt, wie Anbieter sie organisieren. Der Betrieb über mehrere Availability Zones in einer Region ist die normale Grundausstattung für jedes Produktivsystem: Er übersteht den Verlust eines Rechenzentrums mit geringen Mehrkosten, weil Zonen nah genug für synchrone Replikation beieinanderliegen. Der Betrieb über mehrere Regionen ist ein viel größerer Schritt, und es gibt nur drei gute Gründe dafür.

Latenz. Licht in Glasfaser legt rund 200.000 km pro Sekunde zurück, daher kann ein Round Trip zwischen London und Sydney (etwa 17.000 km Luftlinie) nicht weniger als etwa 170 ms dauern, und reale Routen brauchen deutlich länger. Eine Anfrage, die mehrere Round Trips zu einer entfernten Region braucht, fühlt sich langsam an, wie schnell die Server auch sein mögen. Nutzer aus einer nahen Region oder von der Edge zu bedienen, ist die einzige Abhilfe.

Disaster Recovery. Ganze Regionen fallen tatsächlich aus, meist durch eine gemeinsame Abhängigkeit statt durch eine physische Katastrophe. Am 19. und 20. Oktober 2025 hinterließ eine Race Condition in der Automatisierung, die DNS-Einträge für Amazon DynamoDB verwaltet, für dessen Endpoint in US-EAST-1 einen leeren DNS-Eintrag; die DynamoDB-Fehler dauerten etwa drei Stunden, doch Folgeausfälle beim Starten neuer virtueller Maschinen und bei den Health Checks der Load Balancer zogen sich bis in den folgenden Nachmittag. Jeder große Anbieter hatte vergleichbare regionale Incidents. Disaster Recovery plant für sie.

Datenresidenz. Anforderungen an die Datenresidenz aus Gesetzen, von Aufsichtsbehörden oder aus Kundenverträgen können verlangen, dass bestimmte Daten in bestimmten Rechtsräumen gespeichert oder verarbeitet werden. Die DSGVO selbst beschränkt Übermittlungen personenbezogener Daten aus dem Europäischen Wirtschaftsraum, statt eine lokale Speicherung zu verlangen, doch Branchenregeln, nationale Gesetze und Unternehmensverträge gehen oft weiter (siehe Privacy by Design). Residenz erzwingt oft Multi-Region-Designs, in denen Daten bewusst nicht überallhin repliziert werden.

Multi-Region ist teuer: doppelte Infrastruktur, Gebühren für regionsübergreifende Datenübertragung, schwierigere Datenkonsistenz sowie komplexerer Betrieb und komplexere Tests. Viele Teams, die glauben, es zu brauchen, brauchen eigentlich ein gutes Multi-Zonen-Design, getestete Backups und ein CDN.

Wiederherstellungsziele und die vier Strategien

Abschnitt 2.5 (Verfügbarkeit und Zuverlässigkeit) hat die zwei Zahlen definiert, die jedes Disaster-Recovery-Design bestimmen. Das Recovery Time Objective (RTO) gibt an, wie lange der Dienst nicht verfügbar sein darf; das Recovery Point Objective (RPO) gibt an, wie viele aktuelle Daten verloren gehen dürfen, ausgedrückt als Zeitspanne. Beide kommen aus dem Geschäft, idealerweise aus den Kosten einer Stunde Ausfall und einer verlorenen Bestellung, nicht aus den Vorlieben der Technik. Niedrigere Werte kosten mehr, und die Kosten steigen nahe null steil an.

Das AWS-Well-Architected-Whitepaper Disaster Recovery of Workloads on AWS: Recovery in the Cloud beschreibt vier Strategien in der Reihenfolge steigender Kosten und Komplexität. Die Namen sind weit über AWS hinaus gebräuchlich und gelten ebenso für Azure, Google Cloud oder ein Paar privater Rechenzentren.

Das Whitepaper selbst nennt für jede Strategie einen groben Wert, der RTO und RPO zusammen abdeckt; die Tabelle trennt sie, weil bei kontinuierlicher Replikation das RPO von Pilot Light und Warm Standby durch die Replikationsverzögerung bestimmt wird und nicht dadurch, wie viel von der Anwendung läuft. Zwei Warnungen gelten für jede Spalte. Replikation ist kein Backup: Eine versehentliche Löschung, eine fehlerhafte Migration oder Ransomware wird binnen Sekunden getreu repliziert, daher sind Point-in-Time-Backups, idealerweise unveränderlich und in einem separaten Konto, selbst in einem Active-Active-Design nötig. Und eine Strategie, die nicht geprobt wurde, ist eine Hoffnung, kein Plan. Teams, die mindestens einige Male im Jahr eine regionale Failover-Übung durchführen, entdecken fehlende Berechtigungen, fest eincodierte Endpoints, abgelaufene Zertifikate und zu kleine Quotas in der Recovery-Region, solange es noch billig ist, sie zu finden.

Daten über Regionen replizieren

Zustandslose Anwendungsserver lassen sich leicht an zwei Orten betreiben; die Daten sind der schwierige Teil, und die Abwägungen sind die von Konsistenz, CAP und PACELC über kontinentale Entfernungen. Synchrone Replikation über Regionen bedeutet, dass jeder Schreibzugriff auf mindestens einen langen Round Trip wartet, vielleicht 70 bis 150 ms oder mehr; das ist für wenige kritische Schreibzugriffe akzeptabel und ruinös für gesprächige. Asynchrone Replikation hält Schreibzugriffe schnell, aber das Replikat hinkt hinterher, und was beim Ausfall der Primärregion noch nicht angekommen ist, geht verloren: Die Replikationsverzögerung ist das tatsächliche RPO.

Es gibt vier gängige Datendesigns. Eine einzige Primärregion: Alle Schreibzugriffe gehen an eine Region, und Replikate anderswo bedienen Lesezugriffe und die Wiederherstellung; einfach, aber entfernte Nutzer zahlen Schreiblatenz, und ein Failover bedeutet, ein Replikat zu befördern (mit den Split-Brain-Risiken, die unter Replikation und Partitionierung beschrieben sind). Heimatregion pro Entität: Jeder Kunde, jedes Restaurant oder jeder Mandant hat eine Heimatregion, in der seine Daten geschrieben werden; das hält Schreibzugriffe lokal und unterstützt die Residenz, um den Preis des Routings und seltener regionsübergreifender Operationen. Mehrere Schreiber mit Konfliktauflösung: Jede Region nimmt Schreibzugriffe an, und Konflikte werden zusammengeführt, etwa per Last-Writer-Wins (der Standard bei DynamoDB Global Tables) oder mit konfliktfreien replizierten Datentypen; sicher nur für Daten, bei denen ein Zusammenführen sinnvoll ist, etwa ein Warenkorb, und gefährlich für Geld oder Lagerbestand. Global konsistente Datenbanken wie Google Spanner oder CockroachDB zahlen bei Schreibzugriffen Konsens-Latenz, um starke Konsistenz über Regionen hinweg zu bieten; bei Azure Cosmos DB wählt jede Anwendung unter fünf Konsistenzstufen, von stark bis eventual.

Die meisten realen Systeme mischen diese pro Datenbestand, genau wie Abschnitt 6.6 empfiehlt: Zahlungen und Bestellstatus in einer einzigen Primär- oder Heimatregion, Speisekarten und Restaurantdetails für Lesezugriffe überallhin repliziert und Analysedaten asynchron übertragen.

Failover, DNS und statische Stabilität

Traffic wird per DNS oder über einen globalen Load Balancer zwischen Regionen gesteuert. Beim DNS-basierten Failover prüft der DNS-Dienst jede Region per Health Check und liefert die Adresse einer gesunden zurück; seine Schwäche ist das Caching, weil Resolver und Clients alte Antworten länger halten können als die TTL des Eintrags. Globale Load Balancer (etwa AWS Global Accelerator, Azure Front Door, der globale externe Load Balancer von Google Cloud, Cloudflare) nutzen Anycast-Adressen, die von vielen Standorten aus angekündigt werden, sodass Clients eine Adresse behalten und der Anbieter den Traffic binnen Sekunden verlagert.

Zu entscheiden, wann ein Failover ausgelöst wird, ist schwieriger als der Mechanismus. Ein automatischer Failover reagiert am schnellsten, kann aber durch einen Monitoring-Fehler oder eine kurze Netzwerkstörung ausgelöst werden, und der Failover einer Datenbank birgt das Risiko, dass zwei Primärknoten Schreibzugriffe annehmen. Viele Organisationen automatisieren daher die Erkennung und die Failover-Schritte, behalten aber eine menschliche Entscheidung für den Start eines regionalen Failovers bei, mit einem Runbook und einem Zeitlimit. Auch das Zurückschwenken nach dem Incident, einschließlich der Neusynchronisierung von Daten, die in der Recovery-Region geschrieben wurden, braucht einen Plan.

Der Incident vom Oktober 2025 veranschaulicht ein Prinzip, das die AWS Builders’ Library statische Stabilität nennt: Ein System sollte während eines Ausfalls weiterarbeiten, ohne in diesem Moment Änderungen vornehmen zu müssen. Systeme, die bereits genug Kapazität am Laufen hatten, überstanden das Problem; Systeme, die neue Instanzen starten mussten oder deren Wiederherstellung von Control-Plane-Aktionen in der betroffenen Region abhing, konnten sich erst erholen, als die Region es tat. Für Disaster Recovery spricht das für vorab bereitgestellte Kapazität (Warm Standby statt Pilot Light für kritische Pfade), für einen Failover, der nur von der Data Plane der gesunden Region abhängt, und für DNS, Identitäten und Secrets, die nicht ausschließlich in der Region liegen, aus der Sie fliehen.

Zellen: den Blast Radius begrenzen

Regionen schützen vor regionalen Katastrophen; die meisten Ausfälle werden jedoch durch die eigenen Änderungen des Systems, Überlastungen und schädliche Eingaben verursacht, unter denen eine zweite Region mit demselben Code und derselben Konfiguration ebenfalls leidet. Die zellbasierte Architektur begrenzt den Blast Radius solcher Ausfälle, indem sie viele vollständige, unabhängige Kopien des Systems betreibt, Zellen genannt, die jeweils eine feste Teilmenge der Kunden bedienen. Ein schlanker Router ordnet jede Anfrage ihrer Zelle zu, meist nach Kunden- oder Mandantenkennung. Zellen teilen zur Laufzeit nichts: Jede hat eigene Anwendungsinstanzen, Queues und Datenbanken.

Erleidet eine Zelle ein schlechtes Deployment, einen überlastenden Kunden oder Datenkorruption, sind nur die Kunden dieser Zelle betroffen: bei 20 Zellen etwa 5 % von ihnen. Deployments werden Zelle für Zelle in Wellen ausgerollt, sodass ein schlechtes Release in der ersten Zelle auffällt. Das Design ist im AWS-Well-Architected-Whitepaper Reducing the Scope of Impact with Cell-Based Architecture (2023) beschrieben und wird in großem Maßstab von AWS’ eigenen Diensten und von Unternehmen wie Slack genutzt. Eine verwandte Technik, Shuffle Sharding, gibt jedem Kunden eine zufällige Kombination weniger Worker aus vielen (bei 8 Workern und 2 pro Kunde gibt es 28 Kombinationen), sodass ein Kunde, dessen Anfragen Worker zum Absturz bringen, nur seine eigene Kombination lahmlegt und die meisten anderen Kunden höchstens einen Worker mit ihm teilen.

Zellen haben ihren Preis: mehr Instanzen und Datenbanken im Betrieb, zellübergreifende Operationen (Berichte über alle Kunden, das Verschieben eines Kunden zwischen Zellen), die eigene Mechanismen brauchen, und ein Router samt Zuordnungsdienst, die extrem einfach und zuverlässig sein müssen. Sie eignen sich für große mandantenfähige Systeme mit natürlichen Partitionsschlüsseln; für eine interne Single-Tenant-Anwendung sind sie Over-Engineering.

Die Edge: CDNs und Edge Functions

Zwischen Nutzern und Regionen liegt die Edge: die Hunderte von Standorten, die Content Delivery Networks wie Akamai, Cloudflare, Fastly, Amazon CloudFront und Azure Front Door betreiben. Ein CDN cacht statische und cachebare Inhalte (Bilder, Skripte, Speisekartenseiten) in Nutzernähe, nach den HTTP-Caching-Regeln, die unter Caching beschrieben sind, und fängt Traffic-Spitzen und viele Denial-of-Service-Angriffe ab, bevor sie den Origin erreichen.

Edge Functions gehen weiter, indem sie Code an diesen Standorten ausführen: Cloudflare Workers, Fastly Compute, CloudFront Functions und Lambda@Edge, Akamai EdgeWorkers sowie die Edge Functions von Plattformen wie Vercel und Netlify. Cloudflare Workers führt Code in leichtgewichtigen V8-Isolates aus, den Sandboxes, die JavaScript-Engines für Browser-Tabs nutzen, statt in einem Container pro Funktion; daher ist der Start sehr schnell, und viele Mandanten teilen sich sicher einen Prozess. Dieser Kurs selbst läuft auf Cloudflare Workers. Gute Einsatzzwecke sind Request-Routing und A/B-Zuordnung, Authentifizierungsprüfungen und Token-Validierung, Header- und Redirect-Regeln, Bildskalierung, einfache Personalisierung und API-Proxys, die geheime Schlüssel aus dem Browser heraushalten.

Die Grenzen sind architektonischer Art. Edge Functions haben enge Grenzen für CPU-Zeit und Speicher; Edge-Speicher ist meist eventually consistent (bei Cloudflares Workers KV kann es einige Zeit dauern, bis sich ein Schreibzugriff global verbreitet hat) oder bietet starke Konsistenz nur für ein einzelnes koordinierendes Objekt, wie es Durable Objects tun; und das führende System (System of Record) bleibt normalerweise in einer Region. Ein gängiges Muster lautet daher an der Edge lesen, am Origin schreiben: Speisekarten, Restaurantseiten und Sitzungsprüfungen von der Edge ausliefern und Bestellungen und Zahlungen an die Heimatregion schicken.