Amazon DOP-C02: Hochverfügbarkeit, Resilienz und Notfallwiederherstellung — Lernleitfaden

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Überblick

Hochverfügbarkeit und Notfallwiederherstellung (Disaster Recovery) auf AWS konzentrieren sich auf die Reduzierung von Ausfallzeiten (RTO) und Datenverlust (RPO) bei Ausfällen von Komponenten, Availability Zones (AZ) oder ganzen Regionen. Multi-AZ-Designs fangen AZ-Ausfälle ohne Datenverlust und mit minimalen Servicebeeinträchtigungen ab; Multi-Region-Designs adressieren regionale Störungen und großflächige Ereignisse. Die Wahl zwischen Aktiv/Aktiv-, Aktiv/Passiv- (Warm Standby) und Pilot-Light-Strategien wird von den geschäftlichen RTO/RPO-Zielen, Konsistenzanforderungen und Kosten bestimmt. Das Erreichen dieser Ziele erfordert ein kohärentes Design über DNS-Routing, Compute-Elastizität, Lastverteilung, Datenbankreplikation/-Failover, durablen Objektspeicher mit Replikation/Versionierung, zentralisierte Backups und eine kontinuierliche Überprüfung der Resilienz durch Fehlerinjektion.

Architekturen für RTO/RPO und intelligentes Routing

Multi-AZ und Multi-Region:

Multi-AZ: Platzieren Sie redundante Instanzen über mindestens zwei Subnetze in verschiedenen AZs hinter einem Load Balancer. Verwenden Sie verwaltete Datenbanken mit synchroner Replikation (RDS Multi-AZ, Aurora Multi-AZ/Cluster). Der RPO liegt bei synchronem Speicher typischerweise bei null; die RTO-Ziele reichen von unter einer Minute (Aurora) bis zu einigen Minuten (RDS Single-Instance Multi-AZ Failover).
Multi-Region: Wählen Sie Aktiv/Aktiv für die niedrigste RTO mit regionaler Isolation und geringer Latenz oder Warm Standby/Pilot Light für kostenoptimiertes DR. Die Datenreplikation muss den RPO erfüllen: asynchrone DB-Replikate, Aurora Global Database (<1 s typischer RPO), DynamoDB Global Tables (Multi-Region, Multi-Aktiv) und S3 Cross-Region Replication (CRR) mit optionaler Replication Time Control (RTC) für SLA-gestützte Replikation.

Route 53 Routing-Richtlinien und Zustandsprüfungen:

Failover-Routing: Erstellen Sie zwei Einträge für denselben Namen: Primär und Sekundär. Verknüpfen Sie eine Zustandsprüfung mit dem primären Eintrag (oder verwenden Sie „Evaluate Target Health“ für Aliase zu ALB/NLB). Bei einem Ausfall wird der Datenverkehr auf den sekundären Eintrag umgeleitet. Halten Sie die TTL niedrig (z. B. 60 s), um Verzögerungen durch DNS-Caching zu reduzieren, und überwachen Sie den Status der Zustandsprüfung mit CloudWatch Alarms.
Latenzbasiertes Routing: Leitet Benutzer zu der Region mit der niedrigsten gemessenen Latenz. Verknüpfen Sie jeden Eintrag mit Zustandsprüfungen, um sicherzustellen, dass nur fehlerfreie Endpunkte Datenverkehr erhalten. Kombinieren Sie dies mit Multi-Region-Stacks und regionalen Datenspeichern, die je nach Anforderung Eventual oder Strong Consistency unterstützen.
Gewichtetes Routing: Teilen Sie den Datenverkehr prozentual auf, um Canary-Releases, A/B-Tests oder eine „schleichende“ DR-Bereitschaft (z. B. 1 % kontinuierlich an die sekundäre Umgebung) zu unterstützen. Kombinieren Sie dies mit Zustandsprüfungen, damit fehlerhafte Gewichtungen ausgeschlossen werden. Verwenden Sie schrittweise verschobene Gewichtungen, um den Datenverkehr während einer regionalen Evakuierung zu migrieren.
Zustandsprüfungen: Fragen Sie HTTP(S)/TCP-Endpunkte oder CloudWatch Alarms ab. Aktivieren Sie für ALB/NLB-Aliase „Evaluate Target Health“, um den Zustand der Zielgruppe zu übernehmen. Gestalten Sie Zustandsprüfungs-Endpunkte so, dass sie die tatsächliche Bereitschaft widerspiegeln (Abhängigkeiten erreichbar, Migrationen angewendet). Bei zustandsbehafteten Anwendungen sollten Prüfungen von Abhängigkeiten (Datenbank, Cache) einbezogen werden, um ein Routing zu teilweise fehlerhaften Instanzen zu vermeiden.

Resiliente Muster nach Zielsetzung:

Niedriger RPO, RTO unter einer Minute global: Aktiv/Aktiv mit latenzbasiertem Routing und Zustandsprüfungen von Route 53, regionallokale, zustandslose Rechenleistung, DynamoDB Global Tables oder Aurora Global Database, S3 CRR mit RTC für kritische Objekte.
Moderater RPO (≤15 Min.), RTO ≤4 Stunden: Warm Standby mit verkleinerter sekundärer Umgebung, asynchrones DB-Replikat (RDS Cross-Region Read Replica oder Aurora Global), Route 53 Failover-Routing, Runbooks oder Automatisierung zum Hochskalieren und Hochstufen beim Failover.
Kostenoptimiertes DR: Pilot Light nur für Kerndatendienste, Infrastructure-as-Code zur horizontalen Skalierung der Anwendungsschicht bei Aktivierung, RPO bestimmt durch die Replikationsfrequenz, RTO durch die Bereitstellungszeit und den Datenabgleich.

Elastic Load Balancing und Auto Scaling

Elastic Load Balancing:

Application Load Balancer (ALB): Schicht 7, Host-/Pfad-basiertes Routing, WebSocket/HTTP/2, integrierte WAF, Stickiness über Target-Group-Cookies und anfragebasierte Health Checks. Verwenden Sie zonenübergreifenden Lastausgleich (Cross-Zone Load Balancing) und eine Verzögerung bei der Deregistrierung (Connection Draining), um Ziele bei Scale-in-Vorgängen oder Deployments ordnungsgemäß zu leeren. Konfigurieren Sie Slow Start und Ausreißererkennung (Outlier Detection) für ein ungleichmäßiges Aufwärmen des Backends.
Network Load Balancer (NLB): Schicht 4, extrem niedrige Latenz, statische IPs/Elastic IPs, TLS-Pass-Through/Terminierung, behält die Quell-IP-Adresse bei und unterstützt langlebige Verbindungen. Einsatz für TCP/UDP-Protokolle, Workloads mit hohem Durchsatz oder wenn die Sichtbarkeit der Client-IP zwingend erforderlich ist. Health Checks sind je nach Konfiguration TCP/HTTP/HTTPS auf Schicht 4/7.
Connection Draining (Verzögerung bei der Deregistrierung): Legen Sie eine angemessene Verzögerung fest (z. B. 60–300 s), damit laufende Anfragen abgeschlossen werden können. Stellen Sie sicher, dass Deployment- und Auto-Scaling-Terminierungsereignisse diese Verzögerung berücksichtigen, um Benutzerunterbrechungen zu vermeiden.

Auto-Scaling-Gruppen:

Skalierungsrichtlinien:
- Zielverfolgungsskalierung (Target Tracking Scaling): Hält eine Metrik (CPUUtilization, ALB RequestCountPerTarget) auf einem Zielwert. Dies ist die einfachste und anpassungsfähigste Richtlinie für Web-/API-Flotten.
- Schrittweise Skalierung (Step Scaling): Skaliert in definierten Schritten, wenn Metriken Schwellenwerte überschreiten. Nützlich bei stoßweisem Datenverkehr mit vorhersagbaren Mustern.
- Geplante Skalierung (Scheduled Scaling): Vorskalieren für bekannte Ereignisse (Verkaufsaktionen, Produkteinführungen), um kalte Kapazität zu vermeiden.
- Prädiktive Skalierung (Predictive Scaling): Prognostiziert optional die Nachfrage mithilfe von ML für tägliche/wöchentliche Muster.
Lifecycle-Hooks: Launching:Wait und Terminating:Wait ermöglichen es Ihnen, die Bereitschaft und das Herunterfahren von Instanzen zu steuern. Verwenden Sie Hooks, um:
- Instanzen zu bootstrappen (SSM Automation, Abschluss von User Data, AMI-Hydration), bevor sie in Betrieb gehen.
- Protokolle und Artefakte vor der Terminierung für die Ursachenanalyse zu sammeln.
- Blue/Green- oder In-Place-Deployments zu koordinieren, die Bereitschaftssignale (z. B. cfn-signal) bestätigen müssen.
Warm Pools: Halten Sie Instanzen vorinitialisiert im Zustand „Stopped“ oder „Running“ an die ASG angehängt, um die Latenz beim Aufskalieren drastisch zu reduzieren. Warm Pools eignen sich gut für lange Bootstrap-Schritte (Installation großer Pakete, Modelldownloads). Konfigurieren Sie eine minimale aufgewärmte Kapazität und Wiederverwendungsrichtlinien. Kombinieren Sie dies mit dem Lifecycle-Hook Launching:Wait, um den Hook erst abzuschließen, wenn die App-Bereitschaftsprüfungen erfolgreich sind, was konsistente Umstellungszeiten gewährleistet.
Resilienzeinstellungen: Aktivieren Sie Capacity Rebalance für Spot, mehrere Instanztypen/-Zuweisungen, Health Checks, die an den Zustand der Zielgruppe gekoppelt sind, und Instance Refresh für sichere Rolling Updates mit Health Guardrails.

Resilienz der Datenschicht, Replikation und Backups

Relationale Datenbanken:

RDS Multi-AZ: Synchrone Replikation auf eine Standby-Instanz in einer anderen AZ; ein automatisches Failover aktualisiert den DNS-Endpunkt auf die Standby-Instanz. Dies schützt vor AZ- und Instanzausfällen mit einem RPO von ≈ 0 und einer RTO von typischerweise wenigen Minuten für Single-AZ-DB-Instanzen mit Multi-AZ-Standby. Der neuere Multi-AZ-DB-Cluster für MySQL/PostgreSQL bietet ein schnelleres Failover mit mehreren lesbaren Standby-Instanzen.
Lesereplikas (Read Replicas): Asynchrone Replikation zur Leseskalierung und für DR. Verwenden Sie für DR regionsübergreifende Lesereplikas; die Heraufstufung (Promotion) erfolgt manuell (oder automatisiert mit Runbooks/Serverless-Funktionen) und führt zu einem RPO > 0. Stellen Sie sicher, dass die Binlog- oder logische Replikation korrekt konfiguriert ist und der Replikationsverzug (Replication Lag) überwacht wird.

Chaos Engineering und AWS Fault Injection Simulator (FIS)

Chaos-Experimente validieren, dass HA- und DR-Mechanismen wie vorgesehen funktionieren. AWS FIS orchestriert kontrollierte Fehler mit Sicherheitsvorkehrungen (Guardrails):

Experimentvorlagen definieren Aktionen (z. B. das Stoppen oder Neustarten eines Prozentsatzes von EC2-Instanzen in einer ASG, das Injizieren von CPU- oder Speicherbelastung über SSM, das Hinzufügen von Netzwerklatenz/Paketverlust auf Instanzen, das Beenden von EKS-Pods, das Stoppen von ECS-Tasks, das Auslösen eines RDS/Aurora-Failovers) und Ziele (Ressourcen-Tags, ARNs).
Sicherheitskontrollen: Festlegen von CloudWatch-Alarmen als Abbruchbedingungen, Zeitlimits, Einschränkungen des „Blast Radius“ über Tags/Filter und Vorabprüfungen. Führen Sie die Experimente zuerst in Nicht-Produktionsumgebungen aus, dann in der Produktion mit strengen Sicherheitsvorkehrungen und nach Genehmigung durch die Fachabteilung.
Beobachtbarkeit (Observability): Instrumentieren Sie KPIs (Fehlerrate, Tail-Latenz, Warteschlangenalter, Replika-Lag) und überprüfen Sie automatisierte Reaktionen, einschließlich der Reaktionen von Auto Scaling, der Konvergenz des Zustands des Load Balancers, des Route 53-Failovers, der Heraufstufung der Datenbank (Promotion) und des Verhaltens von Circuit Breakern.
Kontinuierliche Resilienz: Integrieren Sie Experimente in Pipelines/Gamedays, um zu verhindern, dass Konfigurationsdrift die Resilienz untergräbt. Verwenden Sie Parameter Store oder AppConfig für Feature-Toggles und zur Koordination sicherer Rollouts.

Praktisches Problemszenario

Die Expedia Group betreibt eine globale API für die Reisesuche, die eine RTO von unter 60 Sekunden und eine RPO von nahezu Null für kritische Buchungsdaten gewährleisten muss, während gleichzeitig eine niedrige Latenz für Benutzer in Nordamerika und Europa aufrechterhalten wird. Das Team erlebt gelegentliche regionale „Brownouts“ und durch Deployments verursachte Instabilität. Zudem fordern Auditoren kontoübergreifende, unveränderliche Backups und dokumentierte DR-Übungen.

Schritt-für-Schritt-Ansatz:

Aufbau von Multi-Region-, Aktiv/Aktiv-Stacks

Stellen Sie zustandslose API-Stacks in us-east-1 und eu-west-1 über mehrere AZs hinweg hinter ALBs bereit. Verwenden Sie latenzbasiertes Routing von Route 53 mit Zustandsprüfungen (Health Checks) und „Evaluate Target Health“ bei Alias-Records. Dies sorgt für latenzoptimiertes Routing und eine automatische regionale Ausweichmöglichkeit, falls ein Endpunkt nicht fehlerfrei ist.

Globaler Datenspeicher mit niedriger RPO

Migrieren Sie Buchungs- und Sitzungsdaten zu Amazon Aurora Global Database (MySQL-kompatibel), wobei us-east-1 als primäre und eu-west-1 als sekundäre Region dient. Die typische RPO von <1 s und RTO von <1 min erfüllen die Vorgaben für Ausfallzeiten. Verwenden Sie die Cluster- und Reader-Endpunkte in der Anwendungskonfiguration mit Wiederholungsversuchen/Backoff, um Failover zu tolerieren.

Resiliente Skalierung und reibungslose Übergänge (Graceful Transitions)

Konfigurieren Sie Auto Scaling Target Tracking für ALB RequestCountPerTarget mit einer Mindestkapazität in beiden Regionen. Fügen Sie Warm Pools hinzu, die so dimensioniert sind, dass sie den 10-fachen Traffic-Anstieg bei Großereignissen abfangen können, sowie Lifecycle-Hooks vom Typ „Launching:Wait“, um die Registrierung zu verzögern, bis die Bereitschaftsprüfungen der Anwendung erfolgreich sind. Aktivieren Sie eine Deregistrierungsverzögerung (Deregistration Delay) des ALB von 120 Sekunden, um laufende Anfragen bei Scale-In-Vorgängen und Deployments zu erhalten.

Dauerhaftes Objekt-DR

Aktivieren Sie S3 Versioning und CRR mit RTC für Reisedokumente von us-east-1 nach eu-west-1. Verwenden Sie eine dedizierte IAM-Rolle für die Replikation und KMS-Schlüssel in beiden Regionen, wobei Sie kms:Decrypt für die Quelle und kms:Encrypt für das Ziel gewähren. RTC-Metriken und Alarme schaffen Vertrauen in die Replikations-SLAs.

DNS-Steuerung für Canary-Tests und Failover

Fügen Sie gewichtete Route 53-Records hinzu (1 % konstanter Datenfluss nach eu-west-1), um den sekundären Pfad kontinuierlich zu testen. In Kombination mit Zustandsprüfungen stellt dies sicher, dass der Standby-Pfad produktionsbereit ist und Abweichungen (Drift) vor einer Krise erkannt werden.

Zentralisierte, unveränderliche Backups

Erstellen Sie in einem Backup-Konto, das dem Sicherheitsteam gehört, AWS Backup-Vaults mit Vault Lock und KMS CMKs. Definieren Sie Backup-Richtlinien auf Organisationsebene, um tägliche Backups und kontoübergreifende Kopien für RDS, DynamoDB, EFS und EBS zu planen. Weisen Sie Ressourcen über das Tag „Backup_Frequency“ zu. Dies ermöglicht Ransomware-Resistenz und Funktionstrennung.

Automatisierte Failover-Orchestrierung

Implementieren Sie eine EventBridge-Regel, die Signale für den Ausfall der primären Aurora-Instanz erkennt und eine Lambda-Funktion aufruft. Diese stuft die sekundäre Region herauf und aktualisiert einen Anwendungs-Endpunkt, der im Parameter Store gespeichert ist. Anwendungen laden den Endpunkt beim Start und aktualisieren ihn bei Verbindungsfehlern, um manuelle Schritte zu minimieren.

Chaos-Validierung mit AWS FIS

Erstellen Sie FIS-Experimentvorlagen, um: 10 % der ASG-Instanzen zu beenden, 150 ms Latenz und 1 % Paketverlust auf EC2 über SSM zu injizieren und ein Aurora-Failover auszulösen. Sichern Sie dies mit CloudWatch-Alarmen als Abbruchbedingungen für die p95-Latenz und die Fehlerrate ab. Führen Sie monatliche Gamedays durch, um die Geschwindigkeit des Route 53-Failovers, die Wiederherstellung der ASG, die Konvergenz des ALB-Zustands und die RTO der Aurora-Promotion zu validieren.

Warum diese Services:

Latenzbasiertes und gewichtetes Routing von Route 53 bieten sowohl optimale Benutzerlatenz als auch kontrolliertes Traffic Shaping zur Sicherstellung der DR-Bereitschaft.
ALB plus ASG mit Warm Pools und Lifecycle-Hooks gewährleisten eine schnelle, reibungslose Skalierung ohne Cold-Start-Nachteile oder Benutzerunterbrechungen.
Aurora Global Database erfüllt auf einzigartige Weise die Anforderungen an eine RPO von nahezu Null und eine RTO von unter einer Minute über Regionen hinweg mit minimalen Anwendungsänderungen.
S3 Versioning und CRR mit RTC liefern eine auditierbare, SLA-gestützte Replikation für kritische Artefakte.
AWS Backup mit kontoübergreifenden Vaults und Vault Lock erstellt unveränderliche, zentral verwaltete Backups, die auf Compliance-Anforderungen abgestimmt sind.
AWS FIS bietet eine sichere, automatisierte Fehlerinjektion, um die Resilienz kontinuierlich nachzuweisen und zu verhindern, dass Konfigurationsdrift den DR-Plan untergräbt.

← Container und Serverless-Betrieb · Alle Domänen · Ereignisgesteuerte Architekturen und Automatisierung →

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