Amazon SAP-C02: Resilienz, Disaster Recovery & Hochverfügbarkeit — Lernleitfaden

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Teil des AWS Solutions Architect Professional SAP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

RTO- und RPO-Planung: Toleranz quantifizieren und Architektur abbilden

RTO (Recovery Time Objective) und RPO (Recovery Point Objective) sind die treibenden Kräfte für jede Entscheidung zur Ausfallsicherheit, von der Dimensionierung der Rechenleistung bis zur Replikationstopologie. Beginnen Sie mit der Klassifizierung von Workloads nach ihren Geschäftsauswirkungen und den Kosten von Ausfallzeiten. Übersetzen Sie diese Prioritäten dann in messbare Ziele: RPOs im Millisekundenbereich erfordern synchrone Replikation oder speziell entwickelte globale Datenbanken, während RPOs im Minuten- bis Stundenbereich asynchrone Replikation, Snapshot-Zeitpläne oder gebündeltes Log-Shipping ermöglichen. Nutzen Sie AWS-Services, die auf diese Ziele abgestimmt sind: Amazon Aurora Multi‑AZ und Aurora Global Database für niedrige RTO/RPO bei hoher Skalierung, RDS Multi‑AZ für synchrone Hochverfügbarkeit in einer einzelnen Region, regionsübergreifende Lesereplikas für Wiederherstellung und Reporting und AWS Elastic Disaster Recovery (DRS) für die Replikation von On-Premises-Servern nahezu in Echtzeit mit minimalen Anwendungsänderungen. Eine häufige Falle ist, das Design nur für die durchschnittliche Last auszulegen anstatt für Wiederherstellungsvorgänge im Worst-Case-Szenario. Eine weitere ist die Annahme, dass Snapshots allein den RPO für transaktionale Systeme erfüllen, da Snapshots im Minutenabstand erstellt werden können und ihnen möglicherweise die Anwendungskonsistenz fehlt. Die Kompromisse bei der Entscheidungsfindung sind einfach: Synchrone Replikation erhöht die Kosten und die Schreiblatenz, senkt aber den RPO; asynchrone Replikation reduziert die Latenz und die Kosten, erhöht aber den potenziellen Datenverlust. Testen Sie den Plan mit Chaos-Tests, geplanten Failovern und Wiederherstellungsübungen, um die tatsächlichen RTO/RPO-Werte zu validieren und versteckte Abhängigkeiten wie externe Authentifizierung, DNS oder IP-Whitelists zu identifizieren.

Multi-AZ- und Multi-Region-Architekturen und Failover-Strategien

Multi-AZ-Architekturen schützen vor AZ-Ausfällen, indem sie redundante Rechen-, Netzwerk- und Speicherressourcen über mehrere Availability Zones verteilen. Multi-Region-Architekturen erweitern die Ausfallsicherheit auf Ausfälle auf Regionsebene, Naturkatastrophen oder große Netzwerkpartitionen. Wählen Sie ein Architekturmuster – Pilot Light, Warm Standby, Aktiv-Passiv oder Aktiv-Aktiv – basierend auf den Kosten und den Wiederherstellungsanforderungen. Pilot Light verwendet minimale Ressourcen in einer sekundären Region, um die Kosten zu minimieren, und skaliert im Falle eines Failovers hoch. Warm Standby hält herunterskalierte Dienste für eine schnellere Wiederherstellung am Laufen. Aktiv-Aktiv bedient den Datenverkehr in mehreren Regionen für den niedrigsten RTO, erfordert aber eine starke Datenreplikation und Konfliktlösung. Verwenden Sie Route 53 mit Zustandsprüfungen (Health Checks) und Failover-Routing, Amazon CloudFront oder Global Accelerator für das globale Traffic-Management und Datendienste wie DynamoDB Global Tables oder Aurora Global Database für die regionsübergreifende Replikation. Häufige Fallstricke sind das Vertrauen auf zu lange DNS-TTLs, die fehlende Validierung des Failovers von zustandsbehafteten Diensten (Session-Speicher, Caches) und die Vernachlässigung von Kosten für den regionsübergreifenden Datentransfer sowie von Compliance-Anforderungen. Wägen Sie die Komplexität und die Kosten einer Multi-Region-Bereitstellung gegen akzeptable Ausfallzeiten und Datenverluste ab. Im Zweifelsfall sollten Sie die Failover-Zeiten instrumentieren und modellieren, um den Business Case zu untermauern.

Resilienzmuster für Anwendungen: Zustandslosigkeit, Entkopplung und Zustandsverwaltung

Entwerfen Sie für den Fehlerfall (Design for Failure), indem Sie den an einzelne Rechenknoten gebundenen Zustand minimieren und Komponenten entkoppeln, damit Teilausfälle nicht kaskadieren. Zustandslose Anwendungsknoten hinter einem Application Load Balancer oder Network Load Balancer ermöglichen horizontale Skalierung und einen schnellen Austausch. Bevorzugen Sie für den Sitzungszustand (Session State) externe Speicher wie Amazon DynamoDB oder Amazon ElastiCache anstelle von Sticky Sessions. Verwenden Sie für Dateifreigaben (File Shares) Amazon S3, Amazon EFS oder FSx, je nach Protokoll- und Leistungsanforderungen. Asynchrone Muster, die Amazon SQS, SNS oder Kinesis verwenden, puffern Lastspitzen, ermöglichen Wiederholungsversuche (Retries), glätten den Gegendruck (Backpressure) und reduzieren synchrone Abhängigkeiten während eines Failovers. Implementieren Sie Circuit Breaker, Bulkheads und Exponential Backoff in Clients, um ausfallende Subsysteme zu isolieren. Eine häufige Falle für Architekten ist die Unterschätzung von Kaltstart- (Cold-Start) oder Hochskalierungszeiten (Scale-up) – Lambda-Gleichzeitigkeitslimits, Auto-Scaling-Cooldowns und Aufwärmstrategien (Warm-up) beeinflussen den RTO. Eine weitere ist, Caching als Dauerhaftigkeit (Durability) zu betrachten; Caches müssen wiederherstellbar sein. Die Abwägung zwischen Kosten und Ausfallsicherheit zeigt sich in der Pufferdimensionierung und Replikation: Eine höhere Ausfallsicherheit erfordert oft mehr reservierte Kapazität oder eine regionsübergreifende Replikation, was die Kosten erhöht. Wählen Sie die minimal erforderliche Redundanz, die RTO/RPO erfüllt, und stellen Sie gleichzeitig Beobachtbarkeit (Observability) und Automatisierung sicher, um Fehler zu erkennen und zu beheben.

Backups, Replikation, Governance und Betriebsbereitschaft

Backups sind eine Versicherung; die entscheidenden Aspekte sind Konsistenz, Sicherheit, Aufbewahrung und Wiederherstellbarkeit. Verwenden Sie AWS Backup für zentralisierte Backup-Richtlinien über EBS, RDS, DynamoDB, EFS und FSx hinweg und erzwingen Sie konto- und regionsübergreifende Backup-Kopien für geografische Ausfallsicherheit. Aktivieren Sie für Objektdaten die S3-Versionierung mit Lifecycle-Regeln und S3 Replication (CRR) für regionsübergreifende Dauerhaftigkeit. Stellen Sie anwendungskonsistente Snapshots für Datenbanken und Windows-Dateisysteme sicher, indem Sie datenbankeigene Backups, automatisierte RDS-Snapshots oder AWS DRS mit VSS-Unterstützung nutzen. Kontoübergreifende Replikation und das IAM-Prinzip der geringsten Rechte (Least Privilege) sind unerlässlich, um versehentliche Löschungen zu verhindern. Regelmäßige Wiederherstellungsübungen decken Probleme mit fehlenden IAM-Rollen, der Netzwerkkonfiguration (VPC-CIDR-Überschneidungen) oder externen Integrationen auf. Automatisieren Sie Runbooks mit Systems Manager Automation und kodifizieren Sie Failover-Prozeduren in CloudFormation oder Terraform, um manuelle Fehler zu reduzieren. Häufige Fallstricke sind das alleinige Verlassen auf Point-in-Time-Snapshots ohne Exportmöglichkeit, die Nichtverschlüsselung von Backups mit kundenseitig verwalteten Schlüsseln und die fehlende Überwachung des Erfolgs von Backup-Jobs. Wägen Sie Aufbewahrungs- und Speicherkosten gegen regulatorische Anforderungen ab; stufen Sie ältere Backups zur Kostenkontrolle nach S3 Glacier ab, während Sie aktuelle Backups für schnelle Wiederherstellungen schnell zugänglich halten.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Events Inc., ein globales Unternehmen für Live-Veranstaltungen, betreibt eine Ticketing-Anwendung in einer einzigen AWS-Region. Die Anwendung nutzt EC2 Auto Scaling-Gruppen hinter einem ALB, mit einem 3-Knoten-PostgreSQL-Cluster auf EC2 in einer AZ und nächtlichen EBS-Snapshots. Das Unternehmen muss die RTO auf unter 10 Minuten und die RPO auf unter 5 Minuten reduzieren und dabei den Betriebsaufwand und die Kosten minimieren.

Herausforderung: Erreichen Sie eine nahezu kontinuierliche Verfügbarkeit und einen geringen Datenverlust für die Datenbank über AZs/Regionen hinweg, mit vorhersagbarem Failover und minimalen Anwendungsänderungen.

Empfohlener Ansatz:

1. Konfigurieren Sie Amazon RDS for PostgreSQL mit einer Multi‑AZ-Bereitstellung oder migrieren Sie zu Amazon Aurora PostgreSQL mit Multi‑AZ und aktivieren Sie automatisierte, kontinuierliche Backups sowie schnelle Snapshot-Exporte; aktivieren Sie automatisierte Backups mit einem angemessenen Aufbewahrungszeitraum.
2. Fügen Sie eine regionsübergreifende Replikation mithilfe von Aurora Global Database (oder logischer/physischer RDS-Replikation auf eine Read Replica in einer sekundären Region) hinzu, um die geografischen RPO-Ziele zu erreichen. Konfigurieren Sie latenzbasiertes Routing mit Route 53 und Zustandsprüfungen (Health Checks), um ein kontrolliertes regionales Failover zu ermöglichen.
3. Ersetzen Sie die Single‑AZ EC2 PostgreSQL-Instanz durch einen Managed Service, um die Host-Wartung zu eliminieren. Überarbeiten Sie die Verbindungslogik der Anwendung, um Cluster-Endpunkte oder den RDS Proxy für Connection Pooling und eine schnellere Failover-Verarbeitung zu nutzen.
4. Implementieren Sie eine kontinuierliche Überprüfung der Replikation und die Automatisierung von Runbooks: geplante Failover-Übungen mit Systems Manager Automation und CloudFormation-Vorlagen zur schnellen Wiederherstellung von Ressourcen; instrumentieren Sie Metriken und führen Sie Alarme über CloudWatch und SNS aus.

Begründung: Die Verwendung von gemanagten Multi‑AZ-Datenbankdiensten und regionsübergreifender Replikation reduziert die Betriebskomplexität und erfüllt aggressive RTO/RPO-Ziele. Automatisierung und regelmäßige Übungen stellen sicher, dass der Plan in der Praxis funktioniert, während RDS/Aurora manuelle Failover-Schritte und die Failover-Zeit minimieren.

← Migration · Alle Domänen · Kostenoptimierung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →