Szenarien für resiliente und hochverfügbare Architekturen

Szenario: Ein Unternehmen betreibt eine zweistufige Webanwendung (ALB → EC2 → RDS) und möchte innerhalb der AWS-Region jeden Single Point of Failure beseitigen. Lösung: Stellen Sie EC2-Instances in einer Auto Scaling Group bereit, die sich über mindestens 2 Availability Zones erstreckt, und platzieren Sie diese hinter einem ALB (der grundsätzlich mehrere Availability Zones nutzt). Aktivieren Sie RDS Multi-AZ für die synchrone Replikation auf einen Standby. Konfigurieren Sie Health Checks auf dem ALB, damit der Datenverkehr automatisch von fehlerhaften Instances weggeleitet wird. Bei dieser Architektur führt der Ausfall einer einzelnen AZ auf jeder Ebene zu einem automatischen Failover.

Szenario: Die RDS-Instance einer E-Commerce-Anwendung stößt während der Spitzenzeiten an CPU-Grenzen, weil das Business-Intelligence-Team leseintensive Analyseabfragen ausführt. Lösung: Erstellen Sie RDS Read Replicas und leiten Sie BI-Abfragen an den Replica-Endpunkt weiter. Read Replicas verwenden eine asynchrone Replikation – eine geringe Verzögerung ist für Analysen akzeptabel. Dadurch wird der Leseverkehr von der primären RDS-Instance ausgelagert, die für Schreibvorgänge und Lesezugriffe der Anwendung reserviert bleibt. Bei extrem leseintensiven Workloads können Sie vor RDS zusätzlich eine ElastiCache-Ebene für häufig abgerufene Daten einsetzen.

Szenario: Eine zustandslose API läuft auf EC2 hinter einem ALB. Während der Geschäftszeiten steigt die CPU-Auslastung auf 90 %, nachts fällt sie nahezu auf null. Das Unternehmen möchte die Flotte automatisch skalieren. Lösung: Konfigurieren Sie eine Auto Scaling Group mit einer Target-Tracking-Skalierungsrichtlinie, die eine durchschnittliche CPU-Auslastung von 60 % anstrebt. Die ASG fügt automatisch Instances hinzu, wenn die CPU-Auslastung 60 % überschreitet, und entfernt Instances, wenn sie unter den Zielwert fällt. Fügen Sie eine geplante Skalierungsaktion hinzu, um die Mindestkapazität vor Beginn der Geschäftszeiten vorab bereitzustellen und dadurch Verzögerungen beim morgendlichen Verkehrsschub zu vermeiden.

Szenario: Ein Unternehmen betreibt eine primäre Webanwendung in us-east-1 und möchte bei einer Störung auf eine statische, in S3 gehostete Wartungsseite in us-west-2 umschalten. Lösung: Erstellen Sie einen Route-53-Health-Check, der den primären ALB-Endpunkt überwacht. Erstellen Sie zwei Route-53-Datensätze mit einer Failover-Routing-Richtlinie: einen primären Datensatz, der auf den ALB verweist und mit dem Health Check verknüpft ist, sowie einen sekundären Datensatz, der auf die statische S3-Website verweist. Wenn der Health Check fehlschlägt, liefert Route 53 automatisch die DNS-Antwort des sekundären Datensatzes aus.

Szenario: Ein Backend zur Bestellverarbeitung schreibt in eine Datenbank. Während Wartungsfenstern ist die Datenbank jedoch gelegentlich nicht verfügbar, wodurch Bestellungen verloren gehen. Lösung: Platzieren Sie eine SQS-Warteschlange zwischen dem Frontend, das Bestellungen annimmt, und dem Backend, das sie verarbeitet. Bestellungen werden sofort in die Warteschlange gestellt, sodass der Kunde unmittelbar eine Bestätigung erhält. Hintergrund-Worker lesen die Bestellungen aus der Warteschlange und verarbeiten sie, sobald die Datenbank verfügbar ist. Während der Wartung werden Bestellungen daher aufgereiht, statt verworfen zu werden – das sorgt durch asynchrone Entkopplung für Ausfallsicherheit.

Szenario: Ein Unternehmen benötigt für ein mittleres Budget eine Disaster-Recovery-Lösung mit einem RPO von 1 Stunde und einem RTO von 4 Stunden. Lösung: Implementieren Sie eine Pilot-Light-DR-Strategie. Halten Sie die zentrale Datenbank mithilfe einer RDS Cross-Region Read Replica in der DR-Region repliziert. Die Anwendungsserver laufen während des Normalbetriebs nicht in der DR-Region – nur der minimale „Kern“ (die Datenbank) bleibt aktiv. Im Katastrophenfall stufen Sie die Read Replica zu einer eigenständigen Datenbank hoch und starten die Anwendungsserver aus vorbereiteten AMIs mithilfe von CloudFormation. Das RTO liegt bei Stunden statt Minuten, da die Server erst gestartet werden müssen.

Szenario: Nachrichten in einer SQS-Warteschlange können aufgrund eines Fehlers in der Consumer-Lambda-Funktion wiederholt nicht verarbeitet werden. Die Nachrichten erscheinen immer wieder und blockieren die Warteschlange. Lösung: Konfigurieren Sie für die Hauptwarteschlange eine Dead-Letter Queue (DLQ). Nachdem die Verarbeitung einer Nachricht eine konfigurierbare Anzahl von Malen fehlgeschlagen ist (maxReceiveCount), verschiebt SQS sie automatisch in die DLQ, statt sie unbegrenzt erneut auszuliefern. Dadurch wird die Hauptwarteschlange für fehlerfreie Nachrichten freigegeben. Richten Sie einen CloudWatch-Alarm für die DLQ-Metrik ApproximateNumberOfMessagesVisible ein, um das Engineering-Team zu benachrichtigen, sobald sich Nachrichten in der DLQ ansammeln.

Szenario: Ein Unternehmen ist in den USA und Europa tätig. Nutzer in Europa erleben eine hohe Latenz bei Datenbanklesevorgängen, da sich RDS in us-east-1 befindet. Lösung: Verwenden Sie Amazon Aurora Global Database. Der primäre Cluster befindet sich in us-east-1; ein sekundärer schreibgeschützter Cluster wird in eu-west-1 hinzugefügt. Aurora repliziert die Daten mithilfe der Replikation auf Speicherebene mit einer typischen Latenz von unter 1 Sekunde in die sekundäre Region. Europäische Nutzer lesen die Daten aus dem sekundären Cluster in eu-west-1. Bei einer regionalen Katastrophe kann der sekundäre Cluster in weniger als 1 Minute zum primären Cluster hochgestuft werden (das beste RTO aller AWS-Datenbankoptionen über mehrere Regionen hinweg).

Szenario: Ein containerisierter API-Service, der auf ECS Fargate läuft, muss anhand der CPU-Auslastung skalieren und Ausfälle von Availability Zones überstehen. Lösung: Registrieren Sie den ECS-Service bei einer Application-Load-Balancer-Target-Gruppe, damit der Datenverkehr auf die laufenden Tasks verteilt wird. Platzieren Sie die Tasks über mehrere AZs, indem Sie in der Servicekonfiguration mehrere Subnetze angeben. Konfigurieren Sie ECS Service Auto Scaling mit einer Target-Tracking-Richtlinie für die CPU-Auslastung des ECS-Services, damit die Anzahl der Tasks automatisch nach oben und unten skaliert wird. Wenn eine AZ ausfällt, startet ECS die ausgefallenen Tasks in fehlerfreien AZs neu.

Szenario: Ein Unternehmen betreibt zwei EC2-Instances in unterschiedlichen AZs, die dieselbe Domain bedienen. Route 53 soll den Datenverkehr automatisch nicht mehr an eine fehlerhafte Instance senden. Lösung: Verwenden Sie Route-53-Weighted-Routing mit gleichen Gewichtungen (50/50) und verknüpfen Sie mit jedem Datensatz einen Endpunkt-Health-Check. Wenn Route 53 einen fehlerhaften Endpunkt erkennt, entfernt es den zugehörigen Datensatz aus den DNS-Antworten und leitet 100 % des Datenverkehrs an den fehlerfreien Endpunkt. Sobald sich die Instance erholt hat und die Health Checks wieder erfolgreich sind, verteilt Route 53 den Datenverkehr automatisch neu – manuelle DNS-Änderungen sind nicht erforderlich.

Szenario: Eine mobile Gaming-Anwendung benötigt für ihre Spielerdaten sowohl Lese- als auch Schreibzugriffe mit geringer Latenz aus us-east-1 und ap-southeast-1. Eine DynamoDB-Tabelle in nur einer Region verursacht für asiatische Nutzer eine hohe Latenz. Lösung: Aktivieren Sie DynamoDB Global Tables. Global Tables repliziert Daten automatisch über die angegebenen Regionen hinweg mithilfe der Multi-Master-Replikation – jede Region kann Schreibvorgänge annehmen. Asiatische Nutzer schreiben in das Replikat in ap-southeast-1 und lesen daraus mit lokaler Latenz (~5 ms). Global Tables löst Konflikte mithilfe einer „Last-Writer-Wins“-Strategie auf Grundlage von Zeitstempeln. Das RTO bei einem vollständigen regionalen Ausfall liegt nahezu bei null – der Datenverkehr wird einfach an die verbleibende Region weitergeleitet.

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

In dieser Lektion haben Sie Szenarien zu folgenden Themen bearbeitet: Multi-AZ-ASG und RDS für Hochverfügbarkeit innerhalb einer Region, Failover-Routing mit Route 53 für Disaster Recovery über mehrere Regionen hinweg, SQS-DLQ zur Isolierung fehlerhafter Nachrichten, ohne Warteschlangen zu blockieren sowie Aurora Global Database für Leseskalierung über mehrere Regionen und Failover mit einem RTO von unter einer Minute. Als Nächstes behandeln wir Szenarien für hochperformante und kostenoptimierte Architekturen.