Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Eine regionsübergreifende Aktiv-Aktiv-Architektur auf AWS ist ein verteiltes Cloud-Design, bei dem zwei oder mehr AWS-Regionen gleichzeitig Live-Produktionsverkehr verarbeiten. Gestützt wird dies durch eine kontinuierliche regionsübergreifende Replikation und automatisiertes globales Verkehrsrouting.
Wenn eine Region Störungen erleidet, bedienen die übrigen Regionen die Nutzer ohne Umschaltverzögerung weiter. Die verbleibenden Regionen sind dimensioniert, um die gesamte Anwendungsauslastung zu übernehmen und so die Geschäftskontinuität bei Ausfällen zu gewährleisten. Nutzer werden per latenzbasiertem Routing von Route 53 oder Global Accelerator an die nächstgelegene Region geleitet – dies minimiert die Latenz und sorgt für eine schnellere Nutzungserfahrung.
Dieser Leitfaden zeigt Ihnen die Einrichtung der AWS-Regionen. Sie lernen die durchgängige Bereitstellung, das Design der Datenschicht, Konfliktauflösung, Monitoring sowie die Vermeidung kostspieliger Fehler kennen.
Eine regionsübergreifende AWS-Architektur verursacht durch die Datenreplikation Kosten, die das Zwei- bis Dreifache einer Ein-Region-Lösung betragen können. Bevor Sie mit der Umsetzung beginnen, prüfen Sie anhand folgender Szenarien, ob Sie diese Architektur tatsächlich benötigen:
Die Infrastruktur ist einfach einzurichten: AWS stellt Route 53, Global Accelerator und CloudFront direkt zur Verfügung. Bei einer regionsübergreifenden Aktiv-Aktiv-Betriebsweise müssen Sie sich jedoch direkt mit dem CAP-Theorem auseinandersetzen. Bei Netzwerkunterbrechungen zwischen Regionen müssen Sie eine der beiden Prioritäten wählen:
Folgen Sie nun den nachfolgenden Schritten, um eine regionsübergreifende Aktiv-Aktiv-Architektur auf AWS einzurichten.
Nutzer müssen zur nächstgelegenen fehlerfreien Region gelangen. AWS bietet drei sich ergänzende Verfahren an.
► DNS-basiertes Routing mit Amazon Route 53
Route 53 dient als zentraler Zugangspunkt. Nutzen Sie das latenzbasierte Routing, um Nutzer an die nächste Region zu leiten. Jeder regionale Endpunkt erhält eine Gesundheitsprüfung; bei einem Ausfall einer Region leitet Route 53 automatisch keinen Verkehr mehr dorthin.
Wichtige Konfigurationsdetails:
1. Erstellen Sie eine Gesundheitsprüfung für jeden regionalen ALB mit einem Prüfintervall von 10 Sekunden und einem Ausfallschwellenwert von 2
2. Setzen Sie die DNS-TTL auf einen niedrigen Wert (60 Sekunden), um schnellere Umschaltungen zu ermöglichen.
3. Aktivieren Sie EvaluateTargetHealth: true, damit Route 53 den Gesundheitsstatus des ALB berücksichtigt
# Erstellen einer Gesundheitsprüfung für einen regionalen ALB
aws route53 create-health-check \
--caller-reference "us-east-1-health-$(date +%s)" \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "us-east-1-alb.example.com",
"Port": 443,
"ResourcePath": "/health",
"RequestInterval": 10,
"FailureThreshold": 2
}'
► Verkehrsbeschleunigung mit AWS Global Accelerator
Global Accelerator stellt statische Anycast-IP-Adressen bereit, die den Verkehr an den nächstgelegenen funktionsfähigen regionalen Endpunkt leiten. Im Gegensatz zum DNS-basierten Routing arbeitet Global Accelerator auf Netzwerkebene und überträgt den Verkehr über das private AWS-Backbone. Dadurch sinkt die Latenz bei TCP/UDP-Verkehr um bis zu 60 % im Vergleich zur Übertragung über das öffentliche Internet.
Jeder Listener kann mehrere Endpunktgruppen verwalten (eine pro Region). Global Accelerator verteilt den Verkehr an die nächste intakte Gruppe. Mit Traffic Dials steuern Sie den Anteil des Verkehrs pro Region – praktisch für graduelle Umschaltungen oder Canary-Bereitstellungen.
► Edge-Caching mit Amazon CloudFront
Für inhaltslastige Anwendungen speichert CloudFront statische Assets an Edge-Standorten weltweit. Das entlastet die Ursprungsserver und verbessert die Nutzungserfahrung. Kombinieren Sie CloudFront mit dem latenzbasierten Routing von Route 53 für maximale Leistung.
Sie benötigen Datenspeicher, die regionsübergreifende Schreibvorgänge mit akzeptablen Konsistenzgarantien verarbeiten. Hier finden Sie fünf Lösungsoptionen:
► Option 1: DynamoDB Global Tables (echte Multi-Master-Betriebsweise)
DynamoDB Global Tables bieten eine vollständig verwaltete multiaktive Replikation über mehrere AWS-Regionen. Sie können in jede Replikat-Tabelle schreiben, Änderungen werden automatisch an alle anderen Regionen übertragen. Im Hintergrund nutzen Global Tables DynamoDB Streams zur regionsübergreifenden Synchronisation.
Zehntausende Kunden setzen DynamoDB Global Tables mit eventualer Konsistenz erfolgreich ein. Kritische Anwendungen wie Zahlungssysteme und Finanzdienstleistungen erfordern jedoch höhere Anforderungen – für diese Systeme ist ein RPO von Null bei seltenen regionweiten Ausfällen erforderlich.
Multi-Region Strong Consistency (MRSC): Im Juni 2025 wurde MRSC für DynamoDB Global Tables eingeführt. Es ermöglicht ein RPO von Null für hochverfügbare regionsübergreifende Anwendungen. MRSC repliziert Ihre DynamoDB-Tabellen automatisch in ausgewählte AWS-Regionen und liefert schnelle, stark konsistente Lese- und Schreibzugriffe.
Verfügbarkeit von MRSC nach Regionen: MRSC steht in folgenden AWS-Regionen zur Verfügung: US East (N. Virginia, Ohio), US West (Oregon), Europa (Irland, London, Paris, Frankfurt) sowie Asien-Pazifik (Tokio, Seoul, Osaka).
Architekturanforderungen für MRSC: Für die Aufrechterhaltung eines Quorums sind drei AWS-Regionen erforderlich. Es gibt zwei Konfigurationsmöglichkeiten:
(1) Drei vollständige Tabellenreplikate
(2) Zwei Replikate plus eine Witness-Region
Die Witness-Region speichert nur replizierte Änderungsdaten, keine vollständige Tabellenkopie. Dadurch wird die erforderliche Verfügbarkeit ohne vollständige Speicherkosten sichergestellt.
Konfliktauflösung: Global Tables mit eventualer Konsistenz verwenden das Last-Writer-Wins-Verfahren anhand von Zeitstempeln. Bei MRSC entfallen Schreibkonflikte vollständig durch starke Konsistenz.
Kosten: MRSC Global Tables werden nach den üblichen Preisen für Global Tables abgerechnet. Für moderate Workloads belaufen sich die Kosten für den Global-Tables-Anteil einer Aktiv-Aktiv-Umgebung auf etwa 18 US-Dollar pro Monat.
► Option 2: Aurora Global Database (für relationale Workloads)
Eine Aurora Global Database repliziert einen Aurora-Cluster auf bis zu sechs AWS-Regionen. Eine Region fungiert als primäre Instanz (erlaubt Lese- und Schreibzugriffe), sekundäre Regionen dienen nur zum Lesen.
Der Nachteil: Aurora Global Database unterstützt keine mehreren Schreibknoten. Sämtliche Schreibvorgänge müssen an die primäre Region gesendet werden. Für eine echte Aktiv-Aktiv-Betriebsweise mit Schreibzugriffen aus allen Regionen ist eine Weiterleitung von Schreibanfragen aus sekundären Regionen zur Primärregion erforderlich – dies erhöht die Latenz bei Schreibvorgängen, die weit von der Primärregion initiiert werden.
Replikationsverzögerung: Die regionsübergreifende Replikationsverzögerung bei Aurora Global Database liegt üblicherweise unter einer Sekunde. Daher eignet sich die Lösung für leselastige Anwendungen, bei denen Nutzer aus verschiedenen Regionen schnellen lokalen Datenzugriff benötigen.
Kosten: Der Overhead der Replikation bei Aurora Global Database verursacht für mittelgroße Anwendungen monatliche Kosten von etwa 85 bis 100 US-Dollar.
► Option 3: Aurora DSQL (echte Aktiv-Aktiv-SQL-Datenbank)
Amazon Aurora DSQL ist eine serverlose verteilte SQL-Datenbank (PostgreSQL-kompatibel) mit nahezu unbegrenzter Skalierbarkeit, maximaler Verfügbarkeit und keiner Infrastrukturverwaltung. Wichtige Merkmale:
Wie Aurora DSQL regionsübergreifende starke Konsistenz erreicht: Regionsübergreifende Aurora-DSQL-Cluster nutzen synchrone regionsübergreifende Replikation, um starke Konsistenz zwischen allen Regionen (und der Witness-Region) aufrechtzuerhalten. DSQL akzeptiert Lese- und Schreibanfragen an jedem regionalen Endpunkt. Dank der starken Konsistenz von Aurora DSQL sieht ein Leser in Region A sofort alle bestätigten Schreibvorgänge aus Region B und umgekehrt.
Der entscheidende Vorteil: Der Anwendungsstack muss nicht wissen, dass er in einer regionsübergreifenden Aktiv-Aktiv-Konfiguration läuft. Die Anwendung benötigt keine regionsübergreifende Koordination oder Nachrichtenverarbeitung – diese Aufgabe übernimmt DSQL vollständig. Dadurch vereinfacht sich das Anwendungsdesign erheblich.
Verfügbarkeits-SLA: 99,99 % Verfügbarkeit innerhalb einer einzelnen Region; 99,999 % bei regionsübergreifender Betriebsweise.
Endpunkt-Routing für regionsübergreifendes DSQL: Anwendungen mit regionsübergreifenden Aurora-DSQL-Clustern sollten eine DNS-basierte Routing-Lösung wie Route 53 einsetzen, um den Verkehr automatisch zwischen Regionen umzuleiten. Best Practices empfehlen die Implementierung von routing-spezifischer Logik auf Anwendungsebene für eine ganzheitliche Verwaltung von regionalen Ausfallumschaltungen.
► Option 4: S3 Cross-Region Replication (für Objektspeicher)
Für Nutzer-Uploads und statische Assets aktivieren Sie die S3 Cross-Region Replication (CRR). Jedes Objekt, das in den Quell-Bucket hochgeladen wird, wird automatisch in Ziel-Buckets anderer Regionen repliziert. Nutzen Sie S3 Multi-Region Access Points (MRAPs), um den Zugriff auf replizierte Daten über alle Regionen hinweg zu vereinfachen.
► Option 5: ElastiCache (Strategien zur Cache-Ungültigmachung)
Jede Region betreibt einen eigenen ElastiCache-Cluster. Die Herausforderung besteht in der regionsübergreifenden Koordination der Cache-Ungültigmachung: Wenn sich Daten in einer Region ändern, müssen die entsprechenden Cache-Einträge in allen anderen Regionen ungültig gesetzt werden. Gängige Lösungsansätze:
Vergleichstabelle der Datenschicht-Lösungen
|
Dienst |
Aktiv-Aktiv-Schreibzugriffe |
Konsistenzmodell |
RPO |
Verfügbarkeits-SLA |
Einsatzzweck |
|
DynamoDB Global Tables (MRSC) |
Ja |
Stark |
Null |
99,999 % |
NoSQL, Schlüssel-Wert-Workloads, Anforderung RPO=0 |
|
Aurora Global Database |
Nein (nur Schreibweiterleitung) |
Stark |
< 1 Sekunde |
99,99 % |
Relationale Daten, leselastige Anwendungen |
|
Aurora DSQL |
Ja |
Stark (ACID-konform) |
Null |
99,999 % |
Relationale Daten mit regionsübergreifenden Schreibvorgängen |
|
S3 CRR |
Nicht zutreffend |
Eventual |
Minuten bis Stunden |
99,99 % |
Objektspeicher, Nutzer-Uploads |
Bereitstellen Sie in jeder Region die gleiche Infrastruktur mithilfe von CloudFormation oder Terraform. Jede Region muss in der Lage sein, die gesamte globale Anwendungsauslastung bei Ausfallumschaltungen zu übernehmen.
# CloudFormation-Vorlage (für alle Regionen bereitstellen)
AWSTemplateFormatVersion: '2010-09-09'
Description: Aktiv-Aktiv-Anwendungs-Stack
Parameters:
Region: {Type: String, AllowedValues: [us-east-1, eu-west-1]}
Resources:
AppAutoScalingGroup:
Type: AWS::AutoScaling::AutoScalingGroup
Properties:
MinSize: 2, MaxSize:10, DesiredCapacity:3
VPCZoneIdentifier: [!Ref PrivateSubnet1, !Ref PrivateSubnet2]
LaunchTemplate: {LaunchTemplateId: !Ref AppLaunchTemplate, Version: !GetAtt AppLaunchTemplate.LatestVersionNumber}
TargetGroupARNs: [!Ref AppTargetGroup]
AppLaunchTemplate:
Type: AWS::EC2::LaunchTemplate
Properties:
LaunchTemplateData:
ImageId: !FindInMap [RegionMap, !Ref "AWS::Region", AMI]
InstanceType: c5.xlarge
UserData:
Fn::Base64: !Sub |
#!/bin/bash
aws s3 cp s3://deploy-bucket/app-latest.tar.gz /opt/app/
cd /opt/app && tar xzf app-latest.tar.gz
export AWS_REGION=${AWS::Region}
export APP_ROLE=active
systemctl start myapp
Nutzer können zwischen Anfragen die Region wechseln – Sitzungen müssen global abrufbar sein. Nutzen Sie DynamoDB Global Tables mit einer TTL von 24 Stunden.
import boto3, uuid, time
dynamodb = boto3.resource('dynamodb')
def create_session(user_id):
session_id = str(uuid.uuid4())
sessions_table.put_item(Item={
'session_id': session_id, 'user_id': user_id,
'created_at': int(time.time()), 'ttl': int(time.time()) + 86400
})
return session_id
def get_session(session_id):
response = sessions_table.get_item(Key={'session_id': session_id}, ConsistentRead=False)
return response.get('Item')
Gleichzeitige Schreibvorgänge aus verschiedenen Regionen können Konflikte verursachen. Nutzen Sie eines dieser praxisbewährten Muster:
1. Last-Writer-Wins: Standardverfahren bei DynamoDB Global Tables
2. Regionenaffinität: Jedem Nutzer wird eine Heimatregion für alle Schreibvorgänge zugewiesen; Lesevorgänge sind aus jeder Region möglich
3. CRDTs: Konfliktfreie replizierte Datentypen für saubere Datenzusammenführungen
AWS-eigene Dienste wie DynamoDB Global Tables und Aurora DSQL bieten hervorragende Aktiv-Aktiv-Funktionalitäten innerhalb des AWS-Ökosystems. Viele Unternehmen stoßen jedoch auf Szenarien, bei denen AWS-native Lösungen allein nicht alle Anforderungen erfüllen.
Wenn Sie eine einfachere Betriebsweise wünschen oder eine heterogene Datenbankreplikation benötigen, bietet i2Stream von Info2Soft eine überzeugende Alternative.
i2Stream ist eine unternehmensgerechte Datenbankreplikationssoftware für Echtzeit-Datensynchronisation, Notfallwiederherstellung, Migration und Integration – sowohl für homogene als auch heterogene Datenbanken. Im Gegensatz zu AWS-eigenen Diensten, die hauptsächlich innerhalb von AWS funktionieren, ist i2Stream für vielfältige Umgebungen konzipiert: On-Premises, AWS sowie weitere Cloud-Anbieter.
Kernfunktionen von i2Stream:
Die regionsübergreifende Aktiv-Aktiv-Architektur auf AWS bietet das höchste Verfügbarkeitsniveau von AWS. Nutzen Sie DynamoDB Global Tables für Schlüssel-Wert-Workloads oder Aurora Global Database für relationale Daten. Setzen Sie Route 53 für latenzarmes Routing ein, stellen Sie identische regionale Infrastruktur-Stacks per IaC bereit, gestalten Sie die Anwendung zustandslos und implementieren Sie robuste Verfahren zur Konfliktauflösung.
Alternativ können Sie i2Stream von Info2Soft für den Aufbau einer Aktiv-Aktiv-Architektur wählen. Es vereinfacht die regionsübergreifende Datenbankreplikation erheblich und ermöglicht dank heterogener Replikation die Datensynchronisation zwischen unterschiedlichen Datenbankplattformen.
· Unternehmenskunden und Mittelstand weltweit
· Unser Support-Team unterstützt Sie während der gesamten Testphase
· Starten Sie eine 60-tägige Testversion oder sehen Sie sich eine Demo an, um zu erfahren, wie Info2Soft Unternehmensdaten schützt.
