Een netwerkengineer heeft de TTL van verschillende records in een openbare hosted zone voor example.com verlaagd naar 60 seconden. De engineer wil controleren of deze wijziging het aantal DNS-query's naar Route 53 boven de verwachte niveaus heeft verhoogd door het aantal query's voor de example.com hosted zone op te vragen. Welke benadering biedt die informatie?

De correcte benadering is om Amazon CloudWatch te gebruiken en de DNSQueries metric binnen de AWS/Route 53 namespace te controleren. Deze metric is specifiek ontworpen om het aantal DNS-query's te meten dat Route 53 ontvangt voor een hosted zone. Een verlaagde TTL zal leiden tot meer frequente query's, wat direct zichtbaar moet zijn in deze metric. Het aanmaken van een CloudTrail-trail voor data events is te gedetailleerd en genereert veel loggegevens die niet direct de query-telling bieden die nodig is. CloudTrail richt zich op API-activiteit, niet op DNS-query's. De AWS/Route 53 Resolver namespace en de InboundQueryVolume metric zijn relevant voor Route 53 Resolver-endpoints, niet voor algemene query's naar een openbare hosted zone. Het configureren van logging naar CloudWatch voor de hosted zone is mogelijk, maar de DNSQueries metric is een ingebouwde, direct beschikbare metric die geen extra configuratie of filtering vereist om het totale aantal query's te tonen.