AWS-Multi-Region-Architekturdiagramm für Hochverfügbarkeit

Die meisten AWS Multi-Region-Architekturdiagramme scheitern auf dieselbe Weise: zwei identische Kästen mit den Labels us-east-1 und eu-west-1, nebeneinander, nichts dazwischen. Das sieht nach Hochverfügbarkeit aus, beantwortet aber keine einzige Frage, die ein Reviewer oder die Person im On-Call stellen wird. Wohin gehen Schreibzugriffe? In welche Richtung wird repliziert? Was verschiebt den Traffic, wenn eine Region ausfällt, und wer oder was entscheidet das? Dieser Beitrag zeigt, was das Diagramm enthalten muss, wie sich Active-Active und Active-Passive auf dem Papier unterscheiden und wie du es in Archboard ausgehend von einem kostenlosen Beispiel zeichnest.

Was ein AWS Multi-Region-Architekturdiagramm zeigen muss

Lies das Diagramm von oben nach unten, so wie ein Request es durchläuft.

1. Globaler Einstieg: Route 53 und CloudFront

• Amazon Route 53 steht über beiden Regionen, nicht in einer davon. Schreib die Routing-Policy an die Kante: Failover (Primär- und Sekundär-Records mit Health Checks), Latency-based (jeder Nutzer landet in der Region mit der geringsten Latenz) oder Weighted. Zeichne auch die Health Checks ein, denn Failover-Routing funktioniert nur mit ihnen.
• Amazon CloudFront steht vor den regionalen Origins. Wenn du eine Origin Group mit Origin Failover nutzt, zeichne beide Origins und markiere die primäre. CloudFront Origin Failover greift für GET-, HEAD- und OPTIONS-Requests; Schreibzugriffe brauchen einen eigenen Pfad.

2. Regionaler Einstieg: Application Load Balancer

Ein ALB ist eine regionale Ressource, die sich über die Availability Zones erstreckt, die du für ihn aktivierst. Zeichne einen pro Region, innerhalb der Regionsgrenze, mit Targets in mindestens zwei AZs.

3. Compute über Availability Zones

Amazon-ECS-Services, Amazon-EKS-Node-Groups oder EC2 Auto Scaling Groups, je nachdem, was deine Anwendung ausführt, verteilt über zwei oder drei AZ-Frames. Das Diagramm soll eines klarmachen: Der Ausfall einer AZ wird innerhalb der Region abgefangen, der Ausfall einer Region auf der globalen Ebene.

4. Die Datenschicht, mit Pfeilen

Hier werden die meisten Diagramme still. Jeder Datenspeicher hat sein eigenes Replikationsmodell, und die Pfeilrichtung ist die ganze Geschichte.

Ergänze eine Notiz, dass S3-Replikationsregeln für neue Objekte gelten; Objekte, die schon vor der Regel existierten, brauchen S3 Batch Replication. Jemand wird fragen.

5. Secrets und Konfiguration

AWS Secrets Manager kann ein Secret in andere Regionen replizieren, und AWS KMS unterstützt Multi-Region Keys. Systems Manager Parameter Store ist regional. Zeichne ein, woher jede Region ihre Secrets und ihre Konfiguration liest. Ein Failover, der nur so lange funktioniert, bis die Anwendung ihr Datenbankpasswort nicht entschlüsseln kann, ist kein Failover.

6. Observability und Control Plane

Zeig, was einen Ausfall erkennt und was darauf reagiert: Route-53-Health-Checks, CloudWatch-Alarme in jeder Region, synthetische Canaries und ein regionsübergreifendes Dashboard. Wenn der Failover über Routing Controls des Amazon Application Recovery Controller (ARC) oder über ein Runbook ausgelöst wird, gehört das ebenfalls ins Diagramm. Die AWS Well-Architected Reliability Pillar empfiehlt, sich bei der Wiederherstellung auf Data-Plane-Operationen statt auf Control-Plane-Änderungen zu verlassen. DNS-Failover auf Basis von Health Checks ist ein Beispiel für Ersteres, und das Diagramm ist der richtige Ort, um zu zeigen, wovon du abhängst.

Active-Active vs. Active-Passive

AWS beschreibt vier Disaster-Recovery-Strategien. Bei dreien läuft etwas in einer zweiten Region, und jede verändert, was das Diagramm aussagen muss.

Die Zahlen legst du fest. Schreib deine RTO- und RPO-Ziele neben die Strategie auf das Canvas, damit sich Diagramm und Geschäftsanforderung gegeneinander prüfen lassen.

Active-Active ist nicht automatisch besser. Es entfernt den Promotion-Schritt, zwingt dich aber zu entscheiden, wie jeder Datenspeicher mit gleichzeitigen Schreibzugriffen umgeht. Bei Aurora Global Database schreibt immer nur eine Region; ein Active-Active-Design darauf hat also trotzdem eine einzige Schreibregion. Zeichne das ehrlich ein.

Mach den Failover-Pfad explizit

Nutze drei Kantenstile und erkläre sie in einer Legende:

• Request-Pfad: durchgezogene Pfeile von den Nutzern über DNS, CDN, ALB und Compute.
• Replikation: gestrichelte Pfeile zwischen Datenspeichern, beschriftet mit Richtung und Modus (async, Multi-Active).
• Failover: ein eigener, beschrifteter Pfad, der zeigt, wohin der Traffic geht, wenn die primäre Region ungesund ist.

Nummeriere dann die Failover-Sequenz in einer Notiz auf dem Canvas:

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

Wenn ein Schritt manuell ist, schreib dazu, wer ihn ausführt. Wenn ein Schritt von einer Control-Plane-API abhängt, markiere ihn.

Häufige Fehler

• Eine Region doppelt gezeichnet, ohne Datenfluss. Zwei Kopien desselben Stacks ohne Replikationspfeile sagen nichts über Wiederherstellung aus.
• Die Control Plane verstecken. Health Checks, Routing Controls und Runbooks entscheiden, ob ein Failover passiert. Fehlen sie, beschreibt das Diagramm ein System, das keinen Failover kann.
• Keine Failover-Pfeile. Der Request-Pfad im Normalbetrieb ist nur die halbe Geschichte.
• Globale Services innerhalb einer Region. Route 53 und CloudFront sind global; in einem Regions-Frame suggerieren sie eine Abhängigkeit, die es nicht gibt, oder verdecken eine, die es gibt.
• Keine AZs. Redundanz auf Regionsebene ersetzt keine Redundanz auf AZ-Ebene; zeig beides.
• Vergessener State. Caches, Queues und Session Stores sind ebenfalls regional. Zeig, wo sie liegen und was mit ihnen passiert.

So baust du es in Archboard

In Archboard baust du das mit Nodes aus dem Cloud- und Network-Pack: vollwertige Nodes mit Ports, die du mit den AWS-Servicenamen beschriftest. So zeigt jeder Kasten seine Rolle und den genauen Service. So baust du das Diagramm auf.

1. Sieh dir die kostenlose Vorlage an. Öffne /examples/multi-region-cloud-ha. Sie zeigt ein CDN, einen Load Balancer über zwei Regionen, Compute und eine verwaltete Datenbank über Regionen hinweg. Nutze sie als Referenz oder kopiere sie mit Dieses Beispiel verwenden in deinen Workspace und erweitere sie dann um die Schichten oben.
2. Lege Regions- und AZ-Grenzen an. Füge zwei Cloud-Pack-Region-Frames mit den Labels us-east-1 (primary) und eu-west-1 (secondary) hinzu. Darin jeweils Core-Frame-Elemente für die AZs.
3. Setz die globale Ebene über die Regionen. Network-Pack-Internet für die Nutzer, Network-Pack-DNS mit dem Label Route 53 (failover routing) und Cloud-Pack-CDN mit dem Label CloudFront.
4. Füll jede Region. Cloud-Pack-Cloud LB mit dem Label ALB, Compute-Nodes in jedem AZ-Frame mit ECS service oder EC2 Auto Scaling group (oder ein Kubernetes Cluster-Node für EKS), Managed DB-Nodes mit Aurora (writer) und Aurora (secondary, read-only), ein weiterer für DynamoDB global table und Object Storage mit dem Label S3.
5. Verbinde Ports und beschrifte jede Kante. Request-Pfad, Replikationsrichtung und -modus, Failover-Pfad. Nutze die Kantenlabels für Routing-Policy und Replikationstyp.
6. Ergänze Control Plane und Notizen. Core-Box-Nodes für Secrets Manager, CloudWatch und Health Checks; eine Note mit der nummerierten Failover-Sequenz; einen Markdown-Block mit deinen RTO- und RPO-Zielen und der gewählten Strategie.

Zähl deine Nodes, bevor du startest: Eine vollständige Karte über zwei Regionen geht meist über die 15 Diagramm-Nodes pro Diagramm des Free-Plans hinaus (Notizen und Texte zählen separat, bis zu 150). Pro passt hier am besten, mit unbegrenzten Nodes, Einbettung in deine Doku-Site und PDF-Export. Weitere Muster findest du auf der Cloud-Anwendungsfallseite.

FAQ

Kann ich offizielle AWS-Icons in Archboard verwenden? Die typisierten Cloud- und Network-Nodes von Archboard sind anbieterneutral, aber du kannst AWS-Logos mit dem Core-Icon-Node hinzufügen, der Iconify durchsucht (zum Beispiel logos:aws-route53), oder die offiziellen AWS Architecture Icons als Bilder hochladen. Beschrifte jeden Node mit dem AWS-Servicenamen, etwa Route 53 oder Aurora Global Database, und das Diagramm ist für alle, die AWS kennen, klar lesbar.

Soll ich Regionen und AZs zeichnen? Ja. AZs zeigen, wie du den Ausfall einer Zone überstehst, Regionen, wie du einen regionalen Ausfall überstehst. Das sind unterschiedliche Fehlerarten mit unterschiedlichen Mechanismen.

Active-Active oder Active-Passive? Starte bei deinen RTO- und RPO-Zielen und deinem Datenmodell. Hat deine Hauptdatenbank nur eine Schreibregion, ist Active-Passive (Pilot Light oder Warm Standby) oft das einfachere und ehrlichere Design. Schreib die Entscheidung ins Diagramm.

Wie teile ich es? Exportiere SVG oder PNG (im Free-Plan mit Wasserzeichen), teile einen öffentlichen Link oder bette es mit Pro in deine Doku ein.

Kostenlos starten — ein Seat, keine Kreditkarte