Amazon ANS-C01: DNS und Route 53 — Lernleitfaden

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Teil des AWS Advanced Networking Specialty ANS-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Grundkonzept

DNS ist das Bindeglied zwischen für Menschen lesbaren Namen und verteilten Endpunkten, aber in AWS wird es zu einer aktiven Steuerungsebene für latenzbasiertes Routing, zustandsabhängiges Failover und private Namensauflösung über mehrere Konten hinweg. Amazon Route 53 unterstützt autoritatives öffentliches DNS über öffentliche gehostete Zonen und privates DNS für die VPC-bezogene Auflösung über private gehostete Zonen. Private gehostete Zonen sind mit einer oder mehreren VPCs verknüpft und geben nur Antworten auf Anfragen zurück, die aus diesen VPCs oder über eingehende Endpunkte des Route 53 Resolver stammen. Dieses Split-Horizon-Verhalten – unterschiedliche Antworten für denselben Namen je nach Quelle – ermöglicht es Ihnen, einen öffentlichen Endpunkt für Internet-Clients bereitzustellen, während derselbe Name innerhalb Ihrer VPCs zu privaten IPs aufgelöst wird.

Route 53 integriert auch Routing-Entscheidungslogik und aktive Zustandsprüfungen in das DNS. Zu den Routing-Richtlinien gehören Simple, Weighted, Latency, Failover (primär/sekundär), Geolocation und Multi-Value Answer sowie Traffic Flow (Geoproximity und komplexe Abläufe). Zustandsprüfungen, die mit CreateHealthCheck erstellt werden, ermöglichen es Route 53, fehlerhafte Endpunkte aus DNS-Antworten zu entfernen oder Failover-Record-Sets zu steuern; Zustandsprüfungen sind mit HealthCheckConfig-Feldern wie Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval und FailureThreshold konfigurierbar. Da DNS von Resolvern und Clients zwischengespeichert wird, müssen die TTL von Route 53 und das häufige Abfragen von Zustandsprüfungen (mindestens 10 Sekunden unter bestimmten Einstellungen) mit dem DNS-Propagierungsverhalten für Failover- und gewichtete Routing-Änderungen abgewogen werden.

Wichtige Dienste und Konfiguration

Wenn Sie AWS-Ressourcen verfügbar machen, verwenden Sie Alias-Records, um DNS direkt auf unterstützte AWS-Ressourcen zu verweisen und so zusätzliche Hops oder CNAMEs zu vermeiden. Alias-Records verwenden ein AliasTarget, das auf die Hosted Zone ID und den DNS-Namen der AWS-Ressource verweist (z. B. ein Elastic Load Balancer, eine benutzerdefinierte API Gateway-Domäne, eine CloudFront-Distribution oder ein S3-Website-Endpunkt). Das Erstellen oder Ändern von Records erfolgt über die ChangeResourceRecordSets-API; für programmatische Workflows verwenden Sie ChangeBatch mit UPSERT/DELETE-Aktionen und SetIdentifier zur Identifizierung der Routing-Richtlinie. Für Failover erstellen Sie zwei Records mit demselben Namen und Failover auf PRIMARY und SECONDARY gesetzt, die jeweils über eine HealthCheckId auf eine mit CreateHealthCheck erstellte Zustandsprüfung verweisen.

Für kontoübergreifende und hybride DNS-Auflösung bietet der Route 53 Resolver eingehende und ausgehende Endpunkte, die mit CreateResolverEndpoint erstellt werden. Ein eingehender Endpunkt ermöglicht es lokalen Resolvern, Anfragen an VPCs weiterzuleiten (nützlich zur Auflösung privater gehosteter Zonen), während ein ausgehender Endpunkt es VPC-Ressourcen ermöglicht, Anfragen an lokale DNS-Server oder andere Resolver weiterzuleiten. Resolver-Regeln (CreateResolverRule) ermöglichen es Ihnen, Anfragen für bestimmte Domänen an IP-Adressen weiterzuleiten, und Sie verknüpfen Regeln mit VPCs mithilfe von AssociateResolverRule. Für eine zentrale DNS-Architektur können Sie Weiterleitungsregeln in einem zentralen Konto erstellen und diese mit AssociateResolverRule mit VPCs in anderen Konten verknüpfen, wobei Sie optional AWS Resource Access Manager (RAM) und PutResolverRulePolicy zur Steuerung der Verknüpfungen verwenden können.

Die Route 53 Resolver DNS Firewall bietet domänenbasiertes Filtern und Protokollieren. Sie erstellen Domänenlisten mit CreateFirewallDomainList, Regelgruppen mit CreateFirewallRuleGroup und verknüpfen diese dann mit AssociateFirewallRuleGroup mit VPCs, um Regeln durchzusetzen. Firewall-Regeln können Antworten BLOCK, ALLOW oder OVERWRITE (blockieren, zulassen oder überschreiben), und Sie können die Auswertungen in CloudWatch Logs oder S3 protokollieren. Verwenden Sie CreateFirewallRule und PutFirewallRuleGroupPolicy für die Verwaltung und zur Anwendung priorisierter Regeln, insbesondere um die Exfiltration über DNS zu begrenzen oder bösartige Domänen von an VPCs angebundenen Ressourcen zu blockieren.

Designmuster und Kompromisse

Für hochverfügbare, global verteilte Dienste verwenden Sie latenzbasiertes oder geobasiertes Routing, um Clients zum nächstgelegenen fehlerfreien Endpunkt zu leiten, kombiniert mit Zustandsprüfungen, um fehlerhafte regionale Endpunkte zu entfernen. Latenzbasiertes Routing hängt von den regionalen Latenztabellen von Route 53 ab und eignet sich für aktiv-aktive Designs über mehrere Regionen; Failover-Routing ist besser für die aktiv-passive Notfallwiederherstellung geeignet, bei der immer nur eine Region Datenverkehr empfangen soll. Gewichtetes Routing unterstützt schrittweise Verkehrsverlagerungen (Blue-Green- oder Canary-Deployments), indem Gewichtungswerte den Records zugewiesen und mit ChangeResourceRecordSets geändert werden. Multi-Value-Answer-Routing kann mehrere IPs für die clientseitige Lastverteilung zurückgeben und erfordert Zustandsprüfungen, um sicherzustellen, dass nur fehlerfreie IPs zurückgegeben werden.

Private gehostete Zonen und Resolver-Endpunkte sind die kanonischen Muster für die Namensauflösung über mehrere Konten und VPCs hinweg. Für viele Geschäftsbereiche vereinfacht eine zentrale Shared-Services-VPC, die private gehostete Zonen oder Resolver-Endpunkte hostet, die Verwaltung: Erstellen Sie eine private gehostete Zone und verwenden Sie AssociateVPCWithHostedZone, um die Service-VPCs anzubinden, oder betreiben Sie ausgehende/eingehende Endpunkte des Route 53 Resolver und Weiterleitungsregeln, sodass jedes Konto seine VPC-Isolation beibehält, während es sich auf die zentrale DNS-Richtlinie verlässt. Der Kompromiss besteht darin, dass private gehostete Zonen, die mit vielen VPCs verknüpft sind, das IAM und die Änderungskontrolle verkomplizieren und kontoübergreifende Verknüpfungen einen Autorisierungsschritt erfordern. Die Resolver-Weiterleitung führt zu zentralem Betriebsaufwand, skaliert aber, da Sie nicht jede VPC direkt mit jeder gehosteten Zone verknüpfen müssen; stattdessen verknüpfen Sie Resolver-Regeln.

Wenn Sie strikte Zugriffspfade erzwingen – z. B. indem Sie verlangen, dass der Datenverkehr nur über den Global Accelerator fließt – müssen Sie die Sicherheitsgruppen- und Netzwerkkontrollen so gestalten, dass sie zum DNS passen. Route 53 kann auf den Global Accelerator verweisen, indem A-Records mit den statischen IP-Adressen des Accelerators erstellt oder CNAMEs zu einer vom Accelerator verwalteten Domäne verwendet werden, aber die Durchsetzung erfolgt auf der Ebene der ALB-Sicherheitsgruppe und der Netzwerk-ACL. Die ALB-Sicherheitsgruppe sollte eingehenden Verkehr nur von den statischen IP-Adressen des Global Accelerator zulassen; Global Accelerator garantiert, dass diese statischen IPs die Quelle für eingehenden Verkehr sind, sodass die Begrenzung des eingehenden Verkehrs die Anforderung „Zugriff nur über Accelerator“ aufrechterhält.

Häufige Fallstricke und Entscheidungskriterien

Ein typischer Fallstrick ist die Annahme, dass Route 53 Health Checks Endpunkte sofort entfernen. DNS-Caching (TTL) und das Verhalten von Client-Resolvern bedeuten, dass ein Failover nicht augenblicklich erfolgt. Halten Sie die TTLs für kritische Failover-Namen niedrig, aber denken Sie daran, dass niedrigere TTLs das Abfragevolumen und die Kosten erhöhen. Ein weiterer häufiger Fehler ist die Duplizierung von Namen über öffentliche und private Hosted Zones hinweg, ohne die VPC-Assoziationen zu verstehen: Eine private Hosted Zone mit demselben Namen wie eine öffentliche Hosted Zone überschattet öffentliche Antworten für Abfragen, die aus den zugehörigen VPCs stammen. Dies ist für Split-Horizon-DNS in der Regel erwünscht, kann aber überraschend sein, wenn es nicht dokumentiert ist.

Wählen Sie sorgfältig zwischen Alias- und CNAME-Records: Alias-Records für ELB und CloudFront sind vorzuziehen, da sie zusätzliche DNS-Lookups vermeiden und von der Logik zur Weitergabe von Änderungen in Route 53 unterstützt werden. Sie sind jedoch an die Hosted-Zone-IDs von AWS-Ressourcen gebunden und können nicht für beliebige externe Endpunkte verwendet werden. Beim Entwerfen von kontoübergreifendem DNS sollten Sie Resolver-Regeln und -Endpunkte der direkten Zuordnung vieler VPCs zu einer einzigen privaten Hosted Zone vorziehen, wenn Skalierbarkeit oder administrative Grenzen eine Rolle spielen. Resolver-Regeln ermöglichen eine granularere Steuerung und sind mit CloudTrail leichter zu überprüfen.

Praktisches Problem: Anwendungsfallszenario

Unternehmen: NimbusPay – Herausforderung: Bereitstellung sicherer gRPC-Dienste mit niedriger Latenz über TLS mit Mutual TLS für ein EKS-Backend, Erzwingung des Zugriffs auf das Web-Frontend nur über Global Accelerator und Ermöglichung des Konsums gemeinsamer Datendienste durch VPCs mehrerer Geschäftseinheiten über verschiedene Konten hinweg mit zentralisierter DNS-Steuerung.

Für den gRPC-Dienst, der End-to-End-TLS mit gegenseitiger Authentifizierung und Tausenden von gleichzeitigen Verbindungen erfordert, stellen Sie einen Network Load Balancer (NLB) mit TCP-Listenern auf Port 443 bereit und verwenden Sie den Zieltyp ip, damit die Pod-IPs direkt registriert werden. Konfigurieren Sie die AWS Load Balancer Controller-Annotationen service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" und setzen Sie das Zielgruppenprotokoll auf TCP. Beenden Sie TLS nicht am NLB (kein TLS-Listener), damit Mutual TLS an die Pod-Container weitergeleitet wird, wo Serverzertifikate und die Überprüfung von Client-Zertifikaten erzwungen werden. Verwenden Sie Route 53 A-Records (Alias), die über ChangeResourceRecordSets auf den NLB verweisen. Bevorzugen Sie niedrige TTLs nur, wenn Sie ein schnelles Failover benötigen, andernfalls behalten Sie eine konservative TTL für die DNS-Stabilität bei.
Um sicherzustellen, dass der Web-Frontend-ALB nur Datenverkehr vom Global Accelerator akzeptiert, stellen Sie einen Accelerator bereit und weisen Sie dessen zwei statische IP-Adressen NimbusPay zu. Konfigurieren Sie öffentliche Route 53-Records, um den öffentlichen Namen auf die Accelerator-IPs aufzulösen (A-Records mit den statischen IPs). Legen Sie auf dem ALB die Ingress-Regeln der Sicherheitsgruppe so fest, dass nur diese statischen IP-Adressen zugelassen werden, und schließen Sie 0.0.0.0/0. Dies erzwingt, dass nur Verkehr, der von den statischen IPs des Accelerators kommt, den ALB erreichen kann. Verwenden Sie CloudWatch Logs und VPC Flow Logs, um die eingehenden Quell-IPs zu validieren und zu überprüfen, dass Verkehr, der nicht vom Accelerator kommt, blockiert wird.
Für VPCs mehrerer Geschäftseinheiten über verschiedene Konten hinweg, die Zugriff auf gemeinsam genutzte Dienste benötigen, stellen Sie ein zentrales Paar aus Route 53 Resolver Outbound- und Inbound-Endpunkten im Konto für gemeinsam genutzte Dienste mithilfe von CreateResolverEndpoint bereit und platzieren Sie die Endpunkte in privaten Subnetzen. Erstellen Sie Weiterleitungsregeln (CreateResolverRule) im gemeinsamen Konto für die Domains der gemeinsam genutzten Dienste und teilen Sie die Regeln mithilfe von AWS RAM oder verwenden Sie PutResolverRulePolicy, um Assoziationen zu erlauben. Jede Geschäftseinheit assoziiert die Resolver-Regel mit ihren VPCs (AssociateResolverRule), was die Namensauflösung ermöglicht, ohne alle VPCs direkt an private Hosted Zones anzubinden. Für sensible Kontrollen fügen Sie der gemeinsamen VPC Regelgruppen der Route 53 Resolver DNS Firewall hinzu (CreateFirewallRuleGroup und AssociateFirewallRuleGroup), um unerwünschte Exfiltration zu blockieren oder Domain-Allowlists durchzusetzen. Die Begründung: NLB TCP-Passthrough erhält Mutual TLS und skaliert auf viele gleichzeitige Verbindungen, die Beschränkung des ALB-Ingress auf die statischen IPs des Global Accelerator erzwingt den Zugriff nur über den Accelerator, und Resolver-Endpunkte mit zentral verwalteten Regeln skalieren die DNS-Auflösung über Konten hinweg, während die IAM-Grenzen und die Überprüfungsmöglichkeiten pro Konto erhalten bleiben.