Failover- und Geolocation-Routing

Failover-Routing implementiert eine Active-Passive-Konfiguration: Ein Datensatz wird als Primary und ein anderer als Secondary festgelegt. Route 53 gibt immer den Primary-Datensatz zurück, solange sein Health Check erfolgreich ist. Wird Primary fehlerhaft, wechselt Route 53 automatisch zur Rückgabe des Secondary-Datensatzes.

Failover-Routing ist das gängige Muster für Disaster-Recovery-Szenarien mit einer Produktionsumgebung (Primary) und einer Standby-Umgebung (Secondary), die nur dann Datenverkehr empfangen soll, wenn Primary ausgefallen ist.

Erstellen Sie für Failover-Routing zwei Datensätze mit demselben DNS-Namen: einen mit Failover=PRIMARY und einen mit Failover=SECONDARY. Verknüpfen Sie mit dem Primary-Datensatz einen Health Check. Der Secondary-Datensatz sollte ebenfalls einen Health Check haben, wenn er auf eine Ressource verweist, die unabhängig ausfallen kann.

Der Secondary-Datensatz dient als statischer Fallback. Er kann auf eine statische S3-Website, eine Wartungsseite oder eine verkleinerte Standby-Umgebung verweisen. Selbst wenn für Secondary kein Health Check konfiguriert ist, wechselt Route 53 bei einem Ausfall von Primary immer zu diesem Datensatz.

Failover-Routing erstellt eine Active-Passive-Konfiguration: Im Normalbetrieb bedient nur Primary den Datenverkehr, während Secondary inaktiv auf die Übernahme wartet. Das minimiert die Kosten für die Standby-Umgebung, führt jedoch zu einer etwas längeren Wiederherstellungszeit (der Zeit, bis die DNS-TTL abläuft und Route 53 umschaltet).

Verwenden Sie für Active-Active-Konfigurationen (beide Ressourcen bedienen gleichzeitig Datenverkehr) gewichtetes Routing (mit gleichen Gewichtungen) oder latenzbasiertes Routing. Wenn eine Ressource ausfällt, schlägt ihr Health Check fehl und Route 53 entfernt sie automatisch aus den DNS-Antworten – so wird Active-Active mit integriertem Failover erreicht.

Geolocation-Routing leitet DNS-Abfragen anhand des geografischen Standorts des DNS-Resolvers weiter (typischerweise des Resolver des Internetanbieters des Benutzers oder des AWS Route 53 Resolver). Sie erstellen Datensätze für bestimmte Kontinente, Länder oder US-Bundesstaaten, und Route 53 gibt den Datensatz zurück, dessen Standort am spezifischsten zur Quelle der Abfrage passt.

Wenn kein Datensatz für einen spezifischen Standort passt, gibt Route 53 einen Standarddatensatz zurück (falls konfiguriert). Ohne Standarddatensatz erhalten Abfragen von nicht zugeordneten Standorten NODATA. Erstellen Sie immer einen Standarddatensatz, um Benutzer aus nicht explizit konfigurierten Standorten zu berücksichtigen.

Wichtige Anwendungsfälle für Geolocation-Routing:

• Sprachspezifische Inhalte: Leiten Sie französischsprachige Benutzer zu einem französischsprachigen CDN-Ursprung und deutschsprachige Benutzer zu einem deutschen Ursprung
• Gesetzliche Compliance: Stellen Sie sicher, dass Daten von Benutzern aus der EU in EU-Regionen bleiben (DSGVO), oder blockieren Sie den Zugriff aus bestimmten Ländern
• Lokalisierte Preise oder Verfügbarkeit: Zeigen Sie regionsspezifische Preise an oder beschränken Sie Dienste auf unterstützte Gebiete
• Geo-Blocking: Geben Sie für Benutzer aus eingeschränkten Standorten eine Sperrseite oder eine leere Antwort zurück, indem Sie den Geolocation-Datensatz auf einen Wartungsendpunkt verweisen

Route 53 verwendet die spezifischste Geolocation: Ein Datensatz auf Bundesstaatsebene hat Vorrang vor einem Datensatz auf Länderebene, dieser vor einem Datensatz auf Kontinentalebene und dieser vor dem Standarddatensatz. Geolocation auf Ebene einzelner US-Bundesstaaten ist nur für die Vereinigten Staaten verfügbar.

Wenn Sie keinen Standarddatensatz konfigurieren und der Standort eines Benutzers keinem eingerichteten Datensatz entspricht, gibt Route 53 NXDOMAIN oder NODATA zurück – dadurch wird der Zugriff für Benutzer in nicht konfigurierten Regionen unbemerkt unterbrochen. Fügen Sie immer einen Standarddatensatz für Geolocation als Auffangregel hinzu, um solche unbemerkten Fehler zu vermeiden.

Geoproximity-Routing leitet Datenverkehr anhand der physischen geografischen Entfernung zwischen Benutzern und Ressourcen weiter. Optional kann ein Bias verwendet werden, um den effektiven Routing-Radius jeder Ressource zu vergrößern oder zu verkleinern. Ein positiver Bias vergrößert das geografische Gebiet, das eine Ressource bedient, ein negativer Bias verkleinert es.

Geoproximity ist nur über Traffic Flow (den visuellen Editor für Routing-Richtlinien von Route 53) verfügbar und unterstützt sowohl AWS-Regionen (deren Koordinaten Route 53 automatisch kennt) als auch benutzerdefinierte Ressourcenstandorte, für die Sie Breiten- und Längengrad angeben.

Route 53 Traffic Flow ist ein visueller Editor für Richtlinien, mit dem Sie komplexe Routing-Logik durch die Kombination mehrerer Routing-Richtlinien in einem baumartigen Diagramm erstellen können. Sie können beispielsweise zunächst Geolocation anwenden, um EU-Datenverkehr abzutrennen, anschließend innerhalb der EU Latenz verwenden, um die Region mit der besten Leistung auszuwählen, und schließlich innerhalb jeder Region gewichtetes Routing für Blue-Green-Bereitstellungen einsetzen.

Traffic-Flow-Richtlinien sind versioniert, sodass Sie Änderungen sicher testen können. Sie verknüpfen eine Traffic-Flow-Richtlinie mit einem oder mehreren DNS-Namen. Aktualisierungen der Richtlinie werden sofort übernommen, ohne einzelne Datensätze neu erstellen zu müssen.

Failover-Routing kann in andere Richtlinien eingebettet werden. Ein häufiges Muster: Verwenden Sie Latency-Routing, um die nächstgelegene Region auszuwählen, und innerhalb jeder Region einen Failover-Datensatz. Wenn der primäre Endpunkt in dieser Region ausfällt, wird der Datenverkehr automatisch zu einem sekundären Endpunkt in derselben Region umgeleitet.

Ein weiteres Muster ist Active-Passive über mehrere Regionen mit Latenz-Routing für den primären Endpunkt. Wenn der Health Check der primären Region fehlschlägt, fällt Route 53 auf die gesunde Region mit der nächstniedrigeren Latenz zurück – so werden Latenzoptimierung und DR-Failover effektiv kombiniert.

Damit Failover-Routing korrekt funktioniert, muss** für den Primary-Datensatz ein Health Check verknüpft sein. Ohne Health Check behandelt Route 53 Primary als immer gesund und wechselt nie zu Secondary. Der Secondary-Datensatz kann optional einen eigenen Health Check haben. Wenn auch Secondary ausfällt, gibt Route 53 trotzdem die Adresse von Secondary zurück (dieser ist der letzte Ausweg).

Health-Check-Typen, die Sie für Failover verwenden können: HTTP-/HTTPS-Endpunktprüfungen, TCP-Prüfungen und CloudWatch-Alarmprüfungen (nützlich für zusammengesetzte Anwendungssignale, die mehrere Metriken kombinieren).

Diese Unterscheidung kommt in der SAA-C03-Prüfung häufig vor:

• Geolocation: Das Routing erfolgt nach dem geografischen Standort des Benutzers – für ein bestimmtes Land oder einen bestimmten Kontinent wird unabhängig von der Leistung immer derselbe Endpunkt zurückgegeben; verwendet für Inhaltslokalisierung und Compliance
• Latency: Das Routing erfolgt nach der Netzwerkleistung für den Benutzer – ein Benutzer in Europa kann zu us-east-1 geleitet werden, wenn diese Region zu diesem Zeitpunkt schneller ist als eu-west-1; verwendet zur Leistungsoptimierung

Schlüsselbegriffe in Prüfungsfragen: „Datenresidenz einhalten“, „länderspezifische Inhalte“, „Benutzer aus bestimmten Regionen blockieren“ → Geolocation. „nächstgelegene Region“, „niedrigste Latenz“, „beste Leistung für globale Benutzer“ → Latency.

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

In dieser Lektion haben Sie Folgendes gelernt: Failover-Routing erstellt eine aktive-passive HA-Konfiguration, indem bei einem Fehlschlagen des Zustandschecks auf die sekundäre Ressource umgeschaltet wird; Geolocation-Routing leitet Benutzer anhand ihres geografischen Ursprungs weiter, um Compliance und Lokalisierung zu unterstützen; und Geoproximity-Routing verwendet die physische Entfernung mit einer konfigurierbaren Gewichtung über Traffic Flow. Fügen Sie immer einen Standard-Geolocation-Datensatz hinzu, um nicht zugeordneten Standorten Rechnung zu tragen. Als Nächstes beschäftigen wir uns ausführlich mit Zustandschecks und DNS-Failover.