Availability Zones und Cross-Regions

1) Begriffe und Ziele

Availability Zone (AZ) ist ein isoliertes Rechenzentrum innerhalb einer Region (eigene Kapazität/Netzwerk).
Region - AZ-Gruppe mit allgemeiner Geographie und Verzögerungen.

• RTO (Recovery Time Objective) - Wie lange kann ein Dienst nicht bereitgestellt werden?
• RPO (Recovery Point Objective) - Welche Datenmenge darf verloren gehen?

Normalerweise: Innerhalb der Region zielen wir auf RTO ≤ 5-15 min, RPO ~ 0-1 min, interregional - RTO ≤ 1 h, RPO ≤ 5 min (abhängig vom Produkt und Budget).

2) Architekturmodelle

2. 1 Innerhalb der Region (Multi-AZ)

Stateless-Schicht: über AZ verteilt; Balance - L4/L7 mit Health-Checks.
Stateful-Layer: Cluster mit synchroner Replikation (oder Quorum) zwischen AZ.
Cache/Warteschlangen: Cluster, mit AZ-Sharding und automatischem Failover.

2. 2 Überregional (Multi-Region)

Aktiv-Aktiv: Beide Regionen nehmen Verkehr auf.

minimale Latenz für Benutzer, schnelle Wiederherstellung; − Komplexität der Konsistenz und Konflikte.
Aktiv-Passiv (heiß/warm): Die Hauptregion dient, die zweite ist in warmer/warmer Erwartung.

einfacher Daten, billiger; − höher RTO.
Pilot-Light: minimales „Licht“ (Daten werden synchronisiert, Berechnungen entfalten sich bei einem Unfall).
DR-backup: nur Backups und Wiederherstellungsszenario (das billigste und langsamste).

3) Daten und Konsistenz

3. 1 Datenbanken

Synchrone Quorum (RPO≈0, ↑latentnost): PostgreSQL mit synchronen Standbys innerhalb einer Region; verteilte DBs (CockroachDB/Cassandra) mit lokalen Quorums (Local Quorum) und AZ-Ausgleich.
Asynchrone interregionale (RPO> 0, ↓latentnost): logische Replikation von Postgres/MySQL; «global tables» в KV/NoSQL; CDC→strim in eine andere Region.
Widersprüchliche Einträge: Verwenden Sie für aktiv-aktiv CRDT/Versionierung oder die Strategie „Quelle der Wahrheit“ (leader-region per key/tenant).

3. 2 Event-Sourcing und Warteschlangen

Warteschlangen/Streams (Kafka/Pulsar/SQS-ähnlich): mirror-topics oder cross-regionale Replikatoren; Der Schlüssel ist die Idempotenz von Consumern und Dedup durch Schlüssel.
Webhooks und externe Partner: unterschreiben, wiederholen, Offset/Checkpoints in beiden Zonen speichern.

3. 3 Cache

Lokale Caches pro Region (write-through/refresh-ahead); globaler gemeinsamer Cache nur für starke KVs (sonst Split-Brain). Behinderung durch Ereignisse (pub/sub), TTL - konservativ.

4) Globaler Datenverkehr und Netzwerkkontur

GSLB/DNS: geo-/latenzbasiertes Routing, Gesundheitschecks, „traffic-weights“ für Kanarienvögel und Unfälle.
Anycast/Edge: Wir bringen den Eingang näher an den Benutzer, dann an die nächste gesunde Region.
Failover-Politik: regionale Upstream-Pools, Verbot von 0-RTT auf kritischen Pfaden, niedrige Zeiträume für interregionale Abhängigkeiten.
Retrayrichtlinien: exponentieller Backoff + Jitter, Total-Deadline-Einschränkung, idempotente PUTs/POSTs mit 'Idempotency-Key'.

5) Kubernetes und Service Mesh

5. 1 Multi-AZ in einem Cluster

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - Vermeiden Sie die Co-Location von Replikaten.
Speicherbereiche: PV mit AZ-Replikation oder verteilte Volumensysteme.

5. 2 Multi-region (multi-cluster)

Getrennte Cluster pro Region + GitOps (Argo CD/Flux) für deklarative Synchronisation.
Service Mesh (Istio/Linkerd): locality-aware load-balancing und failover zwischen Regionen; mTLS, gemeinsame Identität.
Verkehrsverlagerung: Schritt für Schritt 1%→10%→50% auf die neue Region; Stift „0% setzen“ sofort.

6) RTO/RPO-Auswahl und Bindung an Muster

7) Fehlertoleranzprüfung (DR)

GameDays: vierteljährliches Full-Scale-Szenario „Region erloschen/AZ“.
Chaos-Injektionen: Netzwerkverzögerungen, Paketverluste, Broker/Base-Trennung in einem AZ.
RTO/RPO ist sachlich: Schaltzeiten und Datenverlust messen, Bericht veröffentlichen.
Runbooks: Schritt-für-Schritt-Anleitungen und „rote Buttons“ zum Umschalten (DNS-Gewichte, Feature-Flags, Heavy-Fit-Shutdown).

8) Beobachtbarkeit und Management

Metrikschnitte nach Region/AZ/Tenant; p95/p99 Latenz entlang der Strecken.
SLO und Error Budgets pro Region und globalen Pool.
Alerts: Die Degradierung einer Region sollte das Paging nicht „stören“, wenn die zweite den Verkehr normal führt.
Трейсы: baggage `region`, `az`, `failover=true/false`; Berichte „wie viele Anfragen gingen an failover“.

9) Sicherheit und Compliance

Datenresidenz: Verknüpfung von PII/Zahlungsdaten mit bestimmten Regionen (Gerichtsbarkeit).
Secrets: KMS/Smart HSM mit regionalübergreifenden Schlüsseln und Rotation; Trennen Sie die Schlüsselmaterialien pro Region.
mTLS und gegenseitiges Vertrauen zwischen den Regionen; Regional-übergreifendes egress durch ACL einschränken.

10) Kosten und Einsparungen

Edge-Cache + SWR - Reduktion des überregionalen Egress.
Unterschiedliche Speicherklassen (hot/warm/cold) und Downsampling von Metriken/Logs.
Auto-Scale-Profile nach Region (Nacht Minimum).
Bildidentität + differenzierte Konfiguration durch Umgebungsvariablen/Helmwerte.

11) Antipatterns

Ein Stateful-Master für das gesamte System; split-brain ohne Quorum.
Interregionale synchrone Aufzeichnung in einem einzigen RDBMS (unerschwingliche Latenz).
Globaler Cache mit starker Konsistenz ohne CRDT → Staus und „Phantome“.
Retrays ohne Idempotenz → doppelte Transaktionen/Zahlungen.
Ein einziges „globales“ SLO - verbirgt das Scheitern einer Region.
Es gibt keine regelmäßigen DR-Übungen - Pläne sind im Kampf nicht durchführbar.

12) Spezifität von iGaming/Finanzen

Die Zahlungsanbieter/KUS werden regional ausgewählt; Smart-Routing über PSP mit Gesundheitssignalen, Failover auf Backup.
Zuständigkeit: Speicherung von PII und Transaktionsprotokollen innerhalb des Landes/der Region; Cross-Region - nur Aggregate/anonym.
Limits/Responsible Play: Lokale Regeln und Stunden - nicht „frontal“ zwischen Regionen replizieren, Ereigniskonsistenz nutzen.
Boni/Guthaben: idempotente Schlüssel und „Quelle der Wahrheit“ per tenant/region; reconcile-jobs nach DR.

13) Mini-Rezepte (Pseudo-Configs)

13. 1 Envoy locality-aware + failover

yaml load_assignment:
endpoints:
- locality: { region: eu, zone: eu-a }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: eu, zone: eu-b }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: us, zone: us-a } # failover target lb_endpoints: [{ endpoint: { address:... } }]
common_lb_config:
zone_aware_lb_config: {}
locality_weighted_lb_config: {}
outlier_detection:
consecutive_5xx: 5 base_ejection_time: 30s

13. 2 Kubernetes topology spread

yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

13. 3 DNS-Gewichts-Failover (Idee)

„weight (eu) = 90“, „weight (us) = 10“ → bei Degradation von „eu“ automatisch in „us“ verschoben. Gesundheitschecks und reduzierte TTL (aber nicht zu aggressiv, 30-120 s).

14) Checkliste Prod-Ready

• Definiert durch RTO/RPO per Service und abgestimmt mit dem Unternehmen.
• Stateless verteilt auf AZ; stateful hat ein Quorum/Replikation und ein verständliches Konsistenzmodell.
• Interregionale Replikation (Acintron/CDC), Konflikt-/Deduplizierungstests.
• GSLB/Anycast sind konfiguriert, Health-Checks und Weights sind automatisierbar.
• Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
• Retrai mit Jitter, Idempotenz beim Schreiben; kurze Zeiträume überregional.
• DR-Übungen, gemessen am tatsächlichen RTO/RPO; Aktuelles Runbook.
• Beobachtbarkeit nach Region/AZ, SLO und Burn-Rate auf den Scheiben, Alerts „stören“ den normalen Betrieb nicht.
• Datenresidenz/Geheimnisse/Schlüssel entsprechen den Regulatoren.
• Wirtschaft: egress, Lagerung, Auto-Scale-Profile unter Kontrolle.

15) TL; DR

Bauen Sie Multi-AZ als Basisschicht, Multi-Region als Betriebsversicherung. Wählen Sie ein Muster (active-active/standby) unter RTO/RPO und Kosten, replizieren Sie Daten bewusst (Quorums/CDC/CRDT), verwalten Sie den globalen Verkehr über GSLB/Anycast und locality-aware balancing. Obligatorisch: Idempotenz, kurze Timeouts, regelmäßige DR-Übungen, SLO/Metriken auf den Scheiben Region/AZ. Für iGaming/Finanzen fügen Sie regionale PSPs/KYCs, Datenanforderungen und separate SLOs nach Gerichtsbarkeit hinzu.