Google Reviews Trusted Google Reviews
24/7 Support
Jon Granados
Jon Granados More Posts
President/CEO · 28 posts
2 years ago
Route 53 failover configuration
Route 53 failover configuration

Amazon Route 53 lets you configure DNS failover in active-active, active-passive, and mixed configurations to improve the availability of your application. When you have more than one resource performing the same function—for example, more than one HTTP server or mail server—you can configure Amazon Route 53 to check the health of your resources and respond to DNS queries using only the healthy resources. For example, suppose your website, example.com, is hosted on 10 servers, two each in five data centers around the world. You can configure Amazon Route 53 to check the health of those servers and to respond to DNS queries for example.com using only the servers that are currently healthy.

You can set up a variety of failover configurations using Amazon Route 53 alias, weighted, latency, geolocation routing, and failover resource record sets:

  • Active-Active Failover: Use this failover configuration when you want all of your resources to be available the majority of the time. When a resource becomes unavailable, Amazon Route 53 can detect that it’s unhealthy and stop including it when responding to queries.
  • Active-Passive Failover: Use this failover configuration when you want a primary group of resources to be available the majority of the time and you want a secondary group of resources to be on standby in case all of the primary resources become unavailable. When responding to queries, Amazon Route 53 includes only the healthy primary resources. If all of the primary resources are unhealthy, Amazon Route 53 begins to include only the healthy secondary resources in response to DNS queries.
  • Active-Active-Passive and Other Mixed Configurations: You can combine alias and non-alias resource record sets to produce a variety of Amazon Route 53 behaviors.

NOTE: When you first acquire a domain name from a Registrar like GoDaddy.com or NetworkSolutions.com you must host the DNS Zone file with Route 53 in order to use Amazon’s DNS failover. You can now purchase domains directly from Amazon. Once you create a Hosted Zone, you will receive the Name Servers your domain name must point to. You can change your domain’s name servers under the registrar’s management console. For this tutorial I will be using thesurgeagency.com as my primary domain name and will be configuring failover for www.thesurgeagency.com.

Today we will be using a Active-Passive Configuration. This is a great way to ensure access to your AWS hosted application. You typical want to host your applications in 2 different locations.  You can host your amazon resources in multiple locations world-wide. These locations are composed of regions and availability zones. Each region is a separate geographic area. Each region has multiple, isolated locations known as availability zones. These availability zones are different data centers that are located under a certain region.

You will first begin by logging into your AWS Account and accessing the main AWS Console Page. We will be using Amazon’s Route 53 Service for DNS Failover.

Once you Select Route 53, You will need to go into DNS management, Here you will create a Hosted Zone.

Next you will select “Create Hosted Zone” and configure your  “Domain Name” and “Comment”. The comment section can be used as a note.

Remember to choose “Public Hosted Zone” when choosing the zone type. Public Zone and Private Zone are the two types of zone available when choosing the type.

Public Zone: A Public hosted zone is a container that holds information about how you want to route traffic on the Internet for a domain, such as example.com, and its subdomains (apex.example.com, acme.example.com).

Private Zone: A Private hosted zone is a container that holds information about how you want to route traffic for a domain and its subdomains within one or more Amazon Virtual Private Clouds

After you create a Hosted Zone for your domain, a “Delegation Set” of name servers will appear. These are the name servers your domain will point to under your registrar’s management console. Once your domain name servers are configured with your registrar there might be a replication period or wait for this to take effect.

Once your Hosted Zone File is created you will then create 2 separate A records under your hosted zone. You can create DNS records by selecting “Create Record Set” under your hosted zone. For this Example I will be creating two separate A records, www.thesurgeagency.com and www2.thesurgeagency.com. www will be my primary website using IP 192.168.1.1, www2 will be my secondary website or failover website using an IP of 192.168.1.2. I’m using internal IP addresses for this demonstration but typically you would use a public IP address or elastic IP address. Even though we are creating www and www2 the end-user will never see www2 in their address bar. www2 is created so that Route 53 knows which is the primary IP address and the secondary IP address. When creating these records ensure the routing policy is simple for both records and the TTL is lowered to 60 seconds.

Primary Website (www.sados.com) A Record

Secondary Website (www2.sados.com) A Record

Now that you have created both A Records you Zone file should look like this.

Now we will create the website health checks. The Health Checks page is under “Hosted Zones” on the left toolbar. Here we will create our first health check.

Route 53 Health Checks can monitor various protocols including HTTP, HTTPS, and TCP. You can also monitor a domain name or even an IP address. you also get other options like “Enable String Matching” where the monitor will search for a specific string on the domain. These are all different variables that you can configure on your Route 53 health check. For this instance we will be using HTTP as our main protocol, and will be monitoring an IP address instead of a domain name. We will also change the request interval to fast instead of standard. All other options are left as default including the failure threshold. Again, I’m using internal IP addresses for this demonstration, typically you would be using a public IP address.

Note: If you try to continue with the IP address 192.168.1.1 You will receive an error stating this is forbidden. You should be using public IP Addresses. 

You can also configure an alarm where CloudWatch sends you an Amazon SNS notification whenever Route 53 health checkers consider the endpoint unhealthy for one minute.

Once the Health Check is created we will go back to the Hosted Zone www.thesurgeagency.com. Next we need to edit and create a new record set. First we will edit the primary A Record for www.thesurgeagency.com. Change this record’s routing policy from simple to failover, once this is done you should notice the Set ID says www-Primary. Lastly, we will need to associate this alias with the health check that we created earlier. Use the following image below for a guideline.

Once the primary record is finally configured, we will  need to configure the secondary Record. First you will create a new record and name it www.thesurgeagency.com. Make sure this record is configured as an alias, so don’t forget to select alias under the record type. Secondly, you will choose the Routing Policy as failover, then you will notice the SET ID will change to www-Secondary. These are all the settings that are needed in order to configure Route 53 failover.

When done your DNS Hosted Zone records should look like this below.

 

Primary Website:                                       Secondary Website:

Northern Virginia Region                               Northern California Region
IIS8 – Medium Instance                                 IIS8 – Medium Instance
IP: 192.168.1.1                                                   IP: 192.168.1.2

I currently have IIS8 running sados.com on an EC2 instance in the Northern Virginia region, I have another EC2 instance running a second copy of our website in the Northern California region. Both Servers have configured bindings to respond to www.thesurgeagency.com, The only configuration difference between both servers is that one server has a binding IP address of 192.168.1.1 and the other server has a binding IP address of 192.168.1.2. When users go to www.thesurgeagency.com, Route 53 will see that I have the routing policy on www.thesurgeagency.com configured as failover. As long as my primary website is up and running users will get the SET-ID www-Primary record, since that is the primary record for www.thesurgeagency.com. So if my primary website is operational users will get DNS for www.thesurgeagency.com as 192.168.1.1. If there was an outage and the primary server in Northern Virginia region is no longer available, the health checks will notice the server is no longer operational and Route 53 will start issuing the SET-ID www-Secondary record to users instead of the www-Primary record. This means that once the Health checks are aware of the outage, Route 53 will start issuing the www-Secondary SET-ID IP address. So now users will be getting www.thesurgeagency.com with an IP address of 192.168.1.2 instead of the primary address of 192.168.1.1. This change tends to happen fairly quickly, this is why we set the TTL or Time to Live for the record to 60 seconds so users have to update frequently.

DNS will not fail back automatically once the primary server is back. The previously known secondary server is now known as the primary server since that is where users are being directed. The easiest way to fail back to the primary server is to take down the secondary website or reboot the server. Basically, you have to cause the secondary server to go down so that the same process will happen over but in reverse. Now you will be going from your secondary server to your primary server. Once you get the secondary website to go down and the the health check notices that the primary website is up and running, Route 53 will change DNS to use the www-Primary SET-ID and start giving users the primary IP address.

I hope this was helpful with your DNS failover configuration. If you have any questions please feel free to email it@thesurgeagency.com. Thank You.

Jon Granados
Jon Granados
President/CEO · 28 posts
2 years ago
Jonathan Granados is the Chief Executive Officer at SADOS. Jon owes his success to a ladder of visible clients throughout his career in IT and network security. He's worked with clients from Spotify to the Department of Defense, and has a proven track record to getting the job done.

You might also like...

What Customers Say
It's about more than technology, it's about a dedication to building impactful relationships
Ready for anything, whatever the task, we provide dependable IT support, both on site and remote through our 24/7 help desk and chat support. We maximize workforce potential in companies of all sizes - building success stories through true relationships with each and every one our awesome clients.

After having many internet/wi-fi and phone issues for years at our office, SADOS has resolved them and made our workplace more efficient. We are so pleased with their commitment to finding the real problems, and their solutions to fix them. Dominick has been awesome – very responsive to our calls, and not happy until we’re happy. Thank you SADOS, Jon, and the team!

Cindy Schlossnagle
Keller Williams Columbia

When we moved our environment into the cloud we worked closely with SADOS. They were easy to work with and very responsive to our needs. They helped us navigate the intricacies of the AWS and perfected our network environment. Anyone looking to move their infrastructure to the cloud would be well-served by working with SADOS.

Donald Koch
South Mountain Creamery

Enforme used to host our own data-center. In doing so we had power costs, generator costs, cooling costs, hardware/warranty costs and many other costs that come along with hosting your own equipment. Now we have POP sites all over the world and double the resources at half the cost thanks to the cloud. Our cloud migration was one of the best decisions we could have made thanks to SADOS.

Eric Delente
Enforme Interactive

SADOS has been a great help. We contacted you to help migrate the Department of Justice, Office of Justice Programs to AWS Gov. Cloud. Their knowledge with cloud technology was an extreme help during this project. They prepared and created the infrastructure for this environment to allow future growth, fail over possibilities, and load balancing scenarios.

Chris Garver
UNISYS

Solid, experienced IT cloud transition partner specializing in moving traditional infrastructure environments to AWS and Azure. SADOS has the expertise and know how to help your company assess your current traditional infrastructure, formulate a transition plan and execute. In many cases, they can help you save thousands in monthly data center & support costs.

Walter Logue
Manitowoc

SADOS’ willingness to provide immediate support during a dire time was a godsend. Their team is not only genuinely invested in the success of their customers, but also highly qualified and more willing to do what it takes to provide a broad range of IT support services compared to others. They genuinely care about my business. All the other vendors I spoke to only offered to set up an appointment and wanted to discuss pricing right away. SADOS was the only company willing to do what needed to be done right away without hesitation. Direction.com is now where it needs to be thanks to SADOS.

Chris Kirksey
Direction Inc.