This lab illustrates how to create and remotely access a dynamodb table. Dynamodb is a NoSQL managed database service.

 

Overview

Step 1 - Create a Dynamodb Table

Go to Database - Dynamodb service and click on Create table.

   

Step 2 - Create and Download an Access Key

Go to IAM - Users and then select your user. Then go to Security credentials and create an access key. Download the key you created (a csv file) and use it on the next step.

Step 3 - Connect to Dynamodb Table

Download and install NoSQL Workbench. Follow the steps to connect to your dynamodb table.

  

Test and Validation

After you connect, try to visualize the contents of the table and modify it.

 

This lab is similar to lab-009 with the addition of a read replica RDS instance, a read-only copy of the database.

 

Architecture Diagram

Overview

Follow the steps described in lab-009 with the following changes when creating the RDS instance:

• Templates: Dev/Test (free-tier won't work this time)
• DB instance identifier: lab011
• DB instance size: select Burstable classes and pick the db.t2.small
• Connectivity: set your custom VPC to be the one where your RDS instance will run; in the additional connectivity configuration - VPC security group, choose Create new and name it lab011sg; finally for the availability zone choose the one suffixed with 1a (or the first option that appears to you)
• Additional configurations: set the initial database name to lab011 and make sure automatic backups is enabled.

Step 1 - Create Read Replica

Select Actions - Create read replica.

Create the replica in a different AZ. Also, have it in the same security group lab011sg. For the DB instance identifier choose the name lab011ro. After a few minutes you should be able to see your read replica instance created.

Test and Validation

Have the phpMyAdmin configuration to first connect to the primary (master) database instance. Create a table (or modify and existing one). You should be able to do it.

Then try to connect to the read replica instead. Note that the read replica cluster has a different endpoint. You should be able to see the table modification that you did previously. Now try to modify the database (create a table or modify an existing one). You should not be able to do that now as the database is running in read-only mode.

This lab is similar to lab-009 with the addition of a standby RDS instance in another AZ to simulate a failover scenario.

 

Architecture Diagram

Overview

Having an RDS instance in a multi-az configuration means that another instance will run on standby mode in another AZ. Writings done on the primary instance are also done on the secondary, and this is done synchronously. In the case of a failure of the primary, the secondary (the one running on standby mode) takes over and become the primary database instance.

Follow the steps described in lab-009 with the following changes when creating the RDS instance:

• Templates: Dev/Test (free-tier won't work this time)
• DB instance identifier: lab010
• DB instance size: select Burstable classes and pick the db.t2.small
• Multi-az deployment: select multi-az deployment (of course)
• Connectivity: set your custom VPC to be the one where your RDS instance will run; in the additional connectivity configuration - VPC security group, choose Create new and name it lab010sg; finally for the availability zone choose the one suffixed with 1a (or the first option that appears to you)
• Additional configurations: set the initial database name to lab010 and disable automatic backups

Test and Validation

Open a browser and using the EC2 instance's public IP address, connect to the database via phpMyAdmin in the same way explained in lab-009. The screen below shows on which AZ the primary RDS instance is running.

To simulate a failure, select Action and then Reboot.

On the next screen, choose Reboot With Failover.

You should then notice that the secondary takes over and becomes the primary. You can attest that by verifying that the database is now running on a different AZ.

Make sure you can still access the database via phpMyAdmin. The change should take only a few seconds.

This lab illustrates how to launch a standalone RDS instance running a MySQL database. An EC2 instance will also be launched to allow access to the database using phpMyAdmin. Here is a mind map of RDS.

 

Architecture Diagram

Overview

The Amazon Relational Database Service (Amazon RDS) offers a managed service based on relational databases. In this lab you will be configuring RDS to use MySQL, an open source database. For simplicity, you will not configure more advanced features available in RDS, such as multi-az deployment or read replicas. To verify that RDS is working, you will configure an EC2 instance with Apache and phpMyAdmin, a free software tool written in PHP that simplifies administration of a MySQL database over the Web.

Step 1 - Create a Custom VPC with Two Public subnets

Start this lab by configuring an internet gateway on a custom VPC. Make sure there is a default route for your VPC's internet gateway. Make sure your public subnets are configured in distinct AZs and that auto-assign IPv4 is enabled.

Step 2 - Launch an RDS Instance

Below are some of the main options you should select:

• Database creation method: Standard Create
• Engine option: MySQL
• Templates: Free tier
• DB instance identifier: lab009
• Master password: 12345678 (not safe but this is just a lab)
• DB instance size: Standard classes
• Storage: default options are fine for this lab
• Multi-az deployment: if you selected the free tier template you should not even be able to select multi-az deployment options
• Connectivity: set your custom VPC to be the one where your RDS instance will run; in the additional connectivity configuration - VPC security group, choose Create new and name it lab009sg; finally for the availability zone choose the one suffixed with 1a (or the first option that appears to you)
• Additional configurations: set the initial database name to lab009 and disable automatic backups

Step 3 - Launch an EC2 Instance

Configure an EC2 instance in the public subnet in the same AZ where your RDS instance was launched. Use the user-data. Create a security group that allows SSH and HTTP access to your instance from anywhere.

Step 4 - Modify RDS's Security Group

Modify the inbound rule of the RDS's security group to enable access from the EC2's instance.

 

Step 5 - Apply RDS's Security Group to EC2 Instance

In order for your EC2 instance to be able to access the RDS instance it has to be in the same security group created in step 2.

 

Step 5 - Configure phpMyAdmin

• Connect to your EC2 instance via SSH
• Run the following commands (requires privileged access):

cd /var/www/html
tar xvf phpMyAdmin-latest-all-languages.tar.gz
rm -rf phpMyAdmin-latest-all-languages.tar.gz
ln -s phpMyAdmin-5.0.2-all-languages phpMyAdmin
cd phpMyAdmin
cp config.sample.inc.php config.inc.php

Edit config.inc.php and search for a reference to localhost. Replace it with your RDS instance endpoint.

Test and Validation

Open a browser and using the EC2 instance's public IP address, connect to the database via phpMyAdmin.

http://<public IP EC2 instance>/phpMyAdmin

This is lab is similar to lab-007 with a caveat: the auto scaling group is configured to create the EC2 instances in the private subnet. Also, two security groups control traffic in and out of the application load balancer and the EC2 instances (in the private subnets). To enable the EC2 instances to respond to requests coming from the internet, NAT gateways were configured on the public subnets of the VPC.

 

Architecture Diagram

Step 1 - Create VPC, Subnets, and Internet Gateway

Step 2 - Update Main Route Table and Configure Nat Gateways

Step 3 - Create new Route Tables

Step 4 - Configure Security Groups

Step 5 - Configure Auto Scaling

Step 6 - Configure the Application Load Balancer

This lab is a continuation of lab-006 with a Load Balancer added.

 

Architecture Diagram

Overview

Step 1 - Create the Application Load Balancer

Follow step 5 of lab-005, but do not add any targets to the load balancer target group.

Step 2 - Edit the Auto Scaling Group

Edit the auto scaling group adding the load balancer target group created in the previous step.  

Test and Validation

Copy the DNS name associated with the load balancer and, using a browser, try to access it. You should be able to see the response associated with the only EC2 instance that is running and automatically launched by the auto scaling service. Now connect to this instance through SSH and run the following commands to artificially increase CPU utilization.