Deploying a Highly Available Web App and a Bastion Host in AWS

Hands-On Lab

 

Photo of Trent Hayes

Trent Hayes

Training Architect

Length

01:00:00

Difficulty

Intermediate

Welcome to this live environment where we are going to build a highly available web application along with a highly available bastion host architecture. To complete these tasks, you will need to add or configure the following services: 1) RDS Database from a Snapshot 2) Security Group and NACL rules 3) Launch configurations and AutoScaling Groups 4) Application Load Balancer 5) Route53 DNS record sets NOTE: Database Snapshot: arn:aws:rds:us-east-1:892710030684:snapshot:sysops-certification-la-course User_data can be obtained at the following: https://github.com/linuxacademy/content-aws-sysops-administrator.git Then click on LearningActivityUserData.txt <p><b> Attention: When selecting the AMI for your Bastion Host and Instance for your Web App, please use the Amazon Linux AMI </p></b> Good luck and enjoy the Learning Activity!

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.

Deploying a Highly Available Web App and a Bastion Host in AWS

Introduction

In this hands-on lab, we are going to build a highly available web application along with a highly available bastion host architecture.

Attention: When selecting the AMI for your bastion host and instance for your Web App, please use the Amazon Linux AMI.

Please go ahead and log in to the live environment with the cloud_user credentials provided.

Make sure you are using us-east-1 as your region throughout the lab.

Database Creation

We're going to launch an RDS database using the provided RDS backup image (which contains the WordPress site data).

First, we need to create a subnet group for the database. Then we can restore the database from a public snapshot.

Create a Subnet Group for the Database

  1. Navigate to the RDS console.
  2. Click Subnet groups in the sidebar.
  3. Click Create DB Subnet Group.
  4. For the Subnet group details, use the following settings:
    • Name: sng1
    • Description: sng1
  5. Under Add subnets, use the following settings for the first subnet:
    • Availability zone: us-east-1a
    • Subnet: 10.99.21.0/24
  6. Click Add subnet.
  7. Now, use the following settings for the second subnet:
    • Availability zone: us-east-1b
    • Subnet: 10.99.22.0/24
  8. Click Add subnet.
  9. Click Create.

Restore the Database from a Public Snapshot

  1. Click Snapshots in the sidebar.
  2. In the search box, paste in the following snapshot ARN:
    • arn:aws:rds:us-east-1:892710030684:snapshot:sysops-certification-la-course
  3. Change the dropdown to All Public Snapshots.
  4. Check the box next to the snapshot, and in the Actions dropdown, select Restore Snapshot.
  5. Under Instance specifications, use the following settings:
    • DB Instance Class: db.t2.micro
    • Multi-AZ Deployment: Yes
  6. Under Settings, use the following:
    • DB Instance identifier: wordpress-database
  7. Under Network & Security, the VPC and subnet group should auto-populate to what we need.
  8. Click Restore DB Instance.

Security Groups and NACLs

Next, we need to configure our security groups and NACLs.

  • Navigate to VPC.

Create Four Security Groups

  1. Click Create Security Group and use these settings:

    • Name tag: BastionSG
    • Group name: BastionSG
    • Description: BastionSG
    • VPC: Leave as default
    • Click Yes, Create.
  2. Repeat this step three more times, but using the following names for the remaining security groups we're creating:

    • LoadBalancerSG
    • WebServerSG
    • DatabaseSG

Configure the Security Groups

BastionSG

  1. Check the box next to BastionSG.
  2. Click the Inbound Rules tab.
  3. Click Edit and use the following settings:
    • Type: SSH
    • Source: 0.0.0.0/0
  4. Click Save.

LoadBalancerSG

  1. Check the box next to LoadBalancerSG.
  2. For its inbound rules, click Edit, and use the following settings:
    • Type: HTTP
    • Source: 0.0.0.0/0
  3. Click Add another rule, and use these settings:
    • Type: HTTPS
    • Source: 0.0.0.0/0
  4. Click Save.

WebServerSG

  1. Check the box next to WebServerSG.
  2. For its inbound rules, click Edit, and use the following settings:
    • Type: SSH
    • Source: BastionSG
  3. Click Add another rule, and use these settings:
    • Type: HTTP
    • Source: LoadBalancerSG
  4. Click Add another rule, and use these settings:
    • Type: HTTPS
    • Source: LoadBalancerSG
  5. Click Save.

DatabaseSG

  1. Check the box next to DatabaseSG.
  2. For its inbound rules, click Edit, and use the following settings:
    • Type: MySQL
    • Source: WebServerSG
  3. Click Save.

Add Rules to Existing NACLs

Now, we're going to add the necessary rules to the existing NACLs, including ephemeral ports.

  • Click Network ACLs in sidebar.

Inbound Rules for DMZNACL

  1. Check the box next to DMZNACL.
  2. Click the Inbound Rules tab.
  3. Click Edit, Add another rule, and use the following settings:
    • Rule #: 100
    • Type: SSH
    • Source: 0.0.0.0/0
  4. Click Add another rule, and use these settings:
    • Rule #: 110
    • Type: HTTP
    • Source: 0.0.0.0/0
  5. Click Add another rule, and use these settings:
    • Rule #: 120
    • Type: HTTPS
    • Source: 0.0.0.0/0
  6. Click Add another rule, and use these settings:
    • Rule #: 130
    • Type: Custom TCP Rule
    • Port Range: 1024-65535
    • Source: 0.0.0.0/0
  7. Click Save.

Outbound Rules for DMZNACL

  1. Click the Outbound Rules tab.
  2. Click Edit, Add another rule, and use the following settings:
    • Rule #: 100
    • Type: SSH
    • Source: 0.0.0.0/0
  3. Click Add another rule, and use these settings:
    • Rule #: 110
    • Type: HTTP
    • Source: 0.0.0.0/0
  4. Click Add another rule, and use these settings:
    • Rule #: 120
    • Type: HTTPS
    • Source: 0.0.0.0/0
  5. Click Add another rule, and use these settings:
    • Rule #: 130
    • Type: Custom TCP Rule
    • Port Range: 1024-65535
    • Source: 0.0.0.0/0
  6. Click Save.

Inbound Rules for AppNACL

  1. Check the box next to AppNACL.
  2. Click the Inbound Rules tab.
  3. Click Edit, Add another rule, and use the following settings:
    • Rule #: 100
    • Type: SSH
    • Source: 10.99.0.0/16
  4. Click Add another rule, and use these settings:
    • Rule #: 110
    • Type: HTTP
    • Source: 10.99.0.0/16
  5. Click Add another rule, and use these settings:
    • Rule #: 120
    • Type: HTTPS
    • Source: 10.99.0.0/16
  6. Click Add another rule, and use these settings:
    • Rule #: 130
    • Type: Custom TCP Rule
    • Port Range: 1024-65535
    • Source: 0.0.0.0/0
  7. Click Save.

Outbound Rules for AppNACL

  1. Click the Outbound Rules tab.
  2. Click Edit, Add another rule, and use the following settings:
    • Rule #: 100
    • Type: SSH
    • Destination: 0.0.0.0/0
  3. Click Add another rule, and use these settings:
    • Rule #: 110
    • Type: HTTP
    • Destination: 0.0.0.0/0
  4. Click Add another rule, and use these settings:
    • Rule #: 120
    • Type: HTTPS
    • Destination: 0.0.0.0/0
  5. Click Add another rule, and use these settings:
    • Rule #: 130
    • Type: Custom TCP Rule
    • Port Range: 1024-65535
    • Destination: 10.99.0.0/16
  6. Click Save.

Inbound Rules for DBNACL

  1. Check the box next to DBNACL.
  2. Click the Inbound Rules tab.
  3. Click Edit, Add another rule, and use the following settings:
    • Rule #: 100
    • Type: MYSQL/Aurora
    • Source: 10.99.0.0/16
  4. Click Add another rule, and use these settings:
    • Rule #: 110
    • Type: Custom TCP Rule
    • Port Range: 1024-65535
    • Source: 0.0.0.0/0

Outbound Rules for DBNACL

  1. Click the Outbound Rules tab.
  2. Click Edit, Add another rule, and use the following settings:
    • Rule #: 100
    • Type: MYSQL/Aurora
    • Destination: 10.99.0.0/16
  3. Click Add another rule, and use these settings:
    • Rule #: 110
    • Type: Custom TCP Rule
    • Port Range: 1024-65535
    • Destination: 10.99.0.0/16
  4. Click Save.

Auto Scaling Groups

Next, it's time to get the instances up and running. Our architected design requires two Auto Scaling groups: one for the bastion host and one for the application servers.

  • Navigate to the EC2 page, and click Auto Scaling Groups in the sidebar.

Create Launch Figuration for First Auto Scaling Group

  1. Click Create Auto Scaling group, and then Create launch configuration.
  2. Click Select beside Amazon Linux AMI.
  3. Leave t2.micro chosen, and click Next: Configure details.
  4. Give it a Name (e.g., "BastionLC").
  5. Click Advanced Details, and paste the following into the User data box:
    #!/bin/bash
    /bin/echo '%password%' | /bin/passwd cloud_user --stdin
    yum update -y
    yum install -y git
    mkdir /home/cloud_user/.aws
    git clone https://github.com/linuxacademy/content-aws-sysops-administrator.git
    cd content-aws-sysops-administrator/config/
    mv config /home/cloud_user/.aws/
  6. For IP Address Type, select Assign a public IP address to every instance.
  7. Click Next: Add Storage.
  8. Leave the defaults, and click Next: Configure Security Group.
  9. For Assign a security group, choose Select an existing security group.
  10. Select BastionSG.
  11. Click Review, and then Create launch configuration.
  12. Create a new key pair (example name: "sysopskey"), and download it.
  13. Click Create launch configuration.

Create First Auto Scaling Group

  1. On the Create Auto Scaling Group page, use the following settings:
    • Group name: BastionASG
    • Group size: 1 instance
    • Network: Use the default VPC
    • Subnet: DMZ1public and DMZ2public
  2. Click Configure scaling policies.
  3. Select Keep group at its initial size, and click Review.
  4. Click Create Auto Scaling group, and then Close.

Create Launch Configuration for Second Auto Scaling Group

  1. Click Launch Configurations in the sidebar.
  2. Click Create launch configuration.
  3. Click Select beside Amazon Linux AMI.
  4. Leave t2.micro chosen, and click Next: Configure details.
  5. Give it a Name (e.g., "WebServerLC").
  6. Click Advanced Details, and paste the following into the User data box:
    #!/bin/bash
    yum update -y
    yum install -y httpd24 php70 mysql56-server php70-mysqlnd git
    cd /var/www/html
    git clone https://github.com/linuxacademy/content-aws-sysops-administrator.git
    cd content-aws-sysops-administrator/wp-site/
    mv * /var/www/html
    groupadd www
    usermod -a -G www ec2-user
    chown -R root:www /var/www
    chmod -R 2775 /var/www
    echo '&lt;?php phpinfo(); ?&gt;' &gt; /var/www/html/phpinfo.php
    service httpd start
    chkconfig httpd on
    service mysqld start
    chkconfig mysqld on
  7. For IP Address Type, select Do not assign a public IP address to my instances.
  8. Click Next: Add storage.
  9. Leave the defaults, and click Next: Configure Security Group.
  10. For Assign a security group, choose Select an existing security group.
  11. Select WebServerSG.
  12. Click Review, and then Create launch configuration.
  13. Choose the existing key pair we just created.
  14. Click Create launch configuration, and Close.

Create Second Auto Scaling Group

  1. Click Auto Scaling Groups in the sidebar.
  2. Click Create Auto Scaling group.
  3. Choose WebServerLC, and click Next Step.
  4. On the Create Auto Scaling Group page, use the following settings:
    • Group name: WebServerASG
    • Group size: 2 instances
    • Network: Use the default VPC
    • Subnet: AppLayer1private and AppLayer2private
  5. Click Configure scaling policies.
  6. Select Keep group at its initial size, and click Review.
  7. Click Create Auto Scaling group, and then Close.

Modifying the Database and Creating the Application Load Balancer

Next, we need to update the RDS instance's security group. Then, we can create an elastic load balancer that distributes traffic to the application servers and add it to the Auto Scaling group.

  • Navigate to the RDS console.

Modify the Database

  1. Click Instances in the sidebar.
  2. Click our available instance.

Note: Before we modify anything, in the Connect section, copy the Endpoint listed and paste it into a note or text file — we're going to need it in a few minutes for the last part of the lab.

  1. In the Details section, click Modify.
  2. In the Network & Security section, delete the default security group listed.
  3. Choose our DatabaseSG from the Security group dropdown.
  4. Click Continue.
  5. Select Apply Immediately, and then Modify DB Instance.

Create the Application Load Balancer

  1. Navigate to EC2, and then click Load Balancers in the sidebar.
  2. Click Create Load Balancer.
  3. In the Application Load Balancer box, click Create.
  4. Use the following configuration settings:
    • Under Basic Configuration, give it a Name of "ALB1".
    • Under Availability Zones, select the default SysOpsVPC and check both availability zones.
  5. Click Next: Configure Security Settings.
  6. Click Next: Configure Security Groups.
  7. Un-check the default security group, and select LoadBalancerSG.
  8. Click Next: Configure Routing.
  9. In the Target group section, give it a Name of "TG1".
  10. In the Health checks section, enter the path "/readme.html".
  11. Click Next: Register Targets.
  12. Click Next: Review, and then Create.

Edit Auto Scaling Group to Communicate with Application Load Balancer

  1. Click Auto Scaling Groups in the sidebar.
  2. Select WebServerASG.
  3. In the Details section below, click Edit.
  4. Click into Target Groups box, and select TG1.
  5. Click Save.

Configuring Route53 DNS Record Sets

Finally, we need to create the DNS record for the database. The instances will use this to connect to the database.

Then, we can add alias records to the lab record set that point to the application load balancer, and finally test the application using the lab record set DNS name.

The finish line is in sight! Let's do it.

Create and Configure DNS Record Sets for the Application

We're going to create two Route 53 DNS record sets:

  • One CNAME record set that points to the RDS database endpoint
  • One Type A record set that points the domain name to the ELB
  1. Navigate to the Route 53 console.
  2. Click Hosted zones.
  3. Click Create Hosted Zone, and use the following settings:
    • Domain Name: sysopsdatabase.com
    • Type: Private Hosted Zone for Amazon VPC
    • VPC ID: SysOpsVPC (in us-east-1)
  4. Click Create.
  5. Click Create Record Set again, and use the following settings:
    • Name: database.sysopsdatabase.com
    • Type: CNAME – Canonical name
    • Value: Endpoint of the database instance, which you pasted into a note or text file a few steps back
  6. Click Create.
  7. Click Back to Hosted Zones.
  8. Click the other hosted zone that was already listed (it'll be something like cmcloudlabxxxx.info).
  9. Click Create Record Set, and use the following settings:
    • Alias: Yes
    • Alias Target: Our ELB application load balancer
  10. Click Create.
  11. Click Create Record Set, and use the following settings:
    • Name: www
    • Alias: Yes
    • Alias Target: Our ELB application load balancer
  12. Click Create.
  13. Test the application by entering cmcloudlabxxxx.info into a browser, and you should see the SysOps Codex Homepage.

Conclusion

All of these are important parts of a highly available architecture, and anyone serving a job function in the AWS environment should know them.

You did it! Congratulations on completing this lab!