Amazon Route 53

What is Route 53?

Route 53 is AWS’s managed DNS: it hosts your zones, answers queries from a global anycast fleet, and registers domains. Two features elevate it beyond commodity DNS. Alias records map zone apexes (example.com, where CNAMEs are forbidden) directly to AWS resources — ALBs, CloudFront, S3 — resolving to current IPs with no lookup charge. Routing policies make DNS itself a traffic-steering layer.

Routing policies in practice

Weighted routing splits traffic by percentage — the poor man’s canary and the standard blue/green switch. Latency-based sends users to the lowest-latency region among your deployments. Failover pairs a primary record with a health check and flips to a standby on failure. Geolocation/geoproximity pin jurisdictions to regions (data-residency compliance via DNS). Combined with health checks — Route 53 probes endpoints globally and withdraws unhealthy records — you get DNS-level failover measured in tens of seconds… bounded below by one hard constraint: TTL. Failover cannot beat the TTL cached in resolvers worldwide, which is why failover-critical records run TTLs of 30–60 s, trading query volume for agility.

The details that page people at 3 a.m.

Health checks see your endpoint from the public internet — private-only resources need calculated or metric-based checks. Alias-to-ALB failover depends on the ALB’s own health; layering both without understanding which triggers first produces confusing flaps. And DNS failover is eventually consistent by nature: some resolvers ignore low TTLs, so a fraction of traffic lingers on the failed side — design backends to reject gracefully rather than assuming instant cutover.

What people get wrong

• 24-hour TTLs on records you might need to move — set low TTLs before the migration, days ahead.
• Weighted routing without session affinity thinking: users bounce between versions on every resolution.
• Treating the 100% SLA as “DNS can’t be my outage” — misconfiguration isn’t covered by anyone’s SLA.

Primary source: Amazon Route 53 documentation

Health Checks as the Foundation for Automated Failover

Route 53’s various routing policies — latency-based, weighted, geolocation, failover — all depend on an underlying health check system that continuously monitors the availability of configured endpoints, automatically excluding unhealthy endpoints from DNS responses without requiring manual intervention. This is what elevates Route 53 from a simple DNS lookup service into an active component of an application’s availability architecture: a failover routing policy combined with health checks can automatically redirect all traffic to a backup region within the time it takes health checks to detect an outage and DNS caches to expire, providing automated disaster recovery capability that operates independently of any application-level failover logic.