Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« AWS Week in Review - February 4, 2013 | Main | Amazon RDS Price Reduction for Multi-AZ Deployments »


TrackBack URL for this entry:

Listed below are links to weblogs that reference Create a Backup Website Using Route 53 DNS Failover and S3 Website Hosting :


Feed You can follow this conversation by subscribing to the comment feed for this post.


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.


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.

Amazon Route 53

Colm MacCárthaigh


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.


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.


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?


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 The DNS name is 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 The DNS name is I can configure a record set for this in the same host zone.
Next, I would make the one for the primary one in the Failover policy. Then, add a new record set for and use the 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 is just an A record pointing to an IP address. Unless Route53 has some internal restriction on the IP address range.

Am I correct?


Colm MacCarthaigh


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. routing=latency-based region=us-east-1 evaluate target health=true alias routing=latency-based region=us-west-1 evaluate target health=true alias routing=latency-based region=eu-west-1 evaluate target health=true alias

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

Then for example, one of the regional records might say; type=A weight=1 healthcheck=some-healthcheck value= type=A weight=1 healthcheck=some-healthcheck value=

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;

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

Amazon Route 53

Colm MacCarthaigh


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.

Amazon Route 53

The comments to this entry are closed.

Featured Events

The AWS Report

Brought to You By

Jeff Barr (@jeffbarr):

Jinesh Varia (@jinman):

Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30