Amazon adds DNS Failover to Route 53

Intros dead man switch in case of site megafails

Amazon Web Services

Amazon has encroached further onto the turf of traditional web-hosters with a DNS Failover upgrade to its Route 53 DNS service.

The free upgrade lets developers use the DNS Failover feature to automatically route traffic to a backup website hosted on Amazon S3, or to a site hosted in another AWS region if part of the Amazon cloud goes titsup, the company announced on Tuesday.

Previously, developers had to program this for themselves, so the upgrade is a time-saver rather than a technical leap forward.

Along with providing a much-requested feature, the technology also encourages developers to build little static websites on Amazon's cloud. This fits with Amazon's slow expansion into the territories of traditional web-hosts as it diversifies its products away from rentable compute, storage, and networking.

It is also a way of bringing parity with one of the few areas where Microsoft's Azure cloud has a lead on Amazon: easy-peasy website hosting.

'Follow Route 53 for diversion'

The new tech works by checking a pre-set page from 16 AWS Route 53 locations around the world (two in each regional data center hub), with each location pinging the page every 30 seconds. If the system functions perfectly, the page should get a checkup every two seconds.

If it detects a problem, Route 53 will start sending traffic to the backup site.

Amazon gave no specific details on exactly how long it could take for Route 53 to wake up, smell the burning cloud, and calmly direct traffic to the backup, but the blog post implied that if you configure everything correctly, then it should be a matter of minutes, as Route 53 will need to wait for about a minute for DNS cache to clear.

At launch you can only point the Route 53 agents to an IP address, so if your site/application/cloud system is fronted by load balancers, it will take a bit of extra fiddling to get this to work for you.

Amazon has a tendency to broaden the remit of its cloud services overtime, so this will probably be changed in the future. ®

Sponsored: Designing and building an open ITOA architecture