AWS Route 53 Support
Route 53 failover routing and health checks.
DNS failover only works if the health check tests something meaningful and the TTL lets clients move quickly. We design active-passive and active-active setups, make health checks reflect real service health and rehearse the failover before you need it.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You need a standby site or region that takes over when the primary fails
- A failover did not trigger, or triggered when the app was fine
- Users stay on the dead endpoint for minutes after failover
- You need health checks for endpoints in private subnets
- You are moving from manual DNS changes to automatic failover
What you get
- Health checks and failover records in infrastructure as code
- A measured failover and failback test report
- Alarms and notifications for health check status changes
- A runbook for manual override
How we do it
A clear, safe process you can follow along with.
1. Define what healthy means
A check that only tests TCP on port 443 will say healthy while the application returns 500. We create a lightweight health endpoint that verifies critical dependencies without being too fragile.
2. Create the health checks
Route 53 health checkers probe from many locations, so the endpoint must allow their IP ranges. For private resources we use a CloudWatch alarm-based health check instead of an endpoint check.
3. Build primary and secondary records
We create failover records for the same name, one primary and one secondary, each linked to a health check or, for alias records, using Evaluate Target Health.
4. Tune TTL and thresholds
We set a low TTL on the records, choose the health check request interval and failure threshold to balance detection speed against false alarms, and note that some resolvers and clients cache longer than the TTL.
5. Make the standby real
The secondary must be able to take the load: capacity, data replication and configuration are checked, otherwise failover just moves the outage.
6. Test the failover
We deliberately fail the primary health endpoint during a planned window, observe the DNS change and client behavior, and measure real recovery time. We then document failback.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Health check only tests the load balancer
The load balancer can be up while every target behind it is unhealthy.
High TTL
Clients keep using the old answer until it expires, so failover looks broken.
Blocking health checker IPs
A firewall that drops probes marks a healthy endpoint as unhealthy.
Never testing
Untested failover often fails at the first real incident because of capacity or data gaps.
Frequently Asked Questions
How does Route 53 DNS failover work?
Route 53 monitors health checks. When the primary record's health check fails, it begins answering queries with the secondary record, until the primary is healthy again.
How fast is Route 53 failover?
Detection depends on your health check interval and failure threshold, and clients then move as cached answers expire. We measure it in your environment rather than quote a figure.
Can Route 53 health check private resources?
Not directly from the internet. We use a CloudWatch alarm that monitors the resource and attach a health check to that alarm.
Want Help With Route 53 failover routing and health checks?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required