Amazon Route 53 Adds ELB Integration for DNS Failover
Route 53 launched DNS Failover on February 11, 2013. With DNS Failover, Route 53 can detect an outage of your website and redirect your end users to alternate or backup locations that you specify. Route 53 DNS Failover relies on health checks-regularly making Internet requests to your applications endpoints from multiple locations around the world-to determine whether each endpoint of your application is up or down.
Until today, it was difficult to use DNS Failover if your application was running behind ELB to balance your incoming traffic across EC2 instances, because there was no way configure Route 53 health checks against an ELB endpoint-to create a health check, you need to specify an IP address to check, and ELBs dont have fixed IP addresses.
Whats different about DNS Failover for ELB?
Determining the health of an ELB endpoint is more complex than health checking a single IP address. For example, what if your application is running fine on EC2, but the load balancer itself isnt reachable? Or if your load balancer and your EC2 instances are working correctly, but a bug in your code causes your application to crash? Or how about if the EC2 instances in one Availability Zone of a multi-AZ ELB are experiencing problems?
Route 53 DNS Failover handles all of these failure scenarios by integrating with ELB behind the scenes. Once enabled, Route 53 automatically configures and manages health checks for individual ELB nodes. Route 53 also takes advantage of the EC2 instance health checking that ELB performs (information on configuring your ELB health checks is available here). By combining the results of health checks of your EC2 instances and your ELBs, Route 53 DNS Failover is able to evaluate the health of the load balancer and the health of the application running on the EC2 instances behind it. In other words, if any part of the stack goes down, Route 53 detects the failure and routes traffic away from the failed endpoint.
A nice bonus is that, because you dont create any health checks of your own, DNS Failover for ELB endpoints is available at no additional charge-you arent charged for any health checks.
When setting up DNS Failover for an ELB Endpoint, you simply set Evaluate Target Health to true-you dont create a health check of your own for this endpoint:
Scenarios Possible with DNS Failover
Using Route 53 DNS Failover, you can run your primary application simultaneously in multiple AWS regions around the world and fail over across regions. Your end users will be routed to the closest (by latency), healthy region for your application. Route 53 automatically removes from service any region where your application is unavailable-it will pull an endpoint out service if theres a region-wide connectivity or operational issue, if your application goes down in that region, or if your ELB or EC2 instances go down in that region.
You can also leverage a simple backup site hosted on Amazon S3, with Route 53 directing users to this backup site in the event that your application becomes unavailable. In February we published a tutorial on how to create a simple backup website. Now you can take advantage of this simple backup scenario if your primary website is running behind an ELB-just skip the part of the tutorial about creating a health check for your primary site, and instead create an Alias record pointing to your ELB and check the evaluate target health option on the Alias record (full documentation on using DNS Failover with ELB is available in the Route 53 Developer Guide.
Get Started and Learn More
Join the High Availability with Route 53 DNS Failover Webinar at 10:00 AM PDT on July 9, 2013 to learn more about DNS Failover and the high-availability architecture options that it makes possible.
To get started with DNS Failover for Route 53, visit the Route 53 product page or review our walkthrough in the Amazon Route 53 Developer Guide. Getting started with Route 53 is easy, and there are no upfront costs. See the Route 53 product page for full details and pricing.
— Jeff (with help from Sean Meckley, Product Manager)