Amazon ANS-C01: DNS en Route 53 — Studiegids

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

Onderdeel van de AWS Advanced Networking Specialty ANS-C01 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Kernconcept

DNS is de lijm tussen mensvriendelijke namen en gedistribueerde endpoints, maar in AWS wordt het een actief controlepaneel voor op latency gebaseerde routing, statusbewuste failover en private naamresolutie over meerdere accounts heen. Amazon Route 53 ondersteunt authoritatieve publieke DNS via public hosted zones en private DNS voor VPC-specifieke resolutie via private hosted zones. Private hosted zones zijn gekoppeld aan een of meer VPC’s en geven alleen antwoord op query’s die afkomstig zijn uit die VPC’s of via Route 53 Resolver inbound endpoints. Dit split-horizon-gedrag—verschillende antwoorden geven voor dezelfde naam, afhankelijk van de bron—stelt u in staat een publiek endpoint beschikbaar te maken voor internetclients, terwijl u dezelfde naam omzet naar private IP-adressen binnen uw VPC’s.

Route 53 integreert ook logica voor routeringsbeslissingen en actieve health checks in DNS. Routeringsbeleidsregels (routing policies) omvatten Simple, Weighted, Latency, Failover (primary/secondary), Geolocation en Multi-Value Answer, en Traffic Flow (geoproximity en complexe flows). Health checks die zijn aangemaakt met

undefined

stellen Route 53 in staat om ongezonde endpoints uit DNS-antwoorden te verwijderen of failover record sets aan te sturen; health checks zijn configureerbaar met

undefined

-velden zoals

undefined

. Omdat DNS wordt gecachet door resolvers en clients, moeten de TTL van Route 53 en de frequente polling van health checks (minimaal 10 seconden onder specifieke instellingen) worden afgewogen tegen het DNS-propagatiegedrag voor failover en wijzigingen in weighted routing.

Belangrijkste services en configuratie

Gebruik bij het beschikbaar stellen van AWS-resources Alias records om DNS direct naar ondersteunde AWS-resources te laten verwijzen, waardoor extra hops of CNAMEs worden vermeden. Alias records gebruiken een

undefined

die verwijst naar de hosted zone ID en DNS-naam van de AWS-resource (bijvoorbeeld een Elastic Load Balancer, API Gateway custom domain, CloudFront-distributie of S3-website-endpoint). Het aanmaken of wijzigen van records gebeurt via de

undefined

API; gebruik voor programmatische workflows

undefined

met

undefined

-acties en

undefined

voor de identificatie van het routeringsbeleid. Voor failover maakt u twee records aan met dezelfde naam en

undefined

ingesteld op

undefined

, die elk verwijzen naar een health check via

undefined

die u aanmaakt met

undefined

Voor cross-account en hybride DNS-resolutie biedt Route 53 Resolver inbound en outbound endpoints die worden aangemaakt met

undefined

. Een inbound endpoint stelt on-premises resolvers in staat om query’s door te sturen naar VPC’s (nuttig voor het resolven van private hosted zones), terwijl een outbound endpoint VPC-resources in staat stelt om query’s door te sturen naar on-premises DNS-servers of andere resolvers. Met Resolver rules (

undefined

) kunt u query’s voor specifieke domeinen doorsturen naar IP-adressen en u koppelt deze regels aan VPC’s met behulp van

undefined

. Voor een centrale DNS-architectuur kunt u forwarding rules aanmaken in een centraal account en deze met

undefined

koppelen aan VPC’s in andere accounts, waarbij u optioneel AWS Resource Access Manager (RAM) en

undefined

gebruikt om de koppelingen te beheren.

Route 53 Resolver DNS Firewall biedt op domeinen gebaseerde filtering en logging. U maakt domeinlijsten aan met

undefined

, regelgroepen met

undefined

, en koppelt deze vervolgens met

undefined

aan VPC’s om de regels af te dwingen. Firewall-regels kunnen antwoorden

undefined

, en u kunt evaluaties loggen naar CloudWatch Logs of S3. Gebruik

undefined

voor beheer en om geprioriteerde regels toe te passen, met name om exfiltratie via DNS te beperken of om kwaadaardige domeinen te blokkeren voor resources die aan een VPC zijn gekoppeld.

Ontwerppatronen en afwegingen

Gebruik voor hoog beschikbare, wereldwijd gedistribueerde services op latency of geolocatie gebaseerde routing om clients naar het dichtstbijzijnde gezonde endpoint te sturen, in combinatie met health checks om ongezonde regionale endpoints te verwijderen. Latency routing is afhankelijk van de regionale latency-tabellen van Route 53 en is geschikt voor multi-region active-active ontwerpen; failover routing is beter voor active-passive disaster recovery waarbij slechts één regio tegelijk verkeer mag ontvangen. Weighted routing ondersteunt geleidelijke verkeersverschuivingen (blue-green of canary deployments) door gewichtswaarden toe te kennen aan records en deze te wijzigen met

undefined

. Multi-value answer routing kan meerdere IP-adressen retourneren voor client-side load distribution en vereist health checks om ervoor te zorgen dat alleen gezonde IP-adressen worden teruggegeven.

Private hosted zones en resolver endpoints zijn de canonieke patronen voor naamresolutie over meerdere accounts en VPC’s. Voor veel bedrijfsonderdelen vereenvoudigt een centrale shared services VPC die private hosted zones of resolver endpoints host het beheer: maak een private hosted zone aan en gebruik

undefined

om de service-VPC’s te koppelen, of gebruik Route 53 Resolver outbound/inbound endpoints en forwarding rules zodat elk account zijn VPC-isolatie behoudt terwijl het vertrouwt op centraal DNS-beleid. De afweging is dat private hosted zones die aan veel VPC’s zijn gekoppeld, IAM en change control compliceren, en dat voor cross-account koppelingen een autorisatiestap vereist is. Resolver forwarding introduceert centrale operationele overhead, maar schaalt goed omdat u niet elke VPC rechtstreeks aan elke hosted zone hoeft te koppelen; in plaats daarvan koppelt u resolver rules.

Bij het afdwingen van strikte toegangspaden—zoals eisen dat verkeer alleen via Global Accelerator loopt—moet u de security group en netwerkcontroles zo ontwerpen dat ze overeenkomen met DNS. Route 53 kan naar Global Accelerator verwijzen door A-records aan te maken met de statische IP-adressen van de accelerator of door CNAMEs te gebruiken naar een door de accelerator beheerd domein, maar de handhaving vindt plaats op het niveau van de ALB security group en de network ACL. De ALB security group zou alleen inkomend verkeer moeten toestaan vanaf de statische IP-adressen van Global Accelerator; Global Accelerator garandeert dat die statische IP’s de bron zullen zijn voor inkomend verkeer, dus het beperken van inkomend verkeer handhaaft de vereiste dat toegang alleen via de accelerator mogelijk is.

Veelvoorkomende valkuilen en beslissingscriteria

Een typische valkuil is de aanname dat Route 53 health checks endpoints onmiddellijk verwijderen; door DNS-caching (TTL) en het gedrag van de client resolver is failover niet ogenblikkelijk. Houd TTL’s laag voor kritieke failover-namen, maar onthoud dat lagere TTL’s het queryvolume en de kosten verhogen. Een andere veelgemaakte fout is het dupliceren van namen over publieke en private hosted zones zonder de VPC-associaties te begrijpen: een private hosted zone met dezelfde naam als een publieke hosted zone zal publieke antwoorden overschaduwen voor queries die afkomstig zijn uit geassocieerde VPC’s. Dit is meestal wenselijk voor split-horizon, maar kan verrassend zijn als het niet gedocumenteerd is.

Kies zorgvuldig tussen Alias- en CNAME-records: Alias-records voor ELB en CloudFront hebben de voorkeur omdat ze extra DNS-lookups vermijden en worden ondersteund door de change propagation-logica van Route 53, maar ze zijn gekoppeld aan de hosted zone-ID’s van AWS-resources en kunnen niet worden gebruikt voor willekeurige externe endpoints. Geef bij het ontwerpen van cross-account DNS de voorkeur aan resolver rules en endpoints boven het direct associëren van veel VPC’s met één enkele private hosted zone wanneer schaalbaarheid of administratieve grenzen een rol spelen; resolver rules bieden meer granulaire controle en zijn eenvoudiger te auditen met CloudTrail.

Praktijkprobleem: Gebruiksscenario

Bedrijf: NimbusPay — uitdaging: Bied veilige, low-latency gRPC-services via TLS met mutual TLS aan een EKS-backend, dwing af dat de web front-end alleen toegankelijk is via Global Accelerator, en sta toe dat VPC’s van meerdere business-units over verschillende accounts gedeelde dataservices kunnen gebruiken met gecentraliseerde DNS-controles.

Voor de gRPC-service die end-to-end TLS met mutual authentication en duizenden gelijktijdige verbindingen vereist, implementeer een Network Load Balancer (NLB) met TCP-listeners op poort 443 met target type ip, zodat pod-IP’s direct worden geregistreerd. Configureer de AWS Load Balancer Controller-annotaties service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” en stel het target group-protocol in op TCP; beëindig TLS niet op de NLB (geen TLS-listener), zodat mutual TLS wordt doorgelaten naar de pod-containers waar servercertificaten en de verificatie van clientcertificaten worden afgehandeld. Gebruik Route 53 A-records (Alias) die via ChangeResourceRecordSets naar de NLB verwijzen; geef alleen de voorkeur aan lage TTL’s als je snelle failover nodig hebt, anders behoud je een conservatieve TTL voor DNS-stabiliteit.
Om ervoor te zorgen dat de web front-end ALB alleen verkeer van Global Accelerator accepteert, provisioneer een accelerator en wijs de twee statische IP-adressen toe aan NimbusPay. Configureer publieke Route 53-records om de publieke naam te resolven naar de IP-adressen van de accelerator (A-records met de statische IP’s). Stel op de ALB de ingress-regels van de security group zo in dat alleen die statische IP-adressen worden toegestaan en sluit 0.0.0.0/0. Dit dwingt af dat alleen verkeer dat via de statische IP’s van de accelerator binnenkomt de ALB kan bereiken. Gebruik CloudWatch Logs en VPC Flow Logs om inkomende bron-IP’s te valideren en te auditen dat verkeer dat niet van de accelerator afkomstig is, wordt geblokkeerd.
Voor VPC’s van meerdere business-units over verschillende accounts die toegang nodig hebben tot gedeelde services, implementeer een centraal Route 53 Resolver outbound/inbound endpoint-paar in het shared services-account met behulp van CreateResolverEndpoint en plaats de endpoints in private subnets. Maak forwarding rules (CreateResolverRule) aan in het gedeelde account voor de domeinen van de gedeelde services en deel de rules met AWS RAM of gebruik PutResolverRulePolicy om associaties toe te staan. Elke business-unit associeert de resolver rule met hun VPC’s (AssociateResolverRule), wat naamresolutie mogelijk maakt zonder alle VPC’s direct aan private hosted zones te koppelen. Voor gevoelige controles, koppel Route 53 Resolver DNS Firewall rule groups (CreateFirewallRuleGroup en AssociateFirewallRuleGroup) aan de gedeelde VPC om ongewenste exfiltratie te blokkeren of om domein-allowlists af te dwingen. De redenering: NLB TCP passthrough behoudt mutual TLS en schaalt naar veel gelijktijdige verbindingen, het beperken van ALB-ingress tot de statische IP’s van Global Accelerator dwingt toegang-alleen-via-accelerator af, en resolver endpoints met centraal beheerde rules schalen DNS-resolutie over accounts heen, terwijl per-account IAM-grenzen en auditing behouden blijven.

← Transit Gateway en Netwerktopologie · Alle domeinen · Load Balancing en Verkeersbeheer →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →