Route 53 DNS Failover of Website from EC2 Instance to Static Website Hosted on S3

Hands-On Lab

 

Photo of Tia  Williams

Tia Williams

AWS Training Architect II in Content

Length

01:15:00

Difficulty

Intermediate

In this live environment, we will configure a website to failover from an EC2 instance to a static failover website hosted on s3. To meet our objective, we will create a website on an EC2 instance, configure Route 53 with failover routing, and configure an s3 bucket where we host a static failover website. We will then simulate failover by stopping the EC2 instance, and our website address will then failover to the failover.html file hosted on our s3 bucket.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Route 53 DNS Failover of Website from EC2 Instance to Static Website Hosted on S3

In this lab, we will configure a website to failover from an EC2 instance to a static failover website hosted on S3. To meet our objective, we will create a website on an EC2 instance, configure Route 53 with failover routing, and configure an S3 bucket where we host a static failover website. We will then simulate failover by stopping the EC2 instance, and our website address will then failover to the failover.html file hosted on our S3 bucket.

To begin, log in to our lab environment as cloud_user with the password provided on the lab page. Make sure you are using us-east-1 (N. Virginia) as your region throughout the lab.

Launch an EC2 Instance

The first thing we're going to do is configure our EC2 instance, install Apache, and configure our index.html file on the server so it can host our website.

Under AWS services at the top, type "EC2." It's also in the All services list; you can find it there by clicking All services and clicking EC2 under the Compute header.

On the EC2 Dashboard, notice that we don't currently have any instances running. Click Launch Instance, and select Amazon Linux AMI 2018.03.0.

Next, select General purpose t2.micro from the list of instance types, and click Next: Configure Instance Details.

On the Configure Instance Details screen, notice we've precreated a VPC and subnet for the lab, so we'll leave those settings. Under Auto-assign Public IP, click Enable. We'll leave the rest of the settings, but here's what they do:

  • Placement group: Determines how instances are placed on underlying hardware, as well as ensures instances are clustered together for performance or spread across different hardware.
  • IAM role: Gives varying levels of access to a resource.
    • We've preconfigured this lab environment, and roles are not required, so we can ignore the error message, which is the result of the restrictions we've placed in our lab environment.
  • Shutdown behavior: Determines if an EC2 instance should stop or terminate when shutdown is initiated.
  • Termination protection: Prevents accidental deletion of our EC2 instance.
  • Monitoring: By enabling CloudWatch, we can monitor our instance.
  • Tenancy: Sets up the instance to run on shared hardware or dedicated hardware.

Again, we aren't going to change any of these settings, so click Next: Add Storage.

The instance is set up automatically with a root volume by default, and for this lab, we don't need any additional volumes, so click Next: Add Tags.

We're not going to add any tags, so click Next: Configure Security Group.

On the Configure Security Group screen, click Select an existing security group. We've preconfigured a security group, so select that one. Make sure you don't select the default security group — we can't use one for this instance.

At the bottom, we'll see the rule we preconfigured allows ports 22-80 from any IP address. In a real environment, we wouldn't want to allow all ports — we'd want to specifically set the ports that are necessary for using our environment. Click Review and Launch.

On the Review Instance Launch screen, we're going to receive a warning message at the top about the fact our security group is open to the world. That's fine because the instance will be terminated shortly after we finish the lab. Click Launch.

In the Select an existing key pair or create a new key pair pop-up, click the default Choose an existing key pair to open the dropdown, and select Create a new key pair. In Key pair name, enter "ec2_s3failover" and click Download Key Pair. Make sure you check where it's saved (most likely to your Downloads folder) because we'll need it soon. Click Launch Instances.

On the Launch Status page, click View Instances.

We've officially launched our EC2 instance.

Configure the EC2 Instance from the CLI

It may take a few minutes for the Status of our instance to change to running. If it still says pending, click the circular-arrow refresh icon in the Launch Instance toolbar to see if it's done.

(Note: There are several times throughout this lab where we need to paste in the IP address assigned to our EC2 instance, so you might want to copy and paste it into a note or doc on your desktop for easy access. You can find the IP address in the Description tab at the bottom. Copy it the old-fashioned way, or click the double-papers copy icon that appears when you hover over the IP address, and paste it wherever you can quickly grab it going forward.)

To start the next step, if you're on a Mac, open a Terminal session. (Note: If you are using Windows, you will need an SSH client such as PuTTY. Here are some instructions on how to use a Windows computer to connect to a Linux EC2 instance using a key pair.)

First, we need to change the permissions on the .pem file we downloaded to make it read-only, so enter:

$ chmod 400 Downloads/ec2_s3failover.pem

Now, we're ready to connect to our instance by entering:

$ ssh -i Downloads/ec2_s3failover.pem ec2-user@IP_ADDRESS

Make sure to replace IP_ADDRESS with your EC2 instance's public IP address.

A prompt will ask, "Are you sure you want to continue connecting (yes/no)?" Type yes.

We're now connected to our instance.

Next, let's make sure all our packages are up to date.

$ sudo yum update -y

This may take a few minutes. Once it's done, install Apache:

$ sudo yum install httpd

A prompt will ask, "Is this ok [y/d/N]." Enter y.

Let's start the Apache service:

$ sudo service httpd start

Set it to start up automatically at boot:

$ sudo chkconfig httpd on

Now, we need to change into our HTML directory:

$ cd /var/www/html

We need to use an editor to create our index.html file. Linux has different types of editors. In this case, we're going to use Nano. So we'll type:

$ sudo nano index.html

This command creates the file.

Next, we need to open our HTML statement, and we'd like to format the text on our web page. Here's the index.html file we've pre-created. Copy the text there.

We want to format the text as a heading:

<html> <h1> Welcome Linux Academy Students! Let's Test Failover Routing with Route 53 </h1></html>

Now, hit Ctrl+O to write the file, hit Enter to save it, and hit Ctrl+X to exit the editor.

Open a new browser tab, and paste in the IP address of our EC2 instance to see what our web page looks like. Right now, it should look like the simple header we just added, so we're on track.

Next, we're going to use Route 53 to map our website address to our IP address. Head back to the EC2 Management Console.

Click Services at the top, and click Route 53 under Networking & Content Delivery. We'll see some error messages related to permissions for things we don't need access to for this lab, so we can ignore those.

Click Hosted zones in the sidebar, and copy the domain name listed.

(Note: You might want to paste this domain name into a note or doc like you did with the IP address. We’ll need it a few more times.)

Click Health checks in the sidebar, click Create health check, and paste the domain name into the Name field on the Configure health check section. We could name the health check whatever we want, but for this lab, we'll just use the domain name. Leave the default setting for What to monitor (which should be Endpoint).

Under Monitor an endpoint, make sure IP address is selected for Specify endpoint by and leave HTTP as the Protocol. Enter the IP address of our EC2 server. For Path, enter "index.html." Click Next.

On the Get notified when health check fails page, leave the setting, and click Create health check.

We'll see a Status error, since the health checks haven't had the chance to run and validate that the web page is active. We can ignore that message.

Click Hosted zones in the sidebar, and click the domain name. Click Create Record Set at the top. The Name field here is where we could add the www prefix to our domain name. For this instance, we don't need to add that. Leave the Type as A — IPv4 address, and make sure the Alias is set to No.

In the Value box, enter the IP address. For the Routing Policy, select Failover. For Associate with Health Check, click Yes. Under Health Check to Associate, select the health check we created. Click Create.

Let's make sure our website address resolves to the IP address of our EC2 server instance. Open a new browser tab, and paste in the domain name. It may take a few moments, but we should eventually see our web page.

Create a Static Website on S3 and Create Route 53 with an Alias Record and Simulate Website Failover

The last part of this lab is testing our failover.

In the AWS Management Console, click Services, and click S3 under Storage. Click + Create bucket. For Bucket name, paste in our DNS domain name. The Region should be US East (N. Virginia). Click Next.

We'll leave the properties as-is, so click Next.

In the Set Permissions tab, uncheck all four boxes that are checked by default (there are two boxes under Manage public access control lists (ACLs) for this bucket and two boxes under Manage public bucket policies for this bucket.) Click Next.

In the Review tab, click Create bucket.

Now, click the bucket we created.

We want to upload an object — in this case, we want to upload the failover.html file we've pre-created, which you can download here. Download it by right-clicking Raw, selecting Save Link As..., and saving it as an HTML text file.

Click Upload in the bucket page, click Add files, and select failover.html. Once it's uploaded, click Next.

Set the Manage public permissions dropdown to Grant public read access to this object(s), and click Next.

We'll leave all the properties as-is again, so click Next.

Click Upload.

Once our failover.html file has been uploaded, click the Properties tab at the top, and click Static website hosting. Select Use this bucket to host a website. Under Index document, enter "failover.html." Copy the URL listed after Endpoint, and click Save.

Open a new browser tab, and paste in the website address we just copied from S3. We should see a new web page that says we successfully used Route 53 to failover to the S3 static failover website. This lets us know we're able to load our web page on S3.

Now, we need to go to Route 53 and configure the secondary route.

Back in the S3 Management Console, click Services at the top, and click Route 53 in the sidebar. Click Hosted zones, click the domain name, and click Create Record Set.

In Alias, select Yes. Under Alias Target, select the S3 website endpoint we just created. Under Routing Policy, select Failover. Set the Failover Record Type to Secondary. Leave the default settings for Evaluate Target Health and Associate with Health Check. Click Create.

Let's test our scenario. Click Services at the top, and click EC2 in the sidebar, and then click Instances in the sidebar. Make sure our running EC2 instance is selected in the dashboard, click Actions, hover over Instance State, and select Stop. Click Yes, Stop.

Go back to our initial website, and click refresh. It'll take a few minutes for failover to actually happen because the health checks have to hit their timeout first, so don't panic if it doesn't immediately show up. After a bit (meaning upwards of five minutes), we should see we've successfully used Route 53 to failover to our static website on S3.

Conclusion

To recap, we just created a website on an EC2 instance, configured Route 53 with failover routing, configured an S3 bucket where we hosted a static failover website, simulated failover by stopping the EC2 instance, and successfully used Route 53 to failover to the failover.html file hosted on our S3 bucket.

Congratulations on completing this lab!