Create a Backup Website Using Route 53 DNS Failover and S3 Website Hosting

Route 53's new DNS Failover feature gives you the power to monitor your website and automatically route your visitors to a backup site if it goes down.

In today's guest post, Product Manager Sean Meckley shows you how to use this powerful new feature on a fictitious website.

-- Jeff;

---

DNS Failover pairs up well with Amazon S3’s website hosting feature to create a simple, low-cost, and reliable way to deploy a backup website. Of course no one wants their site to go down, but things happen, whether due to deploying bad code, network outages, or other issues, and it’s helpful to have a backup which gives your customers a good experience in the event that your primary website does go down.

Let’s say you’re running a website on an Amazon EC2 instance—for example a company website with some e-commerce functionality, or a blog, or a photo sharing site. For our example, we’ll use internetkitties.com, a fictional website where visitors can log in and share their favorite cat photos.

If you’re using Route 53 today, here’s what your Route 53 hosted zone might look like. It’s pretty simple, with just three DNS records: two default records that come with your hosted zone, plus an A record for internetkitties.com pointing to the Elastic IP address of your EC2 instance.

Let’s configure DNS Failover so that visitors to internetkitties.com will land on a friendly backup site in the event that the main internetkitties.com website experiences an outage.

From the Route 53 console, click Health Checks in the left navigation bar and then click on the Create Health Check button:

Click Create Health Check. This takes you to a page where you’ll enter the information that specifies what web page Route 53 should use as the target of its health check. Enter the IP address of your EC2 instance, along with the port (in most cases this will be port 80, the standard port for web pages served over HTTP), your site’s domain name, and the specific web page that you want Route 53 to request (in this case, we’re entering just a forward slash, which means Route 53 will use your site’s index page as the target of the health check). Click Create Health Check to continue.

Now the console shows the health check that we’ve just created.

Click Hosted Zones in the left navigation bar to go back to our hosted zone, and click on the A record for internetkitties.com.    

Now, in the Edit Record Set panel on the right side of the page, do the following:

1. Set the TTL to 60 seconds. This limits the amount of time this DNS record will be cached within the Internet’s DNS system, which means that there will be a shorter delay between the time failover occurs and the time that end users begin to be routed to your backup site.
2. Set the Routing Policy to “Failover”.
3. Select “Primary” as the Failover Record Type.
4. Select “Yes” for Associate Record Set with Health Check.
5. Select the health check to associate with this record. In the drop-down that appears, you should see the health check we just created. Select this health check.
6. Click Save Record Set.

Route 53 will now check the health of your site by periodically requesting your homepage and verifying that it returns a successful response (to be more specific, it’s checking independently from multiple locations around the world, with each location requesting the page every 30 seconds).

Now, configure your backup site on Amazon S3. For a full walk-through, check out this blog post on how to set up a static website on Amazon S3. You can decide what content to put on your static backup website. For example, you could create a nice “fail whale” page with a friendly message to your customers, and perhaps a phone number or email address so that your customers can reach you even though your website is down.

Back in the Route 53 console, go to your hosted zone and click Create Record Set. Enter the same DNS name as your primary website (in this case, we’re using the root domain “internetkitties.com” which is the same as the name of our hosted zone, so the Route 53 console suggests this for you). For the alias radio button, click “Yes”. Then, select your S3 website endpoint as the alias target.

Now, set the Routing Policy to “Failover”, and select “Secondary” as the failover record type. Leave the remaining checkboxes (evaluate target health and associate record set with health check) at their default settings of “No”, and click Create Record Set.

Here’s what your Route 53 hosted zone looks like after you’re finished.

That’s it—now your primary site is being health checked by Route 53, and Route 53 will automatically start sending traffic to your new backup site on S3 if your primary site goes down for any reason.

Route 53 health checks support HTTP and TCP level checks, and may also be used in combination with Latency Based Routing, or Weighted Round Robin records to route around instance, availability zone or even region level problems. You can read more about Route 53 Health checks in the Route 53 Developer Guide.

-- Sean Meckley, Product Manager, Route 53.

Comments

[Max]

Are the steps different if the website is hosted in a subdomain ('www') instead of at the apex? How do I set the failover of the CNAME which points to the public DNS of an EC2 instance to be pointing to an S3 Bucket?

[D. Svanlund]

This is precisely what I imagined that Route 53 would be able to do some day. Route 53 is really becoming more and more powerful. Great job :)

[Geoff Wagstaff]

Is it possible to use this with ELB in any way? For example, it would be useful if you could associate the health check with a CloudWatch alarm and initiate the failover when it's in alarm state. The alarm could be monitoring something relevant to the availability of the service, such as how many healthy hosts in an ELB.

[Tim]

To be proactive in solving the issue of the failed site, how does route 53 notify the organization of the failure?
ie what email address receives notification of the outage, and also receives notice of the restored service?

How would I view via the console the current status of sites?
ie which are operating in failover vs normal?

[Colm MacCárthaigh]

Max - the steps are almost identical when using "www" and a CNAME. You may use a CNAME to EC2 as your primary record set - associated with a health-check to the public IP of your instance (or an elastic IP) - and a CNAME to your S3 bucket as the secondary record set. When the health-check fails, Route 53 will return the CNAME to S3 - when it passes, Route 53 will return the CNAME to EC2.

Colm
Amazon Route 53

[Colm MacCárthaigh]

Geoff

At present it isn't possible to directly use ELBs with Route 53 DNS failover, except as secondary records. It is a feature we expect to add.

In the meantime, it is possible to associate record sets that point to ELBs (either ALIAS or CNAME record sets) with health-checks to other IPs. You could configure an endpoint to monitor your ELB (or its CloudWatch metrics) and to return HTTP success or failure codes on the ELBs "behalf" - but obviously this a very inconvenient workaround.

-
Colm

[Brandon Fuller]

Crap. You had me at failover until I found out I can't setup a health check on an ELB. That's what I need.

[Stormerider]

I would really love to use this feature to move traffic from one region to another region in the case of a regional outage. However, our Routing Policy is set to "weighted", as we direct people to the region closest to them. Are there any plans to add a policy which combines weighting and failover together?

[Jun]

Hi Colm,

This is a great feature.

Now, I am thinking about a possible solution to redirect traffic between different regions, even different providers. It could be a solution to mitigate the region level AWS outage.

For example, I have a site hosting on the EC2 instances in US-EAST-1. The Elastic IP is 50.1.1.1. The DNS name is www.test53.com. I have a A record in the record set for it.
I have the backup site on the EC2 instances in US-WEST-1. The Elastic IP is 60.1.1.1. The DNS name is www-bak.test53.com. I can configure a record set for this in the same host zone.
Next, I would make the one for www.test53.com the primary one in the Failover policy. Then, add a new record set for www.test53.com and use the www-bak.test53.com as the alias target of the secondary one.
It seems that the allowed alias targets are S3 sites, ELB and the record set in the same host zone.Therefore, this setting should work.

That way, if US-EAST-1 is completely down, the traffic should be directed to US-WEST-1.

If so, the traffic can be actually directed to anywhere, including Rackspace.... It is because www-bak.test53.com is just an A record pointing to an IP address. Unless Route53 has some internal restriction on the IP address range.

Am I correct?

Jun

[Colm MacCarthaigh]

Stormerider,

Yep, it's definitely possible to use this feature in combination with both weighted routing and latency based routing. For example you choose to operate a service in three regions and to direct users to their closest region. If a regional record is failing its healthcheck, it will be excluded and users will go to their next best region. Or you could choose to give each region its own nominated secondary "backup" site. Whatever is best for your service.

The trick in all cases is to use "ALIAS" records within your own hosted zone as a connection. So I might configure a regional record that ALIASes to my weighted record sets, e.g.

www.example.com routing=latency-based region=us-east-1 evaluate target health=true alias to:us-east-1.www.example.com
www.example.com routing=latency-based region=us-west-1 evaluate target health=true alias to:us-west-1.www.example.com
www.example.com routing=latency-based region=eu-west-1 evaluate target health=true alias to:eu-west-1.www.example.com

that configuration says "If the user is closest to $region, send them to whatever the $region.www.example.com record says. If that record is failing its healthchecks, ignore it".

Then for example, one of the regional records might say;

us-east-1.www.example.com type=A weight=1 healthcheck=some-healthcheck value=1.1.1.1
us-east-1.www.example.com type=A weight=1 healthcheck=some-healthcheck value=2.2.2.2

Which spreads load across two instances within the region. This is just one example, but the features can be combined in an infinite number of ways. Feel free to use our developer forum;

https://forums.aws.amazon.com/forum.jspa?forumID=87&start=0

where we'd be more than happy to guide you through the specifics based on the end goal you'd like to reach.

Colm
Amazon Route 53

[Colm MacCarthaigh]

Jun,

You are correct - that should work. You can direct traffic anywhere, including non-AWS IP addresses. But as ever, when using a single failover site, it's worth being mindful to ensure that your backup site has sufficient capacity to cope with your regular load.

Colm
Amazon Route 53