← Blog  ·  October 2026

AWS Route 53 DNS Monitoring: Alert on Record Changes and Propagation

CloudTrail tells you what changed. External monitoring confirms what your users actually see.

AWS Route 53 is a highly reliable DNS service, but "reliable infrastructure" doesn't mean "your DNS records are protected from accidental or unauthorized changes." A team member with Route53 access can modify or delete a record in seconds. A Terraform misconfiguration can overwrite an A record during a deployment. An IAM policy that's too permissive lets a compromised service account make DNS changes without an alert firing.

Route 53 has more native observability than most DNS providers — CloudTrail logs every API call, and EventBridge can react to changes. This article covers how to use those tools and where external DNS monitoring fills the remaining gaps.

Route 53 change monitoring via CloudTrail

Every Route 53 change is recorded in CloudTrail as a route53.amazonaws.com event. The relevant API calls to watch:

• ChangeResourceRecordSets — any record add, update, or delete
• DeleteHostedZone — zone deletion (catastrophic)
• CreateHostedZone — new zone creation
• AssociateVPCWithHostedZone — private zone association changes

To see recent DNS changes in CloudTrail via CLI:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=route53.amazonaws.com \
  --start-time 2026-10-01 \
  --query 'Events[?EventName==`ChangeResourceRecordSets`].[EventTime,Username,CloudTrailEvent]' \
  --output table

CloudTrail has up to 90 days of event history in the console (and indefinitely if shipped to S3). The limitation: it's a log, not an alert system. You get visibility into what changed, not a real-time notification when a change occurs.

Real-time alerts with EventBridge

EventBridge can trigger a Lambda function or SNS notification whenever Route 53 records change. The setup:

1. Create an EventBridge rule for Route 53 changes

aws events put-rule \
  --name "route53-record-changes" \
  --event-pattern '{
    "source": ["aws.route53"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventSource": ["route53.amazonaws.com"],
      "eventName": ["ChangeResourceRecordSets"]
    }
  }' \
  --state ENABLED

2. Create an SNS topic for alerts

aws sns create-topic --name route53-dns-changes
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:ACCOUNT_ID:route53-dns-changes \
  --protocol email \
  --notification-endpoint ops@yourcompany.com

3. Add the SNS topic as the EventBridge target

aws events put-targets \
  --rule route53-record-changes \
  --targets '[{
    "Id": "1",
    "Arn": "arn:aws:sns:us-east-1:ACCOUNT_ID:route53-dns-changes",
    "InputTransformer": {
      "InputPathsMap": {
        "user": "$.detail.userIdentity.arn",
        "zone": "$.detail.requestParameters.hostedZoneId",
        "action": "$.detail.requestParameters.changeBatch.changes[0].action",
        "record": "$.detail.requestParameters.changeBatch.changes[0].resourceRecordSet.name"
      },
      "InputTemplate": "\"DNS change in Route 53 zone :  on  (by )\""
    }
  }]'

This setup fires an SNS email the moment ChangeResourceRecordSets is called, with the zone ID, record name, and the IAM principal that made the change. It catches changes made via the AWS Console, CLI, Terraform, CDK, and any other AWS API client.

What CloudTrail + EventBridge doesn't cover

The EventBridge approach covers internal AWS changes. It doesn't cover:

• Propagation verification. Route 53 confirms a change was applied — but DNS propagation to global resolvers takes time. A change might be in Route 53's authoritative servers but not yet visible to resolvers in Europe or Asia. External monitoring from multiple locations catches propagation delays and partial propagation states.
• Third-party DNS changes. If you use Route 53 for some records but delegate subdomains to other nameservers, changes in those delegated zones don't appear in CloudTrail.
• Resolver behavior vs. authoritative response. Route 53 might return the correct record, but a downstream resolver might return a cached old value for the full TTL duration. External DNS checks query resolvers, not just authoritative servers — which is what your users are actually hitting.
• Dangling records. A CNAME pointing to a deprovisioned resource (an old EC2 instance, a deleted S3 bucket endpoint, a deprecated CloudFront distribution) is valid DNS — Route 53 has no idea the target is gone. External monitoring that validates the target responds correctly catches subdomain takeover vectors.

A practical Route 53 DNS monitoring stack

A complete setup for a Route 53 environment typically combines three layers:

1. EventBridge → SNS for real-time change alerts (covers: who changed what, when, from which identity)
2. CloudTrail → S3 for audit history (covers: full record of all changes for compliance and incident response)
3. External DNS monitoring for resolver-level validation (covers: propagation verification, dangling records, third-party delegation zones, cross-region resolver behavior)

Layers 1 and 2 come from AWS natively. Layer 3 requires checking from outside AWS.

Check your Route 53 records from outside AWS right now

Monitoring Route 53 without the AWS setup overhead

The EventBridge + CloudTrail setup gives you good coverage but has non-trivial setup cost: IAM policies, cross-region considerations for Route 53 events, Lambda or SNS wiring, and ongoing maintenance of the alerting infrastructure itself.

For teams that want DNS change alerts without building and maintaining AWS infrastructure, external DNS monitoring services poll your records on a schedule and alert on changes — without requiring AWS credentials or internal infrastructure.