Elastic Load Balancing and Amazon Route 53 have been integrated to support a single application across multiple regions. Route 53 is AWS’s highly available scalable DNS and health checking service. Route 53 supports high availability architectures by health checking load balancer nodes and re-routing traffic to avoid the failed nodes as they support implementation of multi-region deployments. In addition, Route 53 uses Latency Based Routing to route your customers to the end-point that has the least latency. If multiple primary sites are implemented with appropriate health checks configured then failures result in traffic being shifted away from that site to an alternate region.

Region failures can present several challenges as a result of rapidly shifting traffic (similar to the case of zone failures). These can include Auto Scaling, time required for instance startup, and cache fill time (as we may need to fault to our data sources, initially). Another difficulty usually arises from the lack of information or clarity on what constitutes the minimal or critical stack required to keep the site functioning as normally as possible. Any or all services will need to be considered as critical in these circumstances.

The health checks are essentially automated requests sent over the internet to your application to verify that your application is reachable, available, and functional. This can include both your EC2 instances and your application. As answers are returned only for the resources that are healthy and reachable from the outside world the end users can be routed away from a failed application. Amazon Route 53 health checks are conducted from within each AWS region to check whether your application is reachable from that location.

DNS failover is designed to be entirely automatic. After you have set up your DNS records and health checks, no further manual intervention is required for failover. Typically, it takes about 2-3 minutes from the time of the failure to the point where traffic is routed to an alternate location. Compare this to the traditional long drawn out process where an operator receives an alarm, manually configures the DNS update, and waits for the DNS changes to propagate.

Depending on the availability objectives there is an additional strategy (using Route 53)  that you may want to consider for your application. For example, you can create a backup static site to maintain a "presence" for your end customers while your primary (dynamic) site is down. In the normal course, Route 53 will point to your dynamic site and maintain health checks for it. You will also need to configure Route 53 to point to S3 storage where your static site is residing. If your primary site goes down then traffic can be diverted to the static site (while you work to restore your primary site). You can also combine this static backup site strategy with a multiple region deployment.