0Pricing
Cloud & IT Cert Prep · Lektion

Multi-Site Active-Active mit Global Tables und Route 53

Betreiben Sie mit DynamoDB Global Tables, Aurora Global Database und dem Latenz-Routing von Route 53 gleichzeitig die volle Produktionskapazität in zwei oder mehr Regionen.

Multi-Site Active-Active mit Global Tables und Route 53 ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Multi-Site-Active-Active erklärt

Multi-Site-Active-Active ist die höchste Stufe der Notfallwiederherstellung. Dabei läuft Ihre Anwendung gleichzeitig in zwei oder mehr AWS-Regionen mit voller Produktionskapazität. Anders als bei Active-Passive, wo eine Standby-Umgebung auf die Übernahme wartet, bedienen bei Active-Active beide Regionen jederzeit den Live-Traffic der Benutzer. Wenn eine Region ausfällt, übernimmt die andere sofort 100 % des Traffics – ohne Verzögerung durch einen Failover. Dieses Muster reduziert außerdem die Latenz für weltweit verteilte Benutzer, da sie aus der nächstgelegenen Region bedient werden.

# Active-Active traffic split (normal operation):
# us-east-1: serving ~50% of users (North America)
# eu-west-1: serving ~50% of users (Europe)

# Active-Active traffic split (us-east-1 failure):
# us-east-1: 0% (health check failed)
# eu-west-1: 100% (ASG scales up automatically)

# RTO: near-zero (DNS TTL propagation only)
# RPO: near-zero (with DynamoDB Global Tables)

Architektur von DynamoDB Global Tables

DynamoDB Global Tables bildet das Datenfundament von Active-Active-Architekturen. Global Tables ermöglichen die Replikation mit mehreren Mastern über mehrere Regionen hinweg – Anwendungen in jeder Region können in eine lokale DynamoDB-Tabelle lesen und schreiben, und Änderungen werden innerhalb von etwa 1 Sekunde in alle anderen Regionen repliziert. Sie aktivieren Global Tables, indem Sie angeben, in welchen Regionen die Tabelle vorhanden sein soll. AWS übernimmt automatisch die gesamte Replikation, Konfliktauflösung (Last-Writer-Wins) und den Failover.

# Create DynamoDB table and add global regions
aws dynamodb create-table \
  --table-name UserSessions \
  --attribute-definitions AttributeName=userId,AttributeType=S \
  --key-schema AttributeName=userId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

# Add replica regions for Global Table
aws dynamodb update-table \
  --table-name UserSessions \
  --replica-updates '[{"Create":{"RegionName":"eu-west-1"}},{"Create":{"RegionName":"ap-southeast-1"}}]' \
  --region us-east-1

Aurora Global Database für aktive Lesezugriffe

Aurora Global Database ermöglicht aktive Lesezugriffe, aber passive Schreibzugriffe. Alle sekundären Regionen bedienen Lesezugriffe mit einer Replikationsverzögerung von unter 1 Sekunde, während nur die Primärregion Schreibzugriffe akzeptiert. Dies ist ideal für leseintensive Anwendungen, die weltweit Lesezugriffe mit niedriger Latenz und eine eindeutig festgelegte Schreib-Primärregion benötigen. Bei einem Ausfall der primären Region können Sie eine sekundäre Region innerhalb von weniger als 1 Minute zur Primärregion hochstufen und so ein niedriges RTO für die Schreibebene erreichen. Im Gegensatz dazu unterstützt DynamoDB Global Tables aktive Schreibzugriffe in allen Regionen.

# Aurora Global Database read configuration
# Primary region (us-east-1): reads + writes
# Secondary region (eu-west-1): reads only
#   ~100ms replication lag, serves EU users low-latency reads

# Application reads from local Aurora endpoint
# Application writes to primary region Aurora endpoint

# Java connection string with region routing:
# readEndpoint=eu-west-1.cluster-ro-xxx.aurora.amazonaws.com
# writeEndpoint=us-east-1.cluster-xxx.aurora.amazonaws.com

Route-53-Routing für Active-Active

Route 53 steuert den Traffic in Multi-Site-Active-Active-Architekturen. Verwenden Sie latenzbasiertes Routing, um jeden Benutzer an die Region mit der geringsten Netzwerklatenz von seinem Standort aus weiterzuleiten. Verknüpfen Sie jeden regionalen Datensatz mit Health Checks. Wenn eine Region ihren Health Check nicht besteht, entfernt Route 53 sie automatisch aus den DNS-Antworten und leitet den gesamten Traffic an die verbleibenden gesunden Regionen weiter. Setzen Sie die DNS-TTL auf 60 Sekunden oder weniger, um die Zeit bis zum Failover der Benutzer auf die gesunde Region zu minimieren.

# Route 53 latency routing with health checks
aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXX \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "Region": "us-east-1",
          "SetIdentifier": "us-east-1",
          "HealthCheckId": "hc-us-east-1",
          "AliasTarget": {"DNSName": "alb-us-east-1.amazonaws.com", "EvaluateTargetHealth": false}
        }
      }
    ]
  }'

Auto Scaling zur Aufnahme von Traffic

Wenn eine Region in einer Active-Active-Konfiguration ausfällt, muss die verbleibende Region das Doppelte (oder mehr) ihres normalen Traffics verarbeiten. Ihre Auto Scaling Group muss über eine ausreichende maximale Kapazität und Scale-out-Richtlinien verfügen, die schnell reagieren. Konfigurieren Sie Target-Tracking-Skalierung auf Grundlage der ALB-Anforderungsanzahl pro Ziel, damit die ASG bei einer Verdopplung des Traffics automatisch Instanzen hinzufügt. Ziehen Sie außerdem ein Pre-Warming in Betracht: Beobachten Sie während Failover-Übungen, wie schnell Ihre ASG skaliert, und stellen Sie sicher, dass sie die erforderliche Kapazität innerhalb Ihres RTO-Ziels erreicht.

# ASG target tracking for request count
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name app-asg-eu-west-1 \
  --policy-name scale-on-requests \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 1000,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
    },
    "ScaleInCooldown": 60,
    "ScaleOutCooldown": 30
  }'

Sitzungsverwaltung in Active-Active

In einer Architektur mit nur einer Region können Benutzersitzungen lokal auf Anwendungsservern gespeichert werden. Bei Active-Active über mehrere Regionen hinweg können Benutzer bei nachfolgenden Anfragen zwischen Regionen wechseln, wodurch serverseitige Sitzungen ungültig werden. Mögliche Lösungen: 1) Zustandslose Sitzungen – speichern Sie Sitzungsdaten in einem signierten JWT oder Cookie, das jeder Server in jeder Region validieren kann. 2) DynamoDB Global Tables für Sitzungen – speichern Sie Sitzungen zentral und ermöglichen Sie den Zugriff aus jeder Region innerhalb von Millisekunden. 3) ElastiCache mit Global Datastore – verwenden Sie die Redis-Replikation über Regionen hinweg zur Speicherung von Sitzungen.

# DynamoDB Global Table for session storage
# Session item structure:
{
  'sessionId': 'sess-abc123',
  'userId': 'usr-456',
  'data': {'cart': [...], 'preferences': {}},
  'expiresAt': 1750000000,
  'lastUpdatedRegion': 'us-east-1'
}

# Application reads from local region DynamoDB
# Writes replicate to all regions within ~1 second
# No sticky sessions needed on the ALB

Schreibkonflikte und ihre Auflösung

Die größte Herausforderung bei Active-Active mit Schreibzugriffen über mehrere Master hinweg sind Schreibkonflikte. Wenn zwei Benutzer in unterschiedlichen Regionen gleichzeitig denselben Datensatz aktualisieren, welche Aktualisierung gewinnt? DynamoDB Global Tables verwendet Last-Writer-Wins auf Grundlage des Zeitstempels des Schreibvorgangs. Dies funktioniert für die meisten Anwendungsfälle gut, kann aber bei konkurrierenden Aktualisierungen zu Datenverlust führen, etwa wenn zwei Benutzer gleichzeitig einen Zähler erhöhen. Entwerfen Sie Ihr Datenmodell so, dass gleichzeitige Schreibzugriffe verschiedener Regionen auf dasselbe Element vermieden werden – beispielsweise durch bedingte Schreibvorgänge oder indem Sie die Datenhoheit nach Regionen aufteilen.

# Avoid conflicts with conditional writes
aws dynamodb update-item \
  --table-name UserProfiles \
  --key '{"userId":{"S":"usr-123"}}' \
  --update-expression 'SET profileVersion = profileVersion + :inc, username = :name' \
  --condition-expression 'profileVersion = :expectedVersion' \
  --expression-attribute-values '{
    ":inc":{"N":"1"},
    ":name":{"S":"newname"},
    ":expectedVersion":{"N":"5"}
  }'
# If another region already updated version, this fails gracefully

S3-Replikation in Active-Active

Verwenden Sie für Objektspeicher in Active-Active S3 Cross-Region Replication mit bidirektionaler Replikation (verfügbar für Buckets mit aktivierter Versionierung). Anders als bei einer unidirektionalen CRR hält die bidirektionale Replikation die Buckets beider Regionen synchron: In einer Region geschriebene Objekte werden automatisch in die andere Region repliziert. Dies ist entscheidend für Anwendungen, die von Benutzern hochgeladene Dateien in den S3-Bucket ihrer lokalen Region schreiben, aber weltweit auf diese Dateien zugreifen müssen. Aktivieren Sie S3 Replication Time Control (RTC), um zu garantieren, dass 99,99 % der Objekte innerhalb von 15 Minuten repliziert werden.

# Bidirectional S3 replication
# Bucket A (us-east-1) replicates to Bucket B (eu-west-1)
# Bucket B (eu-west-1) replicates to Bucket A (us-east-1)

# Enable S3 RTC for guaranteed replication time
aws s3api put-bucket-replication \
  --bucket us-east-1-uploads \
  --replication-configuration '{
    "Rules": [{
      "Status": "Enabled",
      "ReplicationTime": {"Status": "Enabled", "Time": {"Minutes": 15}},
      "Metrics": {"Status": "Enabled", "EventThreshold": {"Minutes": 15}},
      "Destination": {"Bucket": "arn:aws:s3:::eu-west-1-uploads"}
    }]
  }'

CloudFront mit Ursprüngen in mehreren Regionen

Verwenden Sie CloudFront mit Origin Groups, um ein Active-Active-CDN mit automatischem Failover einzurichten. Konfigurieren Sie einen primären Origin (ALB in us-east-1) und einen sekundären Origin (ALB in eu-west-1). CloudFront führt automatisch ein Failover zum sekundären Origin durch, wenn der primäre Origin 5xx-Fehler zurückgibt. Für statische Assets, die aus S3 bereitgestellt werden, konfigurieren Sie Origin Groups mit S3-Buckets in mehreren Regionen und bidirektionaler Replikation. Dadurch wird eine zusätzliche Resilienzebene auf CDN-Ebene über Ihrem Active-Active-Routing mit Route 53 geschaffen.

# CloudFront origin group for multi-region failover
aws cloudfront create-distribution \
  --distribution-config '{
    "Origins": {
      "Quantity": 2,
      "Items": [
        {"Id": "us-east-1", "DomainName": "alb-us-east-1.amazonaws.com"},
        {"Id": "eu-west-1", "DomainName": "alb-eu-west-1.amazonaws.com"}
      ]
    },
    "OriginGroups": {
      "Items": [{
        "Id": "multi-region-group",
        "FailoverCriteria": {"StatusCodes": {"Items": [500,502,503,504]}},
        "Members": {"Items": [{"OriginId": "us-east-1"},{"OriginId": "eu-west-1"}]}
      }]
    }
  }'

Überwachung des Active-Active-Zustands

Active-Active-Architekturen erfordern eine robuste Überwachung, um sicherzustellen, dass beide Regionen fehlerfrei sind und der Traffic erwartungsgemäß verteilt wird. Wichtige Metriken sind: Route 53 HealthCheckPercentageHealthy pro Region, DynamoDB ReplicationLatency für die Verzögerung von Global Tables, ALB RequestCount pro Region zur Überprüfung der Traffic-Verteilung sowie CloudWatch-Dashboards über Konten und Regionen hinweg für eine einheitliche Übersicht. Richten Sie Alarme ein, wenn die Replikationsverzögerung Ihren RPO-Schwellenwert überschreitet oder die Traffic-Verteilung stark unausgeglichen wird.

# CloudWatch alarm for DynamoDB Global Table replication lag
aws cloudwatch put-metric-alarm \
  --alarm-name 'GlobalTable-ReplicationLag-eu-west-1' \
  --metric-name ReplicationLatency \
  --namespace AWS/DynamoDB \
  --dimensions Name=TableName,Value=UserSessions Name=ReceivingRegion,Value=eu-west-1 \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 5000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-alerts

Wann Active-Active die richtige Wahl ist

Active-Active ist geeignet, wenn: Benutzer weltweit verteilt sind und die Latenz zu einer einzelnen Region nicht akzeptabel ist. Das RTO nahezu null betragen muss – das Unternehmen kann nicht einmal wenige Minuten Ausfallzeit tolerieren. Ein hoher Schreibdurchsatz erfordert, Schreibvorgänge auf mehrere Regionen zu verteilen. Regulatorische Anforderungen die Verarbeitung von Daten im jeweiligen Land vorschreiben. Die Kosten sind deutlich höher als bei anderen DR-Stufen. Wählen Sie Active-Active daher nur, wenn die geschäftlichen Anforderungen und die Wirtschaftlichkeit dies eindeutig rechtfertigen. Für viele Workloads ist Warm Standby ausreichend und wesentlich günstiger.

# Active-Active justification checklist:
# [ ] Users in 2+ continents with latency SLAs
# [ ] RTO requirement < 5 minutes
# [ ] Revenue impact of downtime justifies 2x+ cost
# [ ] Data must remain within specific regions (regulations)
# [ ] Write throughput exceeds single-region capacity

# If fewer than 2-3 boxes checked:
# Consider Warm Standby instead (lower cost, adequate RTO)

Kurze Überprüfung

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

Zusammenfassung der Lektion

In dieser Lektion haben Sie gelernt: DynamoDB Global Tables ermöglicht Schreibzugriffe mit mehreren Mastern über Regionen hinweg und damit echtes Active-Active, das latenzbasierte Routing von Route 53 mit Health Checks leitet Benutzer zur nächstgelegenen gesunden Region und die Sitzungsverwaltung muss in Active-Active zustandslos sein oder global replizierten Speicher verwenden. Active-Active bietet ein nahezu null betragendes RTO und RPO, ist jedoch deutlich teurer. Als Nächstes untersuchen wir die Säulen Operational Excellence und Security des Well-Architected Frameworks.

Häufig gestellte Fragen

Ist die Lektion „Multi-Site Active-Active mit Global Tables und Route 53“ kostenlos?

Ja — der vollständige Text von „Multi-Site Active-Active mit Global Tables und Route 53“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Multi-Site Active-Active mit Global Tables und Route 53“?

Betreiben Sie mit DynamoDB Global Tables, Aurora Global Database und dem Latenz-Routing von Route 53 gleichzeitig die volle Produktionskapazität in zwei oder mehr Regionen. Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?

Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Multi-Site Active-Active mit Global Tables und Route 53“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?

Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. RTO, RPO und DR-Stufen
  2. Backup und Wiederherstellung
  3. Pilot Light und Warm Standby
  4. Multi-Site Active-Active mit Global Tables und Route 53
← Zurück zu Cloud & IT Cert Prep