Health Checks und DNS-Failover

Route-53-Zustandschecks überwachen kontinuierlich den Zustand Ihrer Endpunkte – Webserver, Load Balancer oder beliebige über das Internet erreichbare HTTP-/HTTPS-/TCP-Endpunkte. Anhand der Ergebnisse der Zustandschecks kann Route 53 das DNS-Routing automatisch aktualisieren, um Datenverkehr nicht an fehlerhafte Ressourcen zu senden.

Zustandschecks werden pro Zustandscheck und Monat abgerechnet. Die globalen Zustandschecker von Route 53 (die sich in mehreren Regionen befinden) prüfen Ihren Endpunkt gleichzeitig und sorgen so für Redundanz bei der Zustandsprüfung selbst. Ein Endpunkt gilt erst dann als fehlerhaft, wenn eine bestimmte Anzahl von Checkern übereinstimmend feststellt, dass er ausgefallen ist.

Zustandschecks für Endpunkte überwachen eine bestimmte IP-Adresse oder einen Domänennamen mit dem von Ihnen gewählten Protokoll (HTTP, HTTPS oder TCP), Port und optionalen Pfad. Bei HTTP-/HTTPS-Checks überprüft Route 53, ob der Endpunkt innerhalb des Zeitlimits einen HTTP-Statuscode der Klasse 2xx oder 3xx zurückgibt. Bei HTTPS-Checks kann optional das TLS-Zertifikat validiert werden.

Wichtige Konfigurationsoptionen: Anforderungsintervall (10 oder 30 Sekunden – 10 Sekunden ermöglichen eine schnellere Erkennung, sind aber teurer), Fehlerschwellenwert (1–10 aufeinanderfolgende Fehler, bevor der Endpunkt als fehlerhaft markiert wird) und Zeichenfolgenabgleich (optional wird überprüft, ob der Antworttext eine bestimmte Zeichenfolge enthält).

Berechnete Zustandschecks kombinieren die Ergebnisse mehrerer untergeordneter Zustandschecks mithilfe boolescher Logik (AND, OR, NOT). So können Sie den Zustand einer Anwendung anhand mehrerer Signale definieren, ohne komplexe Routing-Ketten zu erstellen.

Beispiel: Eine Webanwendung ist nur dann fehlerfrei, wenn sowohl der Check des API-Servers als auch der Datenbank-Check erfolgreich ist. Erstellen Sie einen berechneten Zustandscheck mit dem Typ AND, der auf beide Endpunkt-Checks verweist. Wenn einer der beiden Checks fehlschlägt, schlägt auch der berechnete Zustandscheck fehl, und Route 53 entfernt den zugehörigen DNS-Datensatz aus den Antworten.

Zustandschecks auf Basis von CloudWatch-Alarmen verknüpfen einen Route-53-Zustandscheck mit dem Zustand eines CloudWatch-Alarms. Befindet sich der Alarm im Zustand ALARM, wird der Zustandscheck als fehlerhaft markiert; bei OK oder INSUFFICIENT_DATA wird er als fehlerfrei markiert.

Dieses Muster ist für Endpunkte innerhalb einer VPC besonders nützlich, da diese von den externen Zustandscheckern von Route 53 nicht erreicht werden können. Statt den privaten Endpunkt direkt zu prüfen, erstellen Sie dafür CloudWatch-Metriken und -Alarme und legen anschließend den Route-53-Zustandscheck anhand des Alarmzustands fest. Dadurch können Zustandschecks auch auf Geschäftsmesswerten wie Fehlerrate oder Warteschlangentiefe basieren.

Die Zustandschecker von Route 53 sind von AWS verwaltete Server außerhalb Ihrer VPC, die Endpunkte über das öffentliche Internet erreichen. Ressourcen in privaten Subnetzen sind für standardmäßige Zustandschecks von Endpunkten nicht erreichbar. Verwenden Sie für private Endpunkte einen der folgenden Ansätze:

• Veröffentlichen Sie innerhalb der VPC eine benutzerdefinierte CloudWatch-Metrik (z. B. ein Erfolgs-/Fehlersignal der Anwendung), erstellen Sie einen Alarm und verwenden Sie einen Zustandscheck auf Basis eines CloudWatch-Alarms
• Verwenden Sie einen zusammengesetzten CloudWatch-Alarm, der ELB-, RDS- oder Anwendungsmetriken innerhalb der VPC zusammenfasst

Dieses Muster ist für Datenbanken in privaten Subnetzen, interne Load Balancer und Backend-Services von entscheidender Bedeutung.

Sie können den Status eines Zustandschecks in der Route-53-Konsole unter Health Checks anzeigen oder über die API abfragen. Route 53 veröffentlicht Metriken zu Zustandschecks in CloudWatch im Namespace AWS/Route53, darunter HealthCheckStatus (1 = fehlerfrei, 0 = fehlerhaft) und HealthCheckPercentageHealthy (Prozentsatz der Route-53-Checker, die den Endpunkt als fehlerfrei melden).

Richten Sie CloudWatch-Alarme für HealthCheckStatus ein, um SNS-Benachrichtigungen zu erhalten, sobald ein Endpunkt fehlerhaft wird. So erhalten Sie Einblick, bevor Ihr Bereitschaftsteam bemerkt, dass das DNS-Failover bereits stattgefunden hat.

Wenn Route 53 feststellt, dass der Zustandscheck eines primären Datensatzes fehlgeschlagen ist, entfernt es den primären Datensatz aus den DNS-Antworten und gibt die Adresse des sekundären Datensatzes zurück. Dies wird als DNS-Failover bezeichnet. Die Umschaltung erfolgt innerhalb des Auswertungszeitraums (Anzahl der Fehler der Zustandschecker × Anforderungsintervall) zuzüglich der TTL des Datensatzes.

Beispiel: Anforderungsintervall = 30 s, Fehlerschwellenwert = 3, TTL = 60 s. Die maximale Failover-Zeit beträgt ungefähr 3 × 30 + 60 = 150 Sekunden. Durch eine niedrigere TTL (z. B. 10 Sekunden) und ein kürzeres Zustandscheck-Intervall (10 s) lässt sich diese Zeit auf 3 × 10 + 10 = 40 Sekunden reduzieren.

Zustandschecks können auch gewichteten Datensätzen und Latenzdatensätzen zugeordnet werden, nicht nur Failover-Datensätzen. Wenn der Zustandscheck eines gewichteten Datensatzes fehlschlägt, verteilt Route 53 dessen Datenverkehrsgewicht proportional auf die fehlerfreien gewichteten Datensätze. Wenn der Zustandscheck eines Latenzdatensatzes fehlschlägt, leitet Route 53 Abfragen an den fehlerfreien Datensatz mit der nächstniedrigeren Latenz weiter.

Dadurch werden gewichtete und latenzbasierte Routing-Richtlinien gegenüber Endpunktausfällen resilient, ohne dass explizite Failover-Datensätze erforderlich sind. Dies ist ein gängiges SAA-C03-Muster: Latenz-Routing über mehrere Regionen mit Zustandschecks bietet sowohl eine Leistungsoptimierung als auch eine automatische Notfallwiederherstellung.

Ein resilientes Aktiv-aktiv-Muster über mehrere Regionen mit Route 53:

1. Erstellen Sie für jede Region (us-east-1, eu-west-1, ap-southeast-1) einen Latenzdatensatz mit Zustandscheck
2. Solange alle Regionen fehlerfrei sind, werden Benutzer an die Region mit der niedrigsten Latenz weitergeleitet
3. Wenn der Zustandscheck einer Region fehlschlägt (Anwendung ausgefallen oder nicht reagierend), entfernt Route 53 diese Region automatisch aus den DNS-Antworten und leitet Abfragen an die nächstbeste fehlerfreie Region weiter
4. Wenn sich die ausgefallene Region erholt, ist der Zustandscheck wieder erfolgreich und Route 53 nimmt sie wieder in die Verteilung auf

Dies ermöglicht ein automatisches globales Failover mit Leistungsoptimierung – ohne manuelle Eingriffe.

Die Zustandschecker von Route 53 stammen aus einer Gruppe veröffentlichter IP-Bereiche im Abschnitt ROUTE53_HEALTHCHECKS der AWS-IP-Bereiche-JSON-Datei. Wenn Ihr Endpunkt durch eine Firewall oder Sicherheitsgruppe geschützt ist, die den eingehenden Zugriff beschränkt, müssen Sie Datenverkehr aus diesen IP-Bereichen zulassen, damit die Zustandschecks erfolgreich sind.

Alternativ können Sie einen öffentlich erreichbaren Endpunkt verwenden, der als Proxy für Ihr privates Backend dient (z. B. ein ALB). Die Sicherheitsgruppe des ALB muss lediglich die IP-Bereiche von Route 53 zulassen, während die Sicherheitsgruppe des Backends nur die Sicherheitsgruppe des ALB zulässt. So bleibt der Defense-in-Depth-Ansatz erhalten.

Bewährte Vorgehensweisen für Route-53-Zustandschecks:

• Erstellen Sie einen dedizierten /health-Endpunkt, der alle kritischen Abhängigkeiten (Datenbankverbindung, Erreichbarkeit des Caches) prüft und nur dann 200 zurückgibt, wenn das System vollständig betriebsbereit ist
• Verwenden Sie für kritische Produktionsendpunkte ein Anforderungsintervall von 10 Sekunden, um Ausfälle schneller zu erkennen
• Überwachen Sie HealthCheckPercentageHealthy in CloudWatch – ein Teilausfall (einige, aber nicht alle Route-53-Checker schlagen fehl) kann auf ein regionales Netzwerkproblem oder ein sporadisches Problem hindeuten
• Verwenden Sie für private Ressourcen in einer VPC Zustandschecks auf Basis von CloudWatch-Alarmen, die sich auf Anwendungsmetriken stützen
• Testen Sie das Failover in Umgebungen außerhalb der Produktion, bevor Sie sich in der Produktion darauf verlassen

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

In dieser Lektion haben Sie Folgendes gelernt: Zustandschecks für Endpunkte prüfen HTTP/HTTPS/TCP über externe Route-53-Checker, Zustandschecks auf Basis von CloudWatch-Alarmen ermöglichen die Überwachung privater VPC-Ressourcen und berechnete Zustandschecks kombinieren mehrere Signale mithilfe boolescher Logik. Die Geschwindigkeit des DNS-Failovers hängt vom Zustandscheck-Intervall, vom Fehlerschwellenwert und von der TTL ab. Als Nächstes beschäftigen wir uns mit CloudFront-Distributionen und Ursprüngen.