Amazon Route 53 Health Check
Does ZopNight manage Amazon Route 53 Health Check?
Route 53 health checks bill per check per month, with surcharges for HTTPS, string matching, and fast 10-second intervals. Checks pointing at endpoints that were deleted keep billing until someone removes them. ZopNight inventories every health check on the 6-hour cycle and has a cleanup rule (RC-1525), not yet switched on, for failing checks that no record set references.
Rules that fire on Amazon Route 53 Health Check
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
A Route 53 health check monitors endpoint availability for DNS failover, billed per check per month with surcharges for HTTPS and fast intervals. Health checks pointing at deleted endpoints keep billing until removed.
Small meter, optional-feature surcharges
Each health check bills a flat monthly amount, with the rate stepping up for optional features: HTTPS probing, string matching on the response body, and the fast 10-second check interval instead of the standard 30 seconds. Checks against non-AWS endpoints price higher than checks against AWS-hosted ones. No single check is expensive; the meter matters because checks are created programmatically (by DNS failover setups, by infrastructure templates, by monitoring integrations) and each one bills monthly forever.
Orphan detection through ZopNight
A dedicated provider discovers every health check on the 6-hour cycle, with per-check cost drawn from Cost Explorer or CUR 2.0. The cleanup recommendation (RC-1525), not yet switched on, targets checks that are failing and that no Route 53 record set references for failover. Such checks keep billing and, worse, keep alarming, since a check against a deleted endpoint reports unhealthy indefinitely and trains people to ignore health notifications.
How checks outlive their endpoints
Failover architectures get dismantled one half at a time: the standby endpoint goes away, its health check stays. Terraform stacks that created checks get destroyed with lifecycle exceptions, or the checks were clicked into existence outside the stack. And CloudWatch alarms built on health-check status keep the whole chain looking load-bearing after the underlying service moved behind an ALB with its own health model.
Reviewing health checks and their targets
Route 53’s console has a Health checks view listing every check with its endpoint, protocol, interval, and status. Persistent unhealthy status is the tell worth sorting by. A check that has failed for months is watching something that no longer exists. Before deleting, confirm no failover record or alarm still references the check ID.