Route 53 Health Checks and DNS Failover

Build a multi-region active-passive failover system with Route 53.

Introduction

30 Second Summary

When a website goes down, users don't wait around. They leave, and the business loses revenue every second the site stays offline.

In this project, you will build a multi-region failover system using AWS Route 53 that automatically detects when your primary web server goes down and routes visitors to a backup server in another region.

What You'll Build

Stop your primary server, watch the health check flip to unhealthy in real time, then verify that DNS queries now return your secondary server's IP address within a minute.

By the end of this project, you'll have:

A primary web server in us-east-1 and a secondary web server in us-west-2, each serving a unique page that identifies which region is responding.
Route 53 health checks actively polling both servers every 30 seconds and reporting their status, with a failover routing policy that automatically switches DNS answers when the primary goes down.
A live demonstration of failure recovery where you stop an instance, watch the health check alarm, and see traffic reroute automatically.
Secret Mission: Build a calculated health check wired to a CloudWatch alarm that emails you the moment failover triggers.

Are there any prerequisites?

You need an AWS account with Console access and basic familiarity with launching EC2 instances. No domain name is required for this project.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for designing resilient architectures on AWS.

Launch Web Servers in Two Regions

Route 53 failover routing needs at least two endpoints in different locations to switch between. Without servers in separate regions, there is nothing to fail over to.

In this step, you will launch two EC2 web servers: a primary in us-east-1 and a secondary in us-west-2. Each server will display a unique page so you can tell which one is responding.

In this step, get ready to:

Launch a primary EC2 instance running Apache in us-east-1.
Launch a secondary EC2 instance running Apache in us-west-2.
Verify both servers are accessible in your browser and displaying their region-specific pages.

Launch the primary EC2 instance in us-east-1

The primary server handles all traffic under normal conditions. You will place it in us-east-1 and configure it to serve a page that identifies itself as the primary endpoint.

Open the AWS Management Console and confirm you are in the US East (N. Virginia) us-east-1 region using the region selector in the top-right corner.
Search for EC2 in the search bar and open the EC2 dashboard.
Click Launch instances.
Under Name and tags, enter primary-web-server.
Under Application and OS Images (AMI), confirm Amazon Linux 2023 is selected (it is the default).
Under Instance type, confirm t2.micro is selected (free tier eligible).
Under Key pair (login), select Proceed without a key pair from the dropdown. You will not need SSH access for this project.

Now configure the networking and security group to allow web traffic and Route 53 health checker traffic.

Under Network settings, click Edit.
Confirm Auto-assign public IP is set to Enable. Your instance needs a public IP so Route 53 health checkers can reach it.
Under Firewall (security groups), select Create security group.
Name the security group primary-web-sg.
Delete the default SSH rule by clicking Remove next to it.
Click Add security group rule.
Set Type to HTTP. For Source type, choose Anywhere. This allows general web traffic on port 80.
Click Add security group rule again to add a second rule.
Set Type to HTTP. For Source type, choose Custom. In the search field that appears, type route53 and select the prefix list named com.amazonaws.us-east-1.route53-healthchecks from the Prefix lists section.

Why add a prefix list rule?

Route 53 health checkers are servers outside your VPC that periodically ping your instance over HTTP. The AWS-managed prefix list com.amazonaws.us-east-1.route53-healthchecks automatically includes all the IP addresses these health checkers use in this region.

Using the prefix list means you never need to manually track individual health checker IPs. AWS keeps the list current for you.

Next, add the user data script that installs and starts Apache on the instance at launch time.

Scroll down and expand Advanced details.
Scroll to the User data field at the bottom of the section.
Paste the following script into the User data field:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Primary Server - us-east-1</h1><p>This is the primary failover endpoint.</p>" > /var/www/html/index.html

What does this script do?

yum update -y updates all system packages on the Amazon Linux instance.
yum install -y httpd installs Apache HTTP Server.
systemctl start httpd starts the web server immediately.
systemctl enable httpd ensures Apache restarts if the instance reboots.
The echo command writes a simple HTML page identifying this as the primary server in us-east-1.

Click Launch instance.
Wait for the success banner to appear, then click the instance ID link to open the instance details.
Wait for Instance state to show Running and Status check to show 2/2 checks passed. This takes 1-2 minutes.
Copy the Public IPv4 address from the instance details and save it somewhere. You will need it in later steps.

Open a new browser tab and paste the public IP address into the URL bar. You should see the heading "Primary Server - us-east-1" on the page.

Page not loading?

Make sure the instance has passed both status checks. If it still shows Initializing, wait another minute. The user data script needs time to install Apache.
Confirm your browser is using http:// not https://. Your instance only serves HTTP on port 80.
Check that your security group has the HTTP rule with source 0.0.0.0/0. Without it, your browser cannot reach port 80.

Need more help? Why can't I see my primary server page in the browser?

Launch the secondary EC2 instance in us-west-2

The secondary server is your backup. It sits idle until Route 53 detects the primary has failed. You will place it in a completely different region so a regional outage cannot take both servers down simultaneously.

In the top-right corner of the console, click the region selector and switch to US West (Oregon) us-west-2.
Navigate to EC2 and click Launch instances.
Under Name and tags, enter secondary-web-server.
Confirm Amazon Linux 2023 AMI and t2.micro instance type are selected.
Under Key pair (login), select Proceed without a key pair.
Under Network settings, click Edit.
Confirm Auto-assign public IP is set to Enable.
Select Create security group and name it secondary-web-sg.

Delete the default SSH rule.
Click Add security group rule. Set Type to HTTP and Source type to Anywhere.
Click Add security group rule again. Set Type to HTTP and Source type to Custom. Search for route53 and select com.amazonaws.us-west-2.route53-healthchecks from the Prefix lists section.

Why a different prefix list?

Each region has its own set of Route 53 health checker IPs. Since this instance is in us-west-2, you select the com.amazonaws.us-west-2.route53-healthchecks prefix list to match.

Expand Advanced details and scroll to the User data field.
Paste the following script into the User data field:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Secondary Server - us-west-2</h1><p>This is the secondary failover endpoint.</p>" > /var/www/html/index.html

What changed in this script?

The only difference is the HTML content. This page identifies the server as "Secondary Server - us-west-2" so you can immediately tell which server is responding during failover testing.

Click Launch instance.
Click the instance ID link and wait for the state to show Running with 2/2 checks passed.
Copy the Public IPv4 address and save it alongside your primary IP.

Open a new browser tab and paste the secondary instance's public IP. You should see "Secondary Server - us-west-2" on the page.

Secondary page not loading?

Double-check that you switched to us-west-2 before launching. If you launched in us-east-1 by mistake, terminate the instance and relaunch in the correct region.
Confirm the security group has HTTP from Anywhere and use http:// in your browser URL.

Need help? Why can't I reach my secondary EC2 instance in us-west-2?

Verify both web servers are responding

Before you continue, confirm both endpoints are healthy and distinguishable. This is the exact behavior Route 53 will check once health checks are in place.

Before you check, predict: what text do you expect to see on each page, and why does it matter that they are different?

Open a browser tab and navigate to your primary instance's public IP (the us-east-1 address).
Confirm the page displays Primary Server - us-east-1.
Open a second tab and navigate to your secondary instance's public IP (the us-west-2 address).
Confirm the page displays Secondary Server - us-west-2.

Both pages loading with different text proves your servers are healthy and uniquely identifiable. During failover testing later, you will use these page titles to confirm which server Route 53 is directing traffic to.

✔️ Both pages load correctly

You are all set. Both endpoints are live and serving unique content.

ⓧ One or both pages won't load

Verify you are using http:// and not https://. Apache is only configured for HTTP.
Go to the EC2 console in the correct region and confirm the instance shows Running with 2/2 checks passed.
Select the instance, click the Security tab, and click the security group link. Verify you have an inbound rule for HTTP (port 80) with source 0.0.0.0/0.
If the page is blank but loads (no error), the user data script may not have run. Select the instance, click Actions > Monitor and troubleshoot > Get system log and look for Apache installation output.

Your two web servers are live and serving unique pages across two AWS regions. Next up, you will create Route 53 health checks that monitor these endpoints every 30 seconds and report whether they are alive.

Create Route 53 Health Checks

Your two web servers are live and serving pages from different regions. Now you need to give Route 53 a way to know whether each server is actually up and responding.

Route 53 cannot make failover decisions without health data. Health checks are the monitoring mechanism that continuously polls your endpoints and tells Route 53 whether each one is alive. Without them, Route 53 would keep sending traffic to a dead server.

In this step, get ready to:

Create HTTP health checks for both EC2 instances.
Verify both health checks report a "Healthy" status.
Examine health checker regions and the 18% aggregation threshold.

Create the primary health check

Each health check needs to know the IP address to poll, which protocol to use, and how many consecutive failures count as "unhealthy". You will configure one for each server.

In the AWS console, use the search bar at the top and type Route 53.
Select Route 53 from the results.
In the left sidebar, click Health checks.
Click Create health check.

The health check creation form opens. Configure the primary health check with these settings:

In the Name field, enter primary-health-check.
For What to monitor, select Endpoint.
For Specify endpoint by, select IP address.
For Protocol, select HTTP.
In the IP address field, paste your primary EC2 instance's public IPv4 address (from us-east-1).
For Port, enter 80.
For Path, enter /.

Expand the Advanced configuration section.
For Request interval, select Standard (30 seconds).
For Failure threshold, enter 3.

What do these settings mean?

The request interval of 30 seconds means Route 53 health checkers will poll your server every 30 seconds. The failure threshold of 3 means the endpoint must fail 3 consecutive checks before Route 53 marks it unhealthy.

Together, this means it takes approximately 90 seconds (3 checks x 30 seconds) from actual failure to Route 53 marking the endpoint as unhealthy.

Scroll down to the Get notified when a health check fails section.
Select No (you will add alerting in the Secret Mission).
Click Create health check.

You should see primary-health-check appear in your health checks list. Its status may show as "Unknown" briefly while health checkers begin polling.

Don't see the health check?

Make sure you clicked Create health check at the bottom of the form. If you see validation errors, check that the IP address field contains only the IPv4 address with no spaces or extra characters.

help me troubleshoot why my Route 53 health check did not appear after creation

Create the secondary health check

Click Create health check again.
In the Name field, enter secondary-health-check.
For What to monitor, select Endpoint.
For Specify endpoint by, select IP address.
For Protocol, select HTTP.
In the IP address field, paste your secondary EC2 instance's public IPv4 address (from us-west-2).
For Port, enter 80.
For Path, enter /.

Expand Advanced configuration.
Set Request interval to Standard (30 seconds).
Set Failure threshold to 3.
For Get notified when a health check fails, select No.
Click Create health check.

Both primary-health-check and secondary-health-check now appear in your health checks list.

Monitor health check status and examine health checkers

Route 53 considers a new health check to be healthy until there is enough data to determine the actual status. Within 30-60 seconds, the global health checkers will begin polling your endpoints and reporting real results.

Wait 30-60 seconds, then refresh the health checks page.
Observe both health checks transition to a Healthy status (shown in green).

Before you click into a health check, what do you think determines whether Route 53 calls an endpoint healthy or unhealthy? Is it one checker or many?

Click on primary-health-check to open its details.
Select the Health checkers tab.

You can see a list of global regions currently reporting on your endpoint's health. Route 53 uses health checkers distributed across multiple regions worldwide.

What is the 18% aggregation threshold?

Route 53 does not rely on a single checker to determine health. If more than 18% of health checkers report that an endpoint is healthy, Route 53 considers it healthy. If 18% of health checkers or fewer report that an endpoint is healthy, Route 53 considers it unhealthy.

This prevents a single region's network issue from falsely marking your server as down. It is a key concept for the SAA-C03 exam.

Click Health checks in the left sidebar to return to the health checks list.
Confirm both health checks show a Healthy status in green.

Seeing "Unhealthy" status?

If a health check shows Unhealthy, the most common cause is the security group. Return to the EC2 console for that region and verify the security group has an inbound rule allowing HTTP (port 80) from the prefix list com.amazonaws.<region>.route53-healthchecks. Health checkers are outside the VPC and must be explicitly allowed through your security group.

Also confirm the EC2 instance is running and that you can still access its page directly via the public IP in your browser.

help me troubleshoot why my Route 53 health check is showing Unhealthy

Route 53 is now actively monitoring both of your servers every 30 seconds from multiple regions around the world. Next up, you will connect these health checks to failover routing records so Route 53 knows what to do when a server goes down.

Configure Failover Routing Policy

Your health checks are now actively monitoring both web servers and reporting them as healthy. Route 53 knows whether each endpoint is alive, but monitoring alone does nothing.

Without failover records, Route 53 has no instructions for what to do when an endpoint fails. In this step, you will create a failover routing policy that connects your health checks to action. When the primary goes down, Route 53 will automatically switch DNS answers to your secondary server.

In this step, get ready to:

Create a Route 53 hosted zone for testing failover.
Create primary and secondary failover A records associated with their health checks.
Verify that DNS resolves to the primary server under normal conditions.

Create a hosted zone for failover testing

You do not need to own a domain to create a hosted zone in Route 53. You can create one with any name and query it directly using the nameservers Route 53 assigns.

In the AWS Management Console, navigate to Route 53.
In the left navigation pane, click Hosted zones.
Click Create hosted zone.
In the Domain name field, enter failover-demo.com.
Leave Type set to Public hosted zone.
Click Create hosted zone.

After creation, Route 53 shows you the hosted zone details. Look at the NS (nameserver) record in the records list. Copy one of the nameserver values (for example, ns-123.awsdns-45.com) and save it. You will use this to query Route 53 directly.
Click Create record.

Why query the nameserver directly?

Since you do not own failover-demo.com, public DNS resolvers will not find your records. By querying the Route 53 nameserver directly with nslookup, you bypass public DNS and talk straight to Route 53. This proves failover works exactly as it would with a real domain.

Create the primary failover record

You will create both failover records (primary and secondary) as a single batch in the Route 53 console. This ensures they are paired correctly under the same record name.

In the Record name field, enter failover (this creates failover.failover-demo.com).
Set Record type to A.
In the Value field, enter your primary EC2 instance's public IPv4 address.
Set TTL (seconds) to 60.
For Routing policy, select Failover.
Set Failover record type to Primary.
For Health check, select primary-health-check.
In the Record ID field, enter primary-us-east-1.
Click Add another record to add the secondary record in the same batch.

Why set TTL to 60 seconds?

TTL (Time to Live) controls how long DNS resolvers cache a record before checking for updates. A 60-second TTL means that when Route 53 switches the answer during failover, clients pick up the new IP within one minute.

AWS recommends a TTL of 60 seconds or less when associating a record with a health check, so clients respond quickly to changes in health status.

Create the secondary failover record in the same batch

The new record form appears below your primary record. Fill it in with the secondary server's details.

In the Record name field, enter failover (same name as the primary record).
Set Record type to A.
In the Value field, enter your secondary EC2 instance's public IPv4 address (the us-west-2 instance).
Set TTL (seconds) to 60.
For Routing policy, select Failover.
Set Failover record type to Secondary.
For Health check, select secondary-health-check.
In the Record ID field, enter secondary-us-west-2.
Click Create records.

What is active-passive failover?

You have just configured an active-passive failover architecture. The primary record serves traffic during normal operation. When Route 53 detects the primary is unhealthy, it automatically responds with the secondary record instead.

Both records share the same name (failover.failover-demo.com) and type (A), but Route 53 knows which to serve based on the failover record type and the health check status.

🙋‍♀️ Seeing a record creation error?

If Route 53 rejects the records, check that both records have the exact same value in the Record name field. They must match precisely for failover to function.

Also confirm you selected Failover as the routing policy on both records, not just one. Each record in a failover pair must use the same routing policy.

help me fix a Route 53 failover record creation error

Verify normal operation with nslookup

Your failover records are now live. Since both health checks are healthy, Route 53 should serve the primary record to all DNS queries.

Before you run the lookup, what IP address do you expect Route 53 to return for your failover subdomain right now?

Open Command Prompt (Windows) or Terminal (macOS) by pressing Cmd+Space (macOS) or the Windows key, typing cmd or Terminal, and pressing Enter.
Run this command to query Route 53 directly using the nameserver you saved earlier:

nslookup failover.failover-demo.com [[NAMESERVER="your-nameserver-from-the-NS-record"]]

The response shows your primary EC2 instance's public IP address (the us-east-1 server). This confirms Route 53 is correctly routing to the primary under healthy conditions.

Confirm the IP address in the response matches your primary EC2 instance's public IP (the us-east-1 server). This proves Route 53 is correctly routing to the primary.

What does this prove?

Right now both servers are healthy, so Route 53 uses the primary record. The failover routing policy means Route 53 always prefers the primary when it passes its health check.

In the next step, you will stop the primary instance and watch Route 53 automatically switch to the secondary.

🙋‍♀️ Not seeing your primary IP in the nslookup response?

DNS propagation can take up to 60 seconds after record creation. Wait a minute and try the nslookup command again.

If you still see unexpected results, verify in the Route 53 console that your failover records show the correct IP addresses and that both health checks display a status of Healthy.

help me troubleshoot why my Route 53 failover DNS is not resolving to the expected IP

Your failover architecture is wired up and working under normal conditions. Next up, you will simulate a real failure by stopping the primary server and watch Route 53 reroute traffic to the secondary automatically.

Simulate Failure and Observe Failover

Your failover records are configured and verified. Everything works when both servers are healthy. But the entire point of failover architecture is what happens when something breaks.

In this step, you will deliberately break your primary server and watch Route 53 respond in real time. You will also discover a counter-intuitive behavior: what Route 53 does when every endpoint is down.

In this step, get ready to:

Stop the primary instance and observe Route 53 failover to the secondary.
Demonstrate the "all-unhealthy" fallback behavior by stopping both instances.
Restore both instances and confirm recovery.

Trigger failover by stopping the primary instance

Stopping the primary EC2 instance simulates a real server failure. Route 53 health checkers will fail to reach the endpoint, and after 3 consecutive failures (about 90 seconds at 30-second intervals), Route 53 marks the health check as unhealthy and reroutes DNS.

Return to the EC2 console. Confirm the region selector in the top-right shows US East (N. Virginia) us-east-1.
In the left navigation pane, click Instances.
Select the checkbox next to your primary instance.
Click Instance state, then click Stop instance.
When prompted for confirmation, click Stop.

The instance state changes to Stopping and then Stopped within a minute or two.

Switch to the Route 53 console. In the left navigation pane, click Health checks.
Watch the primary-health-check row. Refresh the page every 30 seconds.

Within 1-2 minutes, the status column changes from Healthy (green) to Unhealthy (red). This happens once the failure threshold of 3 consecutive failed checks is reached.

Why does it take 90 seconds?

Your health check polls every 30 seconds with a failure threshold of 3. That means Route 53 needs three consecutive failures before it marks the endpoint unhealthy: 3 x 30 seconds = approximately 90 seconds from actual failure to status change.

Before you run the next command, make a prediction: do you think nslookup will still return your primary IP, or will it have switched to the secondary?

Open Command Prompt and run this command:

nslookup failover.failover-demo.com [[NAMESERVER="your-nameserver-from-the-NS-record"]]

The response now shows your secondary EC2 instance's public IP address. Route 53 has rerouted DNS because the primary health check is unhealthy.

Compare the IP address in the response to your secondary instance's public IP. It should now match the us-west-2 server instead of the primary.

The IP address has switched to your secondary server. Failover is working.

Still seeing the primary IP?

Since you are querying the Route 53 nameserver directly, caching is not a factor. If you still see the primary IP, the health check may not have reached the failure threshold yet. Confirm the health check shows Unhealthy in the Route 53 console before running nslookup again.

Help me troubleshoot Route 53 failover not switching

Demonstrate the "all-unhealthy" fallback behavior

Here is where Route 53 does something surprising. What happens when both servers are down and every health check is unhealthy? You might expect Route 53 to return no answer at all.

Switch to the us-west-2 region in the AWS console by clicking the region selector in the top-right and choosing US West (Oregon) us-west-2.
In the EC2 console, click Instances in the left pane.
Select your secondary instance, click Instance state, then click Stop instance.
Confirm by clicking Stop.

Return to Route 53 > Health checks. Wait 1-2 minutes and refresh until both primary-health-check and secondary-health-check show Unhealthy.

Now for the prediction: both endpoints are down. What do you think nslookup will return? No result? An error? The secondary IP?

In Command Prompt, run the lookup again:

nslookup failover.failover-demo.com [[NAMESERVER="your-nameserver-from-the-NS-record"]]

Route 53 returns the primary record's IP address. This is the "all-unhealthy" fallback behavior.

What is the all-unhealthy fallback?

When all records are considered unhealthy, the Route 53 algorithm reverts to considering all records healthy. Route 53 DNS servers will choose an answer anyway and return it rather than returning no DNS answer or returning an NXDOMAIN (non-existent domain) response.

For failover routing specifically, Route 53 returns the primary record. The logic is that a potentially-recovering primary endpoint is better than no response at all. This is a key SAA-C03 exam concept: Route 53 never leaves users with no answer.

Restore service and verify recovery

With the failover behavior proven, restore both instances and confirm Route 53 returns to normal operation.

In the EC2 console, make sure you are in us-east-1 (switch regions if needed).
Select your primary instance, click Instance state, then click Start instance.
Switch to us-west-2 and start your secondary instance the same way.
Wait for both instances to reach the Running state (1-2 minutes).

Public IPs may change on restart

When you stop and start an EC2 instance (without an Elastic IP), the public IPv4 address changes. Check the Public IPv4 address column for each instance after it reaches the Running state.

If the IP changed, you must update two things: the Route 53 health check (edit the IP address field) and the failover A record value. Follow the steps below.

For each instance whose IP changed, note the new public IPv4 address from the EC2 console.
In Route 53, navigate to Health checks. Click the linked ID of the health check that needs updating, then click Edit.
Update the IP address field with the new public IP. Click Save.
Navigate to Hosted zones and click failover-demo.com. Find the failover A record, click Edit record, and update the Value field with the new IP. Click Save.
Repeat for the secondary if its IP also changed.

Return to Health checks and wait for both health checks to return to Healthy (green). This may take 1-2 minutes.

Time for the final verification. With both instances healthy again, what do you expect nslookup to return?

Run the lookup one more time:

nslookup failover.failover-demo.com [[NAMESERVER="your-nameserver-from-the-NS-record"]]

The response resolves to your primary IP again. Route 53 has failed back to the primary now that it is healthy.

What is failback?

In active-passive failover, once the primary endpoint recovers and its health check returns to healthy, Route 53 automatically routes traffic back to the primary. There is no manual intervention required. The TTL determines how quickly DNS resolvers pick up the change (up to 60 seconds in this configuration).

🙋‍♀️ Health check still showing Unhealthy after restart?

If the instance's public IP changed on restart and you did not update the health check, Route 53 is still polling the old (now-dead) IP. Edit the health check to use the new public IPv4 address. Also verify the instance's security group still allows HTTP from the health checker prefix list.

Help me figure out why my health check isn't recovering

You have just proven that your failover architecture works end-to-end. Next up, you will build a calculated health check and wire it to a CloudWatch alarm so you get notified the moment failover triggers.

Secret mission

Calculated Health Check with CloudWatch Alarm

Your failover works, but how would you know it triggered? In production, silent failovers are dangerous. Build a calculated health check that monitors both endpoints at once, then wire it to a CloudWatch alarm that emails you the moment your infrastructure degrades.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your EC2 instances (t2.micro) are free-tier eligible. The hosted zone is free if deleted within 12 hours of creation.

Cost warning

The hosted zone costs $0.50/month if not deleted within 12 hours of creation. If your AWS Free Tier has expired, the two t2.micro instances will incur hourly compute charges while running. Delete or stop them when you are finished.

Resources you used:

2 EC2 instances (t2.micro) in us-east-1 and us-west-2.
1 Route 53 hosted zone (failover-demo.com).
2 Route 53 endpoint health checks (primary-health-check and secondary-health-check).
1 Route 53 calculated health check (calculated-failover-check).
2 Route 53 failover A records for failover.failover-demo.com.
1 SNS topic (failover-alerts) with email subscription.
1 CloudWatch alarm on the calculated health check.

Keep everything running

No action needed. Choose this if you plan to experiment further with Route 53 failover.

Health checks continue to poll and are free (within the 50 AWS-endpoint limit.
EC2 instances remain running. Compute charges apply if you have exceeded the Free Tier.
The hosted zone costs $0.50/month if kept beyond 12 hours after creation.

Pause - I'll come back to this later

Shut down running instances to halt compute charges. Health checks will show unhealthy but incur no additional cost.

In the EC2 console (us-east-1), select your primary instance, choose Instance state, then Stop instance.
Switch to us-west-2 and stop your secondary instance the same way.
When you return, start both instances. Note that public IPs may change. Update health checks and failover records with the new IPs if they do.

Delete - I don't want to use this again

Remove all project resources completely. Delete the hosted zone within 12 hours of creation to avoid the $0.50 monthly charge.

Terminate both EC2 instances. In the EC2 console (us-east-1), select your primary instance, choose Instance state, then Terminate (delete) instance. Choose Terminate (delete) to confirm. Repeat in us-west-2 for the secondary instance.
Delete the failover A records. In Route 53, open failover-demo.com, select both failover records for failover.failover-demo.com, and choose Delete.
Delete all three health checks. Navigate to Route 53 > Health checks. Select primary-health-check, choose Delete, type confirm, and choose Delete. Repeat for secondary-health-check and calculated-failover-check.
Delete the hosted zone. In Route 53 > Hosted zones, select failover-demo.com, click Delete hosted zone, type confirm, and click Delete. If deleted within 12 hours of creation, no charge applies.
Delete the CloudWatch alarm. Open the CloudWatch console, choose Alarms, then All alarms. Select the checkbox next to your health-check alarm, choose Actions, then Delete. Choose Delete to confirm.
Delete the SNS topic. Open the Amazon SNS console, choose Topics in the left navigation pane. Select failover-alerts, choose Delete, type delete me in the confirmation box, and choose Delete.

That's a Wrap!

Nice work! You have built a production-style active-passive failover architecture using Route 53, proving that your DNS can automatically recover from regional outages without any manual intervention.

Here's what you learned:

Launched EC2 web servers across two AWS regions and configured security groups with AWS-managed prefix lists to allow Route 53 health checker traffic.
Created Route 53 health checks monitoring both endpoints and configured a failover routing policy with primary and secondary A records that automatically switch DNS answers when an endpoint fails.
Simulated a real failure by stopping the primary instance, observed Route 53 reroute traffic to the secondary within 60-90 seconds, and demonstrated the all-unhealthy fallback behavior where Route 53 returns the primary record as a mode of last resort rather than returning NXDOMAIN.
(Secret Mission) Built a calculated health check aggregating both endpoint checks with a HealthThreshold of 2, and wired it to a CloudWatch alarm with SNS email notification for immediate alerting on infrastructure degradation.

Ready to quiz yourself?