Failover Mechanism in Amazon Route 53 Private Hosted Zones

AWS Cloud Hands-on Lab Practice Series

Project Overview —

The AWS Route 53 Failover project aims to architect a secure, cost-efficient, Fault tolerant and Highly available cloud environment. The project’s primary goal is to provide how to configure DNS entries on Amazon Route 53 to do dynamic routing between resources in different AWS regions while adhering to AWS best practices and compliance requirements.

SOLUTIONS ARCHITECTURE OVERVIEW –

First Let’s understand the real world use case :

1.Disaster Recovery: In a disaster recovery setup, where you have primary and secondary data centers or regions, failover policies can automatically redirect traffic from the primary to the secondary site in case of a failure.

Example: let’s say you have a primary data center in US-East (Virginia) and a secondary data center in US-West (Oregon). If the primary data center experiences an outage, Route 53 failover policies can redirect traffic to the secondary data center.

2.Multi-Region Redundancy: For global applications that require high availability, you may deploy identical application stacks in multiple AWS regions. Failover policies can route traffic to the closest healthy region or distribute traffic evenly across regions based on health checks.

Example: If your application is deployed in US-East (Virginia) and EU-West (Ireland), Route 53 can route traffic to the region with the lowest latency or the region that passes health checks.

3.Blue/Green Deployments: During software updates or deployments, you can use failover policies to perform blue/green deployments.

Example : For instance, suppose you have a production environment (blue) and a staging environment (green). You can update the staging environment, run health checks, and then switch traffic from the production environment to the staging environment using failover policies once the update is successful.

4.Highly Available Database Replication: Failover policies can be used to manage database failover scenarios where you have active-passive or active-active database replication setups.

Example: For instance, if you have a primary database in one availability zone and a standby database in another availability zone, Route 53 can automatically redirect traffic to the standby database if the primary database becomes unavailable.

5.Content Delivery Networks (CDNs): In CDN setups, failover policies can be employed to route traffic to alternate CDN endpoints in case of CDN node failures or performance degradation.

Example: If you have CDN endpoints in different regions or with different providers, Route 53 can direct traffic to the next best endpoint if the primary endpoint experiences issues.

Also when considering the use of failover policies in Amazon Route 53 Private Hosted Zones within the context of the Well-Architected Framework (AWS WAR), it primarily aligns with the “Reliability” and “Operational Excellence” pillars.

Prerequisite —

AWS Account with Admin Access.

AWS CLI user with Access key & Secret Key.

AWS Services Usage —

AWS Route53, VPC, EC2, SSM, S3, CloudFormation and IAM

STEP BY STEP GUIDE –

STEP 1 : Clone the GitHub Repo

Navigate to following GitHub Repository AWS-Route53-Failover

Clone the repo to download the CloudFormation Template & code used for this lab.

CloudFormation template name — route53-vpc-cfn-template.yaml

STEP 2 : Creating AWS resources through CloudFormation service.

Login to AWS account, Navigate to AWS CloudFormation Service.

Head over & change the region of the aws console where you want to deploy the Primary region resources. (SITE-A)

Click on Create Stack & upload the template downloaded in the step 1.

VPC CIDR (SITE-A) : 10.0.0.0/16

PublicSubnet : 10.0.1.0/24

This stack will create one VPC and create a public subnet with two EC2 instances, an internet gateway, with a default route on the public subnet in regions you deployed.

NOW Head over & change the region of the aws console where you want to deploy the Secondary region resources. (SITE-B)

Click on Create Stack & upload the template downloaded in the step 1.

VPC CIDR (SITE-B) : 10.1.0.0/16

PublicSubnet : 10.1.1.0/24

This stack will create one VPC and create a public subnet with two EC2 instances, an internet gateway, with a default route on the public subnet in regions you deployed.

STEP 3 : Creating a VPC Peering to connect both regions

Option 1: Use AWS CloudShell to run the commands.

Option 2: From your local machine where you have aws cli working with appropriate access key & secret key.

Make sure to edit the regions before running the commands

Run the commands given in VPC env variable script.txt file.

Get the VPC ID of the respective VPC’s created.

Now Run the commands given VPC Peering Script.txt file.

This will create VPC peering between two VPCs from different AWS Regions (SITE A & SITE B).

STEP 4 : Creating Private DNS entries:

Create a Route 53 — Private Hosted Zone for the acloudguy.internal DNS entries by associating the Site A.

You can change the hosted zone name according to your wish.

Run the commands from private DNS entries.txt file.

STEP 5 : Creating Route 53 Health Check:

Get the public IP of both Web Servers. This is because Route 53 health checkers are public and they can only monitor hosts with IP addresses that are publicly routable on the internet.

Run the command from Public-IP-For-Route53-HealthChecks.txt file.

You need to create a health check policy file: health check policy.txt

Now, Let’s create the health check for our primary endpoint that is in SITE A region.

Run the command from Primary-HealthCheck-Record.txt file.

The health check will be active in 30–60 seconds.

Go to Route53 Console & check the health check section.

STEP 6 : Creating Route 53 Failover Policy:

Get the private IP of both Web Servers.

Run the command from Private-IP-For-Route53-HealthChecks.txt file.

Run the Failover routing policy from Failover policy.txt file.

TIP : It’s being used Private IP to keep the communication through VPC Peering.

Now Associate the traffic policy to Route53 Private Hosted Zone.

Run the command from Associate Failover Policy.txt file.

We just created a policy similar to the image below: (your public IP & Private IP will be different)

STEP 7 : Test the failover policy:

Connect to EC2 Instance through EC2 Connect from SITE A.

Try to access the website using “service.acloudguy.internal”

dig +short service.acloudguy.internal

curl service.acloudguy.internal

You will below responses from it.

Now to test the failover, remove Security Group Inbound rules of Primary Site A EC2 Instance from AWS Console.

Once there is no Inbound rule to EC2 Instance.

After 2 minutes, the Health Check will mark the PRIMARY EC2 Instance as UNHEALTHY and will trigger the failover mechanism.

Health Check will fail & route the traffic to Secondary Site B EC2 Instance.

We can run the commands again

dig +short service.acloudguy.internal

curl service.acloudguy.internal

STEP 8 : Decommission:

Delete all the resources created during the lab.

aws ec2 delete-vpc-peering-connection — vpc-peering-connection-id $PEERING_ID

Delete the CloudFormation Stacks from SITE A & SITE B Regions.

Delete Route53 Health Checks from AWS Console.

Delete Route53 Traffic Policy and Private Hosted Zone from Console

Delete files health-check-config.json & failover-policy.json

Congrats ! We have successfully completed lab for How to Implement Failover Policies in Amazon Route 53 Private Hosted Zones.

I am Kunal Shah, AWS Certified Solutions Architect, helping clients to achieve optimal solutions on the Cloud. Cloud Enabler by choice, DevOps Practitioner having 8+ Years of overall experience in the IT industry.

I love to talk about Cloud Technology, DevOps, Digital Transformation, Analytics, Infrastructure, Dev Tools, Operational efficiency, Serverless, Cost Optimization, Cloud Networking & Security.

aws #community #builders #VPC #route53 #failover #mechanism #cloudformation #disaster #recovery #network #security #hybrid #network #peering #isolated #solution #war #reliability #operations #Excellence #infrastructure #scalable #highly #available #blue #green #deployment #private #secure #design #acloudguy

You can reach out to me @ acloudguy.in