Give a website a backup address — Route 53 and DNS failover

Your goal

Plan how new visitors can be directed to a healthy backup website.

Why this matters

Your main site may become unavailable. You will define a useful health signal, prepare a working backup, and explain why a DNS change takes time to reach every visitor.

Words you will use

DNS translates a name into an address. A health check tests availability. Failover selects a backup. TTL tells caches how long a DNS answer can be kept.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Test a useful signal

A server responds on the network, but its checkout page is broken. A health check should reflect the service visitors depend on. Choose a useful target.

What should the health signal represent?

A meaningful endpoint or supported resource health signal.

Choose a signal that represents the availability you need to act on. A shallow check can miss real failures, while an overly fragile check can cause needless switching. Test both healthy and failed cases.

DNS failover has a meaningful health signal.

Useful health result → routing decision

2. Prepare the backup before trouble

The backup record points to a server that has never served the site. Routing visitors there during an outage would not solve their problem. Choose the next step.

What does a backup need?

Working content, dependencies, and tested routing.

Failover can direct traffic; it cannot create a working backup application. Test the backup’s content, permissions, and required data ahead of time, including what features may be limited during recovery.

The backup can serve the intended fallback experience.

Prepared backup + failover records → usable fallback

3. Set realistic expectations

The DNS answer changes after a failure, but some visitors still use a cached address. Existing connections also do not move themselves. Choose the correct expectation.

Will every visitor switch instantly?

No; cached answers and connection behavior affect the transition.

DNS failover affects answers to DNS lookups. Cached answers can remain until their TTL expires, and applications handle connections differently. Include these delays when testing and explaining recovery time.

The recovery plan accounts for DNS and client delays.

Health change → updated DNS answers → clients refresh over time

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.