Route 53 DNS failover changes the answers returned to DNS queries. Clients can keep using an earlier answer or an existing connection. A useful setup therefore needs a working standby, a health signal that matches the service, and a drill that measures application recovery.
This guide builds a primary/secondary pair of ordinary A records for two public IPv4 endpoints. Load balancer aliases need a different health configuration, covered below. Use a dedicated test hostname before changing a production service.
Prepare a standby that can serve the request
Both endpoints must accept the same application hostname and present a valid certificate for it. Check authentication, required data and available capacity on the standby before connecting DNS failover. A successful health response alone cannot establish those properties.
For a service that writes data, define who can write after a cutover and how the old primary loses that permission. DNS changes cannot fence a database writer. The warm-standby recovery guide covers that work.
A maintenance page can explain an outage, but it cannot complete an API operation. An S3 website endpoint also lacks HTTPS support. If a fallback must serve your HTTPS hostname, provide a compatible HTTPS front end and test it with the original URL. S3 website endpoint limitations.
Create one health check for each endpoint
In Route 53, open Health checks and create an endpoint check. For each server, select HTTPS, its public IP address, port 443 and an application readiness path such as /ready. Set the domain name used for the HTTP Host header and enable SNI when the server requires it. Repeat for the standby, using its own IP address. AWS documents the endpoint and SNI fields.
If you specify an endpoint only by hostname, give each server a separate name that resolves directly to that server. Do not use the shared failover hostname as the lookup target for its own checks: the answer can change which server a checker reaches. With a fixed IP configured, the domain-name field can supply the intended Host header without choosing the destination through DNS. Health-check address and hostname behavior.
Make the readiness response small and cheap. Return 200 only when the endpoint can handle the intended traffic; use a failure status when it cannot. Ordinary HTTP/HTTPS checks accept 2xx and 3xx, so a redirect to a login page can pass. String matching can require a marker in the first 5,120 response bytes. HTTPS checks do not validate certificate expiry or trust. Keep a separate certificate check. Health-check success criteria.
Allow the health checkers through the firewall on the checked port. Use AWS's current ranges for the selected checking regions and Global range, or the relevant AWS-managed prefix list in an EC2 security group. Allowing a single observed checker IP is fragile because the source can change. Firewall configuration.
These direct checks run outside your VPC and cannot probe private addresses. For a private service, use an appropriate internal metric and a health check based on its CloudWatch alarm data stream, or supported target-health evaluation. Decide what missing metric data should mean. Private-zone failover.
Wire the two records to the two checks
Wait for both checks to collect results and confirm their endpoints are healthy before attaching them. A new, non-inverted check initially counts as healthy until AWS has enough data to judge it.
In the authoritative public hosted zone, create two records with the same name and type. The following table is a configuration worksheet for a staging hostname, not a deployed example. Use the public addresses of your test servers.
| Field | Primary | Secondary |
|---|---|---|
| Name | Same test name | Same test name |
| Type | A | A |
| Alias | Off | Off |
| Policy | Failover | Failover |
| Role | Primary | Secondary |
| Value | Primary IPv4 | Standby IPv4 |
| Check | Primary check | Standby check |
| Record ID | primary | secondary |
| TTL | 60 seconds | 60 seconds |
AWS recommends 60 seconds or less for ordinary records associated with health checks. Review the query-volume tradeoff before choosing a lower value. If an existing record has a longer TTL, lower it in advance and allow the earlier cached answers to expire. You cannot create ordinary non-failover records with the same name and type alongside this pair. Failover record fields.
Verify the check IDs carefully. Route 53 monitors the endpoint configured in each check; it does not infer that endpoint from the record value. An accidentally swapped check can remove the healthy server's answer. How records and checks connect.
If the service also publishes AAAA records, review and test the IPv6 route separately. Changing the A response leaves an existing IPv6 route in place.
What Route 53 returns when checks fail
For this pair of non-alias records with a check on each, the authoritative response follows this table. Health here means Route 53's evaluated status, which can differ from what one user observes.
| Primary | Standby | Answer |
|---|---|---|
| Healthy | Healthy | Primary |
| Healthy | Unhealthy | Primary |
| Unhealthy | Healthy | Standby |
| Unhealthy | Unhealthy | Primary |
The last row matters: two failed checks do not remove both answers. If you omit the secondary's check, Route 53 treats that record as healthy and returns it when the primary is unhealthy, even if the standby application is broken. A primary that becomes healthy again is preferred automatically. AWS's failover selection rules.
Do not mark the old primary ready for traffic until its application and data are safe to use. If recovery needs an operator's decision, build that decision into the routing-control procedure before an incident.
Load balancer aliases use target health
For an ELB target, use an alias and Evaluate target health instead of copying its current addresses into ordinary A records. AWS supports target-health evaluation without a separately created endpoint check. Alias and non-alias health configuration.
For Application and Network Load Balancers, review every associated target group. A group containing only unhealthy targets makes the load balancer unhealthy for this evaluation; an empty target group also counts as unhealthy. This can affect routing even when one application path still works.
If you attach an explicit health check and also enable target-health evaluation, both must pass. CloudFront aliases cannot set Evaluate target health to Yes. Check the rules for your exact target before adapting the worksheet. Failover alias behavior.
Measure recovery through the client
The interval between checks can be 10 or 30 seconds. A failure threshold applies to each checker, and AWS combines results from independent checkers. Multiplying 30 seconds by three failures does not produce a guaranteed 90-second cutover time. AWS currently considers an endpoint healthy when more than 18% of checkers report it healthy; that is not a majority vote. Health aggregation.
After the authoritative answer changes, a recursive resolver can still have the previous answer cached. A shorter TTL makes refreshed answers arrive sooner, at the cost of more queries. It does not close existing application connections. Measure the client behavior your service depends on. DNS TTL tradeoffs.
Some resolvers can serve expired answers when they cannot refresh them, as described in RFC 8767. A TTL is therefore unsuitable as a hard bound on user recovery. The DNS TTL and failover tutorial has query examples for inspecting authoritative and recursive responses separately.
Run the failure cases on a test hostname
Use isolated test endpoints, an agreed stop condition and a reversible readiness failure. Keep normal traffic out of the exercise. Record the fault time, evaluated check status, authoritative answer, recursive answer and first successful application request. Use one clock reference and retain the failed requests too.
- Start with both endpoints healthy. Verify the primary answer and complete a request through the shared test hostname. Test the standby directly with the intended hostname and certificate before introducing a fault.
- Make only the primary readiness path return 503. Wait for its evaluated health to change. Query the zone's authoritative servers, then the recursive resolvers used by your test clients. Record when each begins returning the secondary.
- Complete the application operation through the shared hostname. Include a client with a cached primary answer and one with an existing connection. Check the destination in server logs rather than treating a DNS answer as proof of successful recovery.
- With the primary still unhealthy, make the secondary readiness check fail too. Verify that the authoritative answer returns to the primary, as the decision table specifies. Keep this case confined to the isolated test setup.
- Restore the secondary first and verify it is selected. Restore the primary only when it can safely serve the workload, then observe automatic failback and client recovery.
Do not simulate failure by disabling a health check: AWS treats a disabled check as healthy. Test a controlled endpoint failure instead. Disabled-check behavior.
Build the failover records and checks before they are needed. AWS recommends recovery mechanisms that use the distributed DNS and health-check data planes, rather than depending on console edits during an outage. Save the tested configuration, the observed recovery times and the exact conditions for allowing the primary back into service. Route 53 recovery guidance.