Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Bewährte Methoden für Amazon Route 53
Dieser Abschnitt enthält bewährte Methoden für verschiedene Komponenten von Amazon Route 53, darunter:
1. **Bewährte Methoden für DNS:**
+ Machen Sie sich mit den Kompromissen zwischen TTL-Werten (Time to Live) und Reaktionsfähigkeit und Zuverlässigkeit vertraut.
+ Verwenden Sie nach Möglichkeit Alias-Datensätze anstelle von CNAME-Datensätzen, um die Leistung zu verbessern und Kosten zu sparen.
+ Konfigurieren Sie Standard-Routing-Richtlinien, um sicherzustellen, dass alle Clients eine Antwort erhalten.
+ Nutzen Sie latenzbasiertes Routing zur Minimierung der Anwendungslatenz und geolocation/geoproximity Routing für Stabilität und Vorhersehbarkeit.
+ Überprüfen Sie die Weitergabe von Änderungen mithilfe der `GetChange` API für automatisierte Workflows.
+ Delegieren Sie Subdomänen aus der übergeordneten Zone, um ein konsistentes Routing zu gewährleisten.
+ Vermeiden Sie große Einzelantworten, indem Sie das Routing mehrwertiger Antworten verwenden.
1. **Bewährte Methoden für Resolver:**
+ Vermeiden Sie Routingschleifen, indem Sie vermeiden, dieselbe VPC sowohl einer Resolver-Regel als auch ihrem eingehenden Endpunkt zuzuordnen.
+ Implementieren Sie Sicherheitsgruppenregeln, um den Aufwand für die Verbindungsverfolgung zu reduzieren und den Abfragedurchsatz zu maximieren.
+ Konfigurieren Sie eingehende Endpunkte mit IP-Adressen in mehreren Availability Zones, um Redundanz zu gewährleisten.
+ Seien Sie sich möglicher DNS-Zone-Walking-Angriffe bewusst und wenden Sie sich an den AWS Support, wenn Ihre Endgeräte gedrosselt werden.
1. **Bewährte Verfahren für Gesundheitschecks:**
+ Folgen Sie den Empfehlungen zur Optimierung von Amazon Route 53 53-Zustandsprüfungen, um eine zuverlässige Überwachung Ihrer Ressourcen zu gewährleisten
Wenn Sie sich an diese bewährten Methoden halten, können Sie die Leistung, Zuverlässigkeit und Sicherheit Ihrer DNS-Infrastruktur optimieren und so eine effiziente und effektive Weiterleitung des Datenverkehrs zu Ihren Anwendungen und Diensten sicherstellen
**Topics**
+ [Bewährte Methoden für Amazon Route 53 DNS](best-practices-dns.md)
+ [Bewährte Methoden für VPC Resolver](best-practices-resolver.md)
+ [Bewährte Methoden für Amazon Route 53 Zustandsprüfungen](best-practices-healthchecks.md)
# Bewährte Methoden für Amazon Route 53 DNS
Befolgen Sie diese bewährten Methoden, um bei der Verwendung des DNS-Dienstes von Amazon Route 53 beste Ergebnisse zu erzielen.
**Verwenden Sie die Datenebenenfunktionen für DNS Failover und Anwendungswiederherstellung**
Die Datenebenen für Route 53, einschließlich Integritätsprüfungen und Amazon Application Recovery Controller (ARC) -Routing-Steuerung, sind weltweit verteilt und auf hundertprozentige Verfügbarkeit und Funktionalität ausgelegt, selbst bei schwerwiegenden Ereignissen. Sie integrieren sich miteinander und hängen nicht von der Funktionalität der Steuerebene ab. Die Steuerebenen für diese Dienste, einschließlich ihrer Konsolen, sind zwar im Allgemeinen sehr zuverlässig, sie sind aber zentralisierter konzipiert und priorisieren Beständigkeit und Konsistenz anstelle von hoher Verfügbarkeit. Für Szenarien wie ein Failover während der Notfallwiederherstellung empfehlen wir die Verwendung von Funktionen wie Route 53-Zustandsprüfungen und ARC-Routing-Steuerung, die zur DNS-Aktualisierung auf Datenebenenfunktionen angewiesen sind. Weitere Informationen finden Sie unter [Konzepte für Steuer- und Datenebene](route-53-concepts.md#route-53-concepts-control-and-data-plane) und im [Blog: Erstellen von Notfallwiederherstellungsmechanismen mit Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/).
**Auswählen von TTL-Werten für DNS-Datensätze**
Die DNS-TTL ist der numerische Wert (in Sekunden), mit dem DNS-Resolver entscheiden, wie lange ein Datensatz zwischengespeichert werden kann, ohne eine weitere Abfrage an Route 53 zu stellen. Für alle DNS-Datensätze muss eine TTL angegeben sein. Der empfohlene Bereich für TTL-Werte beträgt 60 bis 172 800 Sekunden.
Die Wahl einer TTL ist ein Kompromiss zwischen Latenz und Zuverlässigkeit auf der einen und Reaktionsfähigkeit auf Änderungen auf der anderen Seite. Bei kürzeren TTLs Einträgen stellen DNS-Resolver Aktualisierungen des Datensatzes schneller fest, da sie häufiger Abfragen durchführen müssen. Dies erhöht das Abfragevolumen (und die Kosten). Wenn Sie die TTL verlängern, beantworten DNS-Resolver häufiger Abfragen aus dem Cache, was normalerweise schneller, günstiger und in einigen Situationen zuverlässiger ist, da die Abfragen nicht aus dem Internet vorgenommen werden. Es gibt keinen richtigen Wert, aber Sie sollten sich fragen, ob Reaktionsfähigkeit oder Zuverlässigkeit für Sie wichtiger ist.
Beachten Sie folgende Punkte beim Festlegen von TTL-Werten:
+ Richten Sie den DNS-Eintrag TTLs so lange ein, wie Sie es sich leisten können, auf das Inkrafttreten einer Änderung zu warten. Dies gilt insbesondere für Delegierungen (NS-Datensätze) oder andere Datensätze, die sich selten ändern, z. B. MX-Datensätze. Für diese Einträge TTLs werden längere Werte empfohlen. Die meisten werden auf eine Dauer zwischen einer Stunde (3 600 Sekunden) und einem Tag (86 400 Sekunden) festgelegt.
+ Für Datensätze, die im Rahmen eines schnellen Failover-Mechanismus geändert werden müssen (insbesondere Datensätze, deren Integrität überprüft wurde), TTLs sind niedrigere Werte angemessen. Das Festlegen einer TTL von 60 oder 120 Sekunden ist eine übliche Wahl für dieses Szenario.
+ Wenn Sie Änderungen an wichtigen DNS-Einträgen vornehmen möchten, empfehlen wir Ihnen, den TTLs vorübergehend zu kürzen. Dann können Sie die Änderungen vornehmen, beobachten und bei Bedarf schnell zurücksetzen. Sobald die Änderungen abgeschlossen sind und wie erwartet funktionieren, können Sie die TTL verlängern.
Weitere Informationen finden Sie unter [TTL (Sekunden)](resource-record-sets-values-shared.md#rrsets-values-common-ttl).
**CNAME-Datensätze**
CNAME-Datensätze sind eine Möglichkeit, mit einem Domänennamen auf einen anderen zu verweisen. Wenn ein DNS-Resolver domain-1.example.com auflöst und einen CNAME findet, der auf domain-2.example.com verweist, muss der DNS-Resolver domain-2.example.com auflösen, bevor er antworten kann. Diese Datensätze sind in vielen Situationen nützlich, um beispielsweise die Konsistenz zu gewährleisten, wenn eine Website mehr als einen Domänennamen hat.
DNS-Resolver müssen jedoch mehr Anfragen stellen, um sie zu beantworten CNAMEs, was die Latenz und die Kosten erhöht. Wenn möglich, besteht eine schnellere und günstigere Alternative darin, einen Route-53-Alias-Datensatz zu verwenden. Aliaseinträge ermöglichen es Route 53, mit einer direkten Antwort für AWS Ressourcen (z. B. einen Load Balancer) und für andere Domänen innerhalb derselben Hostzone zu antworten.
Weitere Informationen finden Sie unter [Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
**Erweiterte DNS-Weiterleitung**
+ Wenn Sie Geolokalisierung, Geoproximity oder latenzbasiertes Routing verwenden, legen Sie immer einen Standardwert fest, es sei denn, Sie möchten, dass einige Kunden die Antwort *no answer* (keine Antwort) erhalten.
+ Verwenden Sie latenzbasiertes Routing, um die Anwendungslatenz zu minimieren. Diese Art der Datenweiterleitung kann sich häufig ändern.
+ Um Routingstabilität und Planbarkeit zu gewährleisten, verwenden Sie entweder Geolokalisierung oder Geoproximity-Routing.
Weitere Informationen finden Sie unter [Geolocation-Routing](routing-policy-geo.md), [Geoproximity-Routing](routing-policy-geoproximity.md) und [Latenzbasiertes Routing](routing-policy-latency.md).
**DNS-Änderungsverbreitung**
Wenn Sie einen Datensatz oder eine gehostete Zone mithilfe der Route-53-Konsole oder -API erstellen oder aktualisieren, dauert es einige Zeit, bis die Änderung im Internet sichtbar wird. Das wird *Verbreitung von Änderungen* genannt. Während die Verbreitung weltweit für gewöhnlich weniger als eine Minute dauert, gibt es gelegentlich Verzögerungen, z. B. aufgrund von Problemen bei der Synchronisierung mit einem Standort oder, in seltenen Fällen, aufgrund von Problemen innerhalb der zentralen Steuerebene. Wenn Sie automatisierte Bereitstellungs-Workflows erstellen und es wichtig ist, zu warten, bis die Übertragung der Änderungen abgeschlossen ist, bevor Sie mit dem nächsten Workflow-Schritt fortfahren, überprüfen Sie mithilfe der [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API, ob Ihre DNS-Änderungen wirksam geworden sind ()`Status =INSYNC`.
**DNS-Delegierung**
Wenn Sie mehrere Subdomänen-Ebenen in DNS delegieren, ist es wichtig, immer von der übergeordneten Zone, der „parent“-Zone, aus zu delegieren. Wenn Sie beispielsweise www.dept.example.com delegieren, sollten Sie dies aus der Zone dept.example.com und nicht aus der Zone example.com tun. Delegierungen von einer *grandparent*- zu einer *child*-Zone funktionieren möglicherweise überhaupt nicht oder nur inkonsistent. Weitere Informationen finden Sie unter [Weiterleiten von Datenverkehr für Subdomänen](dns-routing-traffic-for-subdomains.md).
**Größe der DNS-Antwort**
Erstellen Sie keine großen Einzelantworten. Bei einer Größe von über 512 Byte müssen viele DNS-Resolver erneute Versuche über TCP anstelle von UDP ausführen, was zu langsameren Antworten und geringerer Zuverlässigkeit führen kann. Wir empfehlen die Verwendung von Antworten mit mehreren Werten, die acht gesunde, zufällige IPs auswählen, damit die Antworten innerhalb der 512-Byte-Grenze bleiben.
Weitere Informationen finden Sie unter [Mehrwertiges Antwort-Routing](routing-policy-multivalue.md) sowie unter [DNS-Antwortgröße-Testserver](https://www.dns-oarc.net/oarc/services/replysizetest/).
# Bewährte Methoden für VPC Resolver
Dieser Abschnitt enthält bewährte Methoden für die Optimierung von Amazon Route 53 VPC Resolver und behandelt die folgenden Themen:
1. **Vermeidung von Loop-Konfigurationen mit Resolver-Endpunkten:**
+ Vermeiden Sie Routingschleifen, indem Sie sicherstellen, dass dieselbe VPC nicht sowohl mit einer Resolver-Regel als auch mit ihrem eingehenden Endpunkt verknüpft ist.
+ Verwenden Sie diese AWS RAM Option für die gemeinsame Nutzung VPCs durch mehrere Konten unter Beibehaltung der korrekten Routing-Konfigurationen.
Weitere Informationen finden Sie unter [Vermeiden SieSchleifenkonfigurationenResolver-Endpunkt](best-practices-resolver-endpoints.md).
1. **Skalierung von Resolver-Endpunkten:**
+ Implementieren Sie Sicherheitsgruppenregeln, die Datenverkehr auf der Grundlage des Verbindungsstatus zulassen, um den Aufwand für die Verbindungsverfolgung zu reduzieren
+ Befolgen Sie die empfohlenen Sicherheitsgruppenregeln für eingehende und ausgehende Resolver-Endpunkte, um den Abfragedurchsatz zu maximieren.
+ Überwachen Sie eindeutige Kombinationen von IP-Adressen und Ports, die DNS-Verkehr generieren, um Kapazitätsbeschränkungen zu vermeiden.
Weitere Informationen finden Sie unter [Resolver-Endpunkt-Skalierung](best-practices-resolver-endpoint-scaling.md).
1. **Hohe Verfügbarkeit für Resolver-Endpunkte:**
+ Erstellen Sie aus Redundanzgründen eingehende Endpunkte mit IP-Adressen in mindestens zwei Availability Zones.
+ Stellen Sie zusätzliche Netzwerkschnittstellen bereit, um die Verfügbarkeit bei Wartungsarbeiten oder bei hohem Datenaufkommen sicherzustellen
Weitere Informationen finden Sie unter [Hohe Verfügbarkeit für Resolver-Endpunkt](best-practices-resolver-endpoint-high-availability.md).
1. **Verhinderung von DNS-Zone-Walking-Angriffen:**
+ Seien Sie sich möglicher DNS-Zone-Walking-Angriffe bewusst, bei denen Angreifer versuchen, den gesamten Inhalt aus DNSSEC-signierten DNS-Zonen abzurufen.
+ Wenn Ihre Endgeräte aufgrund des vermuteten Zonenwechsels gedrosselt werden, wenden Sie sich an den Support, um AWS Unterstützung zu erhalten.
Weitere Informationen finden Sie unter [Gehen Sie zur DNS-Zone](best-practices-resolver-zone-walking.md).
Wenn Sie diese bewährten Methoden befolgen, können Sie die Leistung, Skalierbarkeit und Sicherheit Ihrer VPC-Resolver-Bereitstellungen optimieren und so eine zuverlässige und effiziente DNS-Auflösung für Ihre Anwendungen und Ressourcen sicherstellen.
# Vermeiden SieSchleifenkonfigurationenResolver-Endpunkt
Ordnen Sie dieselbe VPC nicht einer Resolver-Regel und ihrem eingehenden Endpunkt zu (unabhängig davon, ob es sich um ein direktes Ziel des Endpunkts oder über einen On-Premises-DNS-Server handelt). Wenn der ausgehende Endpunkt in einer Resolver-Regel auf einen eingehenden Endpunkt verweist, der eine VPC mit der Regel gemeinsam verwendet, kann dies zu einer Schleife führen, in der die Abfrage kontinuierlich zwischen den eingehenden und ausgehenden Endpunkten übergeben wird.
Die Weiterleitungsregel kann mithilfe von AWS Resource Access Manager (AWS RAM) weiterhin mit anderen Konten verknüpft werden VPCs , die mit anderen Konten geteilt wurden. Private gehostete Zonen, die dem Hub oder einer zentralen VPC zugeordnet sind, werden weiterhin von Abfragen an eingehende Endpunkte aufgelöst, da eine Weiterleitungsauflösungsregel diese Auflösung nicht ändert.
# Resolver-Endpunkt-Skalierung
Resolver-Endpunkt Sicherheitsgruppen verwenden die Verbindungsverfolgung zum Sammeln von Informationen über Datenverkehr zu und von den Endpunkten. Jede Endpunktschnittstelle verfügt über eine maximale Anzahl von Verbindungen, die verfolgt werden können, und eine hohe Anzahl von DNS-Abfragen kann die Verbindungen überschreiten und zu Drosselung und Abfrageverlust führen. Die Verbindungsverfolgung AWS ist das Standardverhalten zur Überwachung des Datenverkehrs, der durch Sicherheitsgruppen fließt (SGs). Durch die Verwendung der Verbindungsverfolgung SGs wird der Durchsatz des Datenverkehrs reduziert. Sie können jedoch Verbindungen ohne Nachverfolgung implementieren, um den Overhead zu reduzieren und die Leistung zu verbessern. Weitere Informationen finden Sie unter Verbindungen [ohne Nachverfolgung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).
Wenn die Verbindungsverfolgung entweder mithilfe restriktiver Sicherheitsgruppenregeln erzwungen wird oder Abfragen über den Network Load Balancer weitergeleitet werden (siehe [Automatisch verfolgte Verbindungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), kann die maximale Gesamtzahl der Abfragen pro Sekunde und IP-Adresse für einen Endpunkt bis zu 1500 betragen.
**Regelempfehlungen für Sicherheitsgruppen für eingehenden und ausgehenden Datenverkehr für den Resolver-Endpunkt für eingehende Anrufe**
****
|
|
| **Regeln für eingehenden Datenverkehr** |
| --- |
| Protokolltyp | Port-Nummer | Quell-IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **Regeln für den Ausgang** |
| --- |
| Protokolltyp | Port-Nummer | Ziel-IP |
| TCP | Alle | 0.0.0.0/0 |
| UDP | Alle | 0.0.0.0/0 |
**Empfehlungen für Sicherheitsgruppenregeln für eingehenden und ausgehenden Datenverkehr für den ausgehenden Resolver-Endpunkt**
****
|
|
| **Regeln für eingehenden Datenverkehr** |
| --- |
| Protokolltyp | Port-Nummer | Quell-IP |
| TCP | Alle | 0.0.0.0/0 |
| UDP | Alle | 0.0.0.0/0 |
| **Regeln für den Ausgang** |
| --- |
| Protokolltyp | Port-Nummer | Ziel-IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**Anmerkung**
**Port-Anforderungen für Sicherheitsgruppen:**
Für **eingehende Endpunkte** sind Eingangsregeln erforderlich, die es TCP und UDP auf Port 53 ermöglichen, DNS-Anfragen von Ihrem Netzwerk zu empfangen. Ausgangsregeln können alle Ports zulassen, da der Endpunkt möglicherweise auf Anfragen von verschiedenen Quellports antworten muss.
Für **ausgehende Endpunkte** sind Ausgangsregeln erforderlich, die den TCP- und UDP-Zugriff auf die Ports ermöglichen, die Sie für DNS-Abfragen in Ihrem Netzwerk verwenden. Port 53 wird im obigen Beispiel gezeigt, da es sich um den gängigsten DNS-Port handelt, Ihr Netzwerk jedoch möglicherweise andere Ports verwendet. Durch Eingangsregeln können alle Ports Antworten von Ihren DNS-Servern aufnehmen.
**Resolver-Endpunkt**
Bei Clients, die einen eingehenden Resolverendpunkt verwenden, wird die Kapazität der elastic network interface beeinträchtigt, wenn Sie über 40.000 eindeutige IP-Adress- und Portkombinationen verfügen, die den DNS-Datenverkehr generieren.
# Hohe Verfügbarkeit für Resolver-Endpunkt
Wenn Sie Ihre eingehenden VPC-Resolver-Endpunkte erstellen, erfordert Route 53, dass Sie mindestens zwei IP-Adressen erstellen, an die die DNS-Resolver in Ihrem Netzwerk Anfragen weiterleiten. Sie sollten zu Redundanzzwecken auch IP-Adressen in mindestens zwei Availability Zones angeben.
Wenn Sie benötigen, dass immer mehr als ein Endpunkt der elastic network interface verfügbar ist, empfehlen wir, mindestens eine weitere Netzwerkschnittstelle zu erstellen, als Sie benötigen, um sicherzustellen, dass zusätzliche Kapazitäten für die Handhabung möglicher Überspannungen verfügbar sind. Die zusätzliche Netzwerkschnittstelle stellt auch die Verfügbarkeit während des Servicebetriebs wie Wartung oder Upgrades sicher.
Weitere Informationen finden Sie in diesem ausführlichen Blogartikel: [So erreichen Sie DNS-Hochverfügbarkeit mit](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) Resolver-Endpunkten und. [Werte, die Sie beim Erstellen oder Bearbeiten von eingehenden Endpunkten angeben](resolver-forwarding-inbound-queries-values.md)
# Gehen Sie zur DNS-Zone
Ein DNS-Zonenangriff versucht, alle Inhalte von DNSSEC-signierten DNS-Zonen abzurufen. Wenn das VPC-Resolver-Team ein Datenverkehrsmuster erkennt, das mit denen übereinstimmt, die beim Durchlaufen von DNS-Zonen auf Ihrem Endpunkt generiert wurden, drosselt das Service-Team den Verkehr auf Ihrem Endpunkt. Als Konsequenz können Sie einen hohen Prozentsatz Ihrer DNS-Abfragen beobachten, der Timeout ist.
Wenn Sie eine verringerte Kapazität auf Ihren Endpunkten feststellen und glauben, dass der Endpunkt irrtümlich gedrosselt wurde, gehen Sie zu home\$1/, um einen Support-Fall zu https://console.aws.amazon.com/support/ erstellen.
# Bewährte Methoden für Amazon Route 53 Zustandsprüfungen
Eine effektive Konfiguration der Systemdiagnose ist für die Aufrechterhaltung einer hochverfügbaren und ausfallsicheren Infrastruktur unerlässlich. Im Folgenden finden Sie einige bewährte Methoden, die Sie bei der Einrichtung und Verwaltung von Amazon Route 53-Zustandsprüfungen berücksichtigen sollten:
1. **Verwenden Sie elastische IP-Adressen für Endpunkte zur Zustandsprüfung:**
+ Verwenden Sie elastische IP-Adressen für Ihre Health Check-Endpunkte, um eine konsistente Überwachung zu gewährleisten.
+ Wenn Sie keine Amazon EC2 EC2-Instance mehr verwenden, denken Sie daran, alle zugehörigen Zustandsprüfungen zu löschen, um potenzielle Sicherheitsrisiken oder Datenkompromittierungen zu vermeiden.
Weitere Informationen finden Sie unter[Werte, die Sie beim Erstellen oder Aktualisieren von Zustandsprüfungen festlegen](health-checks-creating-values.md).
1. **Konfigurieren Sie die entsprechenden Intervalle für Integritätsprüfungen:**
+ Legen Sie Intervalle für Integritätsprüfungen auf der Grundlage der Anforderungen Ihrer Anwendung und der Wichtigkeit der überwachten Ressourcen fest.
+ Kürzere Intervalle ermöglichen eine schnellere Fehlererkennung, können jedoch die Kosten für Route 53 erhöhen und Ihre Ressourcen belasten.
+ Längere Intervalle reduzieren die Kosten und die Ressourcenbelastung, können jedoch die Fehlererkennung verzögern.
Weitere Informationen finden Sie unter[Erweiterte Konfiguration (nur "Monitor an endpoint")](health-checks-creating-values.md#health-checks-creating-values-advanced).
1. **Implementieren Sie Alarmbenachrichtigungen:**
+ Konfigurieren Sie Amazon so CloudWatchalarms , dass es Benachrichtigungen erhält, wenn Zustandsprüfungen fehlschlagen oder wiederhergestellt werden.
+ Legen Sie je nach den Anforderungen Ihrer Anwendung und dem erwarteten Verhalten Ihrer Ressourcen geeignete Alarmschwellenwerte fest.
+ Integrieren Sie Benachrichtigungen in Ihre Überwachungs- und Reaktionsprozesse.
Weitere Informationen finden Sie unter[Überwachung von Zustandsprüfungen mit CloudWatch](monitoring-health-checks.md).
1. **Nutzen Sie Regionen mit Gesundheitscheck strategisch:**
+ Wählen Sie die Health Check-Regionen auf der Grundlage der geografischen Verteilung Ihrer Benutzer und Ressourcen aus.
+ Erwägen Sie die Verwendung mehrerer Regionen mit Gesundheitschecks für wichtige Ressourcen, um die Zuverlässigkeit zu erhöhen und die Auswirkungen regionaler Ausfälle zu verringern.
1. **Überwachen Sie die Protokolle und Metriken der Gesundheitschecks:**
+ Überprüfen Sie regelmäßig die Protokolle und CloudWatch Metriken der Route 53-Zustandsprüfungen, um potenzielle Probleme oder Leistungsengpässe zu identifizieren
+ Analysieren Sie die Gründe für Fehlschläge bei der Zustandsprüfung und ergreifen Sie geeignete Maßnahmen, um die zugrunde liegenden Probleme zu lösen.
1. **Implementieren Sie Failover- und Failback-Strategien:**
+ Nutzen Sie die Failover-Routing-Richtlinien von Route 53, um den Datenverkehr bei Ausfällen automatisch an fehlerfreie Ressourcen weiterzuleiten.
+ Planen und testen Sie Failover- und Failback-Prozesse, um einen reibungslosen Übergang bei Ausfällen und bei der Wiederherstellung sicherzustellen.
Weitere Informationen finden Sie unter. [Konfigurieren von DNS Failover](dns-failover-configuring.md)
1. **Überprüfen und aktualisieren Sie regelmäßig die Gesundheitschecks:**
+ Aktualisieren Sie die Endpunkte, Intervalle und Alarmschwellenwerte für Integritätsprüfungen nach Bedarf, um eine optimale Überwachung und Leistung aufrechtzuerhalten.
Wenn Sie diese Best Practices befolgen, können Sie Amazon Route 53 Health Checks effektiv nutzen, um den Zustand und die Verfügbarkeit Ihrer Ressourcen zu überwachen und so eine zuverlässige und leistungsstarke Infrastruktur für Ihre Anwendungen und Services sicherzustellen.