Pilot Light und Warm Standby

Wenn Ihre RTO-Anforderung strenger ist als eine Ausfallzeit von wenigen Stunden, reicht Backup und Wiederherstellung nicht aus. Die beiden nächsten DR-Stufen – Pilot Light und Warm Standby – halten ständig einen Teil oder die gesamte Infrastruktur in der DR-Region aktiv und verkürzen dadurch die Wiederherstellungszeit erheblich. Beide Strategien umfassen den kontinuierlichen Betrieb einer DR-Umgebung sowie ein Failover mithilfe von Route-53-Zustandsprüfungen, um den Datenverkehr im Notfall umzuleiten. Sie unterscheiden sich darin, wie viel der DR-Umgebung aktiv ausgeführt wird.

Bei der Strategie Pilot Light betreiben Sie in der DR-Region nur den kritischen Kern Ihres Systems – typischerweise lediglich die Datenbankebene mit kontinuierlicher Replikation. Die Anwendungsserver werden NICHT ausgeführt. Stattdessen verwalten Sie vorbereitete AMIs, Startvorlagen oder Infrastructure as Code, mit denen die Server schnell gestartet werden können. Stellen Sie sich dies wie eine kleine Gasflamme einer Zündflamme vor, die bei Bedarf innerhalb weniger Minuten die vollständige Flamme entzünden kann. Das RTO beträgt typischerweise 30–60 Minuten.

Wenn die primäre Region ausfällt und das Pilot-Light-Failover ausgelöst wird: Schritt 1 – Stufen Sie das RDS Read Replica in der DR-Region zu einer eigenständigen primären Datenbank hoch. Schritt 2 – Starten Sie EC2-Instances aus dem vorbereiteten AMI oder der Startvorlage. Schritt 3 – Erstellen oder aktivieren Sie den Application Load Balancer und registrieren Sie die neuen EC2-Instances. Schritt 4 – Aktualisieren Sie die Anwendungskonfiguration so, dass sie auf den Endpunkt der hochgestuften Datenbank verweist. Schritt 5 – Die Failover-Zustandsprüfung von Route 53 schließt die DNS-Umschaltung ab. Gesamtdauer: 30–60 Minuten.

Bei der Strategie Warm Standby wird kontinuierlich eine vollständige, aber verkleinerte Version Ihrer Produktionsumgebung in der DR-Region ausgeführt. Alle Anwendungsebenen sind aktiv – Webserver, Anwendungsserver und Datenbank –, jedoch mit reduzierter Kapazität (z. B. 2 statt 20 Instances). Beim Failover skalieren Sie die DR-Umgebung auf die Last der Produktionsumgebung hoch. Route 53 schaltet den Datenverkehr mithilfe eines Failovers auf Grundlage von Zustandsprüfungen automatisch um. Das RTO beträgt typischerweise weniger als 15 Minuten. Warm Standby ist die beliebteste DR-Stufe für geschäftskritische Anwendungen.

Aurora Global Database ist die ideale Datenbanktechnologie für Warm-Standby-Notfallwiederherstellung. Der Cluster in der sekundären Region wird ständig ausgeführt, empfängt kontinuierlich Replikationen (mit einer Verzögerung von <1 Sekunde) und kann innerhalb von weniger als 1 Minute zu einer primären Datenbank hochgestuft werden – deutlich schneller als ein RDS Read Replica, bei dem die Replikation angehalten und der verbleibende Rückstand angewendet werden muss. Damit ist Aurora Global Database die empfohlene Wahl, wenn Ihre RTO-Anforderung im Minutenbereich und nicht im Bereich von mehreren zehn Minuten liegt.

Sowohl Pilot Light als auch Warm Standby verwenden Failover-Routing von Route 53, um den Datenverkehr automatisch umzuleiten. Konfigurieren Sie einen primären Datensatz, der auf den ALB oder Endpunkt Ihrer Produktionsregion verweist, und verknüpfen Sie ihn mit einer Zustandsprüfung. Konfigurieren Sie einen sekundären Datensatz, der auf den Endpunkt Ihrer DR-Region verweist. Wenn Route 53 erkennt, dass die primäre Zustandsprüfung den konfigurierten Schwellenwert überschritten hat, gibt der Service den primären Datensatz nicht mehr zurück und liefert nur noch den sekundären Datensatz aus – und zwar innerhalb der DNS-TTL.

Damit Warm Standby das angestrebte RTO erreicht, muss die DR-Umgebung vorgewärmt sein – vollständig konfiguriert und getestet, sodass beim Failover nur noch die Skalierung erforderlich ist. Das bedeutet: Datenbankverbindungen sind hergestellt und zwischengespeichert, Anwendungskonfigurationsdateien verweisen auf Endpunkte in der DR-Region, EC2-Instances sind (auch in geringer Anzahl) hinter dem ALB aktiv und die Zustandsprüfungen sind erfolgreich. Führen Sie monatliche DR-Übungen durch, bei denen Sie ein Failover simulieren, um sicherzustellen, dass die Umgebung mit der Produktionskonfiguration auf dem aktuellen Stand bleibt.

Die Synchronisierung Ihrer DR-Umgebung mit der Produktionsumgebung ist die größte betriebliche Herausforderung. Wenn Sie die Produktion manuell konfigurieren und vergessen, die DR-Umgebung zu aktualisieren, funktioniert diese im echten Notfall möglicherweise nicht korrekt. Die Lösung ist Infrastructure as Code (IaC) mit denselben Vorlagen, die in beiden Regionen bereitgestellt werden. Verwenden Sie AWS CloudFormation StackSets oder Terraform mit mehreren Workspaces, um identische Infrastrukturen aus einer einzigen Codebasis in beiden Regionen bereitzustellen. Dadurch wird Konfigurationsdrift verhindert.

Der Kostenunterschied zwischen den beiden Strategien ist erheblich. Pilot Light verursacht lediglich Kosten für das Datenbank-Replikat (typischerweise 50–100 % der Kosten der primären Datenbank) sowie minimale Netzwerkkosten in der DR-Region. Die Anwendungsserver sind ausgeschaltet, daher fallen keine EC2-Kosten an. Warm Standby verursacht zusätzlich Kosten für den Betrieb verkleinerter EC2-Instances, eines ALB und möglicherweise eines kleineren Cache-Clusters – typischerweise 15–30 % der Gesamtkosten der Produktionsumgebung. Entscheidend ist, ob das schnellere RTO von Warm Standby die höheren laufenden Kosten rechtfertigt.

Nachdem die Primärregion wiederhergestellt wurde, benötigen Sie einen Failback-Plan für die Rückkehr dorthin. Failback ist oft der schwierigste Teil der Notfallwiederherstellung (DR): Während des Ausfalls kann die DR-Region neue Daten verarbeitet haben, die mit der Primärregion synchronisiert werden müssen. Bei Datenbanken müssen Sie möglicherweise eine umgekehrte Replikation einrichten oder die Synchronisierung von der DR-Region zur Primärregion erneut durchführen. Für Route 53 aktivieren Sie den Datensatz der Primärregion einschließlich seines Health Checks wieder. Planen und testen Sie das Failback-Verfahren immer genauso sorgfältig wie den Failover selbst.

Wählen Sie Pilot Light, wenn Ihr RTO 30–60 Minuten zulässt und Sie die DR-Kosten minimieren möchten. Das größte Risiko ist die Zeit, die benötigt wird, um während eines Notfalls unter Zeitdruck Anwendungsserver zu starten und zu konfigurieren. Wählen Sie Warm Standby, wenn Ihr RTO eine Wiederherstellung innerhalb von 15 Minuten erfordert, Ihre Anwendung so komplex ist, dass ein vollständiger Neustart während eines Notfalls riskant wäre, oder Ihre SLA-Zusage gegenüber Kunden eine schnellere Wiederherstellung verlangt. Für die meisten Produktions-Workloads mit mittlerer Kritikalität bietet Warm Standby das richtige Gleichgewicht.

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

In dieser Lektion haben Sie gelernt: Pilot Light hält in der DR-Umgebung nur die Datenbank aktiv und startet die Anwendungsserver während des Failovers, Warm Standby betreibt eine vollständig skalierte, aber verkleinerte Umgebung, die während des Failovers hochskaliert wird und Infrastructure as Code verhindert Konfigurationsabweichungen zwischen Primär- und DR-Umgebungen. Planen und testen Sie Failback-Verfahren immer ebenso wie Failover-Verfahren. Als Nächstes untersuchen wir Multi-Site-Active-Active mit DynamoDB Global Tables und Route 53.