Do Route 53 health checks monitor my DNS records?

No. They monitor whether the endpoints your records point to are reachable. To watch the correctness of the records themselves, you need query logging plus external, outside-in monitoring for drift.

Where do Route 53 health check metrics live in CloudWatch?

In the us-east-1 region, regardless of where your actual resources run. If an alarm can't find HealthCheckStatus, that region mismatch is almost always why.

Can Route 53 alert me if my domain is about to expire?

Not for the registration itself. Auto-renew reduces the risk, but a failed payment or an externally managed domain can still lapse, so domain expiry monitoring is a separate layer.

How to Set Up DNS Monitoring in AWS Route 53

VigilDog Team · October 16, 2026 · 6 min read

Route 53 is two products wearing one name: a domain registrar and an authoritative DNS service. Neither half will proactively tell you when something goes wrong. Setting up real Route 53 DNS monitoring means assembling a few AWS primitives into something that watches both your endpoints and your configuration, and knowing where that leaves gaps.

What DNS monitoring means in Route 53, and what it doesn't

It helps to separate two questions before you configure anything. First: are the things my DNS records point to still alive? That is endpoint health, and it is what Route 53 health checks are built for. Second: are the records themselves still correct and unchanged? That is drift, and Route 53 barely addresses it.

Conflating the two is why teams believe they have monitoring when they only have half of it. A health check will happily report green while an MX record is pointing at the wrong host, because the host it points to is up. Keep the endpoint question and the configuration question in separate buckets, and build for both.

How a domain name resolves to a server

Set up a Route 53 health check

In the Route 53 console, open Health checks and choose Create health check. Select Endpoint, then specify the target by IP address or domain name, pick the protocol (HTTP, HTTPS, or TCP), and set the port and path. For HTTP and HTTPS you can enable string matching, so the check fails unless the response body contains an expected token, that catches a page returning 200 while actually being broken.

Set the request interval (30 seconds standard, or 10 seconds fast) and the failure threshold, how many consecutive failures flip the check to Unhealthy. Route 53 probes from multiple global locations and only marks a check unhealthy when a majority of those checkers agree, which filters out single-region blips. For anything with several moving parts, a calculated health check can combine child checks with boolean logic.

Type: Endpoint (by IP or domain), or Calculated to combine several checks
Protocol and path: HTTP/HTTPS/TCP, with optional response string matching
Interval and threshold: 30s or 10s, plus consecutive-failure count to trip it

Alarm on health checks with CloudWatch and SNS

A health check on its own only changes DNS failover behavior. To actually get notified, you attach CloudWatch. One detail trips everyone up: Route 53 health check metrics like HealthCheckStatus and HealthCheckPercentageHealthy live in the us-east-1 region regardless of where your infrastructure runs, so if your alarm can't find the metric, switch regions.

Create a CloudWatch alarm on HealthCheckStatus (1 = healthy, 0 = unhealthy) with a threshold below 1, and point its action at an SNS topic. Subscribe an email address, or wire the topic to a Lambda or chatbot integration for Slack. Now an endpoint going dark pages you instead of silently failing over in the background.

See what is actually being resolved: query logging

Health checks tell you about the targets; query logging tells you about the lookups. For a public hosted zone you can enable DNS query logging, which streams every query Route 53 answers into a CloudWatch Logs group. That lets you notice a sudden drop in queries for a hostname, often a sign that upstream config changed, or unexpected queries for records that should not exist.

Query logs double as an audit trail. Pair them with CloudWatch Logs metric filters to alarm on patterns, such as a spike in NXDOMAIN responses. Note this is distinct from Resolver query logging, which covers outbound queries from resources inside a VPC; for authoritative record monitoring you want the public hosted zone logs. If you just need a quick sanity check of what resolves right now, the DNS checker answers that with no setup at all.

The gap Route 53 leaves: drift, records, and expiry

Here is what none of the above catches. If someone edits an MX record, swaps a TXT/SPF value, changes your NS delegation, or a DNSSEC signature goes stale, your health checks stay green, the endpoints are fine, the configuration is wrong. Route 53 has no built-in 'alert me when this record's contents change.' Knowing which records carry which risk is worth a refresher in DNS records explained.

The registrar side has its own blind spot: domain expiry. Auto-renew helps, but a failed payment method or a domain managed outside AWS can still lapse, and that is a total outage no health check will predict. A quick look with the domain expiry checker shows how close any domain is to the edge.

The pattern that actually holds is layered: use Route 53's native health checks for endpoint uptime, and add outside-in monitoring that watches the records, certificates, and registration for unexpected change. AWS is watching whether your servers answer; something needs to watch whether your DNS still says what you meant it to say.