Creating an RDS database instance involves a simple four-step process. To begin with, select the Instances option from the navigation pane, as shown in the following screenshot. Next, select the Launch DB Instance button to bring up the DB Launch Wizard:

Step 2 – Production?

Now here comes the fun part! RDS basically allows you to create a database based on your requirements; for example, a production database with multi-AZ support and provisioned IOPS storage or a simpler database that has none of these add-on features. With Multi-AZ deployments, your DB instance is guaranteed with a monthly uptime SLA of 99.95 percent! However, because of such high SLAs, Multi-AZ deployments are not covered under the AWS Free Tier usage scheme. Click on Next Step to continue, as shown in the following screenshot:

Step 3: Specify DB Details

The next page of the wizard will help you configure some important settings for your DB instance:

• License Model: Select the appropriate database License Model as per your database engine's selection. MySQL databases have only one license model; that is, general-public-license. Other propriety databases such as Oracle and SQL servers offer two license modes: Licenses Included and the BYOL (Bring Your Own Licenses) model. With licenses included, AWS provides the required license keys for your databases, so you don't have to separately purchase one. Alternatively, you can even use the BYOL model to provide your own licenses or obtain new ones from the database provider itself.
• DB Engine Version: Select the appropriate DB Engine Version as per your requirements. RDS provides and supports a variety of database engine versions that you can choose from. In this case, I have selected the MySQL database engine version 5.6.23 as shown:
  
• DB Instance Class: From this dropdown list, select the appropriate class of DB instance you wish to provide for your DB instance. For a complete list of supported instance class types, refer to http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html.
• Multi-AZ Deployment: Select Yes from the dropdown list to ensure a multi-AZ deployment for your database. Selecting No will create your DB instance only in a single availability zone.
• Storage type: Select an appropriate storage option from the dropdown list. In this case, I have opted for General Purpose (SSD); however, you can also select between Magnetic and Provisioned IOPS as well.
• Allocate storage: Allocate some storage for your database instance. You can provide anywhere between 5 GB to 6 TB.

With these basic configurations out of the way, configure your database's settings as shown in the following screenshot:

Here are the parameters you need to provide in Settings panel:

• DB Instance Identifier: Provide a suitable name for your DB instance. This name will be a unique representation of your DB instance in the region it is getting deployed in. In my case, I have provided the name US-WEST-PROD-DB.
• Master Username: Provide a suitable username for your MySQL database. You will use this username to log in to your DB instance once it is deployed.
• Master Password: Provide a strong password for your DB instance. You will use this password to log in to your DB instance once it is deployed. You can provide a password that's up to 41 characters long; however, do not provide the following characters in it: (@, " , /).

With the settings configured, click on Next Step to proceed with your database's configuration.

Step 4: Configure Advanced Settings

The final step of configuring your database instance can be split up into three parts. The first part involves the setting up of the DB instance's Network & Security, that includes selecting the VPC along with the Subnet Group that we created a while back. The second part involves configuring various database options such as the database name, the database port number on which the application can connect to it, and so on. The final part consists of the database's Backup and Maintenance window details. Let's have a quick look at each part a bit more in detail:

• VPC: Select the name of the VPC that will host your MySQL DB instance. You can optionally select the option Not in VPC as well if you wish to deploy your DB instance in a standard EC2 Classic environment.
• Subnet Group: Select the newly created Subnet Group from the dropdown list, as shown in the following screenshot:
  
• Publicly Accessible: You can optionally set your DB instance to have public connectivity by selecting Yes from the Publicly Accessible dropdown list; however, as best practice, avoid making your DB instances public at all times.
• Security Group(s): There are two levels of security group that you can use here. The first is a DB security group that is basically used to control access to your DB instances that are outside a VPC. When working with DB security groups, you only need to specify the subnet CIDR associated with your DB instance, and no DB port or protocol details are required. The second is your traditional VPC security group that can be used to control access to your DB instances that are present in a VPC. Here, however, you need to specify both inbound and outbound firewall rules, each with associated port numbers and supported protocols.

You can select one or more security groups here for your DB instance; in my case, I have selected a VPC security group as shown in the previous screenshot. Just remember to open up only the required ports whenever you work with VPC security groups. In this case, I have opened up ports 3306 (MySQL) and 1433 (SQL Server).

Moving on to the second part of the Advanced Settings, we will now set up the Database Options as shown in the following:

• Database Name: Provide a suitable database name here. RDS will not create and initialize any database unless you specify a name here.
• Database Port: Provide the port number using which you wish to access your database. MySQL's default port number is 3306:
  

  Note

  You will not be able to change the database port number once the DB instance is created.

• DB Parameter Group: DB parameter groups are logical groupings of database engine configurations that you can apply to one or more DB instances at the same time. RDS creates a default DB parameter group that contains mostly AWS specific configuration settings and default values. You cannot edit the default DB parameter group, so in order to make changes, you will have to create a DB parameter group of your own. In this case, I have left it as the default value.
• Option Group: This option is similar to DB parameter groups in that they too provide and support few additional configuration parameters that make it easy to manage databases; for example, MySQL DB Instances support for Memcached and so on. RDS currently supports option groups for Oracle, MySQL, and SQL Server database engines. To know more about option groups, refer to http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithOptionGroups.html.
• Enable Encryption: RDS provides standard AES-256 encryption algorithms for encrypting data at rest. This includes your DB instance, its associated Read Replicas, DB Snapshots, as well as the automated backups. An important point to note here is that encryption is not supported on the t2.micro DB instances.

For encryption to work, you will need your DB instance to be one of the following instance classes:

Instance Type	Supported Instance Class
General purpose (M3) current generation	db.m3.medium db.m3.large db.m3.xlarge db.m3.2xlarge
Memory optimized (R3) current generation	db.r3.large db.r3.xlarge db.r3.2xlarge db.r3.4xlarge db.r3.8xlarge
Burst capable (T2) current generation	db.t2.large

In this case, we are not going to encrypt our DB instance, so select No from the Enable Encryption field as shown in the previous screenshot.

The final part of the Advance Settings page is the Backup and Maintenance window selection. Using this section, you can configure automated backups for your database as well as provide designated maintenance windows for the same. You can set the Backup Retention Period as well as the Backup window's Start Time and Duration, as shown in the following screenshot. In my case, I have opted for the backups to be taken at 12:00AM UTC. If you do not supply a backup window time, then RDS will automatically assign a 30-minute backup window based on your region. For example, the default backup time block for the US West (Oregon) region is 06:00 to 14:00 UTC. RDS will select a 30-minute backup window from this block on a random basis:

The same can be set for your Maintenance window as well. An additional feature provided here is that you can choose whether or not the database should receive automated minor version updates from AWS or not. These minor updates for the database engine will be automatically installed on the database based on their availability as well as the maintenance window's time frame. You can make changes in these settings even after your DB instance is created; however, remember that the backup window should not overlap the weekly maintenance window for your DB instance. Once you have configured the settings, click on Launch DB Instance to complete the launch process.

The DB instance will take a good 2 to 3 minutes to spin up depending on whether you have opted for the Multi-AZ deployment or not. You can check the status of your newly created DB instance using the RDS management dashboard, as shown in the following screenshot. Simply check the Status column for all the stat us changes that occur while your DB instance is created:

Let's take a quick look at some of the states that a DB instance goes through during its lifecycle:

• Creating: This is the first stage of any DB instance's lifecycle where the instance is actually created by RDS. During this time, your database will remain inaccessible.
• Modifying: This state occurs whenever the DB instance enters any modifications either set by you or by RDS itself.
• Backing-up: RDS will automatically take a backup of your DB instance when it is first created. You can view all your DB instance snapshots using the Snapshots option on the navigation pane.
• Available: This status indicates that your DB instance is available and ready for use. You can now access your database remotely by copying the database's endpoint.

Note

To read the complete list of DB instance status messages, refer to http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Status.html.

Once your DB Instance is in the Available state, you can now access your database remotely from any other EC2 instance or even remotely from your desktop if you have set the security groups right. In my case, I have launched a new EC2 instance in my VPC, as shown in the following screenshot. This instance is a part of the Web ServerSubnet (US-WEST-PROD-WEB-1) we used in the previous chapter:

The first thing to do is make sure you have the required MySQL client packages installed on your web server EC2 instance. To do so, simply type in the following commands as shown:

# sudo yum install mysql  

With the client installed, you can now access your remote RDS database using the following command:

# mysql -u <USERNAME> -h <DATABSE_ENDPOINT> -p

Substitute the values with your master username and password that you set for the database during the Create DB Instance phase. Here, <DATABSE_ENDPOINT> is the Endpoint (<DB_IDENTIFIER>.xxxxxxxxxxxx.us-west-2.rds.amazonaws.com:3306) that is provided by each DB instance when it is created. If all goes well, you should see the MYSQL command prompt. Go ahead and run a few MYSQL commands and check whether your database was created or not:

> show databases;

You can additionally connect your database with tools such as the MySQL workbench as well. Just remember to provide your database's endpoint in the hostname field followed by the master username and password. With the database connected successfully, you can now run a few simple tests just to make sure that the DB instance is accessible and working as expected.

In this section, I'm going to show you a simple exercise, using which you can test the configurations and the working of your database, as well as your DB instance. First up, log in to your database using the following command as done earlier:

# mysql -u <USERNAME> -h <DATABSE_ENDPOINT> -p

Next, let's go ahead and create a simple dummy table called doge. Type the following command in your MySQL prompt:

CREATE TABLE doge
(
idint(11) NOT NULL auto_increment,
namevarchar(255),
description text,
sizeenum('small','medium','large'),
date timestamp(6),
  PRIMARY KEY (id)
);

Fill in some data in your newly created table using the following INSERT commands:

INSERT INTO doge (name,description ,size,date) VALUES('Xena','Black Labrador Retreiver','medium',NOW());
INSERT INTO doge (name,description ,size,date) VALUES('Betsy','Browndachshund','medium',NOW());
INSERT INTO doge (name,description ,size,date) VALUES('Shark','Mix bread- Half dachshund','small',NOW());

With your basic table and data created, you can now access the same using your Web Server Instances. In my case, I'm using a simple PHP script (index.php) that is installed on the web server instance itself to print the database name as well as the table's data. Remember that as per our use case scenario, the web server instances are isolated from the database instances by different subnets as well as security groups and network ACLs, so make sure your subnets can communicate with each other correctly before testing. If all goes well, you should see your database, as well as the newly created table and its data, as shown in the following screenshot:

Once your DB Instances are created and launched, you can further modify them using two methods. The first method is by using the AWS CLI, where you can use the modify-db-instance command along with a bunch of options to specify and assign new parameters and values to your DB instances. For example, we need to expand the storage as well as the instance class of our DB instance so that it can accommodate the growing database's needs. To do so, type in the following command:

# aws  modify-db-instance --db-instance-identifier us-west-prod-db 
--allocate-storage 100 
--db-instance-class db.m1.large

The preceding command will update the DB instance with the identifier us-west-prod-db with 100 GB of disk space and change its instance class to db.m1.large as well. The CLI provides a host of additional parameters as well which you can use to configure almost any aspect of your DB Instance, such as the master user's password, the preferred backup and maintenance window, the database engine versions, and so on. You can find the complete list of parameters and their descriptions at http://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html.

The second method of modifying the DB instances is by using the RDS Management dashboard itself. Select your DB instance, and from the Instance Actions dropdown list, select the Modify option, as shown in the following screenshot:

Using the Modify page, you can change almost all configuration parameters of your DB instance just as you would by using the CLI. You can optionally set the changes to take effect immediately as well by selecting the Apply Immediately checkbox. Note, however, that by doing so, your DB instance will try to accept the made changes instantly, which can cause outages and even performance degradation at certain times. So as good practice, avoid setting this checkbox unless absolutely necessary. Changes made otherwise are reflected in your DB instance during its next scheduled maintenance window.

RDS provides two mechanisms using which you can perform backups of your database instances as per your requirements. The first is an automated backup job that can be scheduled to run at a particular backup job interval, preferably when the database is at its least utilization point. This is something that we configured sometime back while creating our DB Instance. The second is a manual database instance snapshot that you can perform at any point in time. Here's a look at both the techniques in a bit more detail:

This will bring up the Take Snapshot page where all you need to do is provide a suitable name for your snapshot and click on Take Snapshot to complete the process.

Alternatively, you can also use the AWS CLI for performing a manual DB instance snapshot. Type in the following command:

# aws rds-create-db-snapshot -i<DB_IDENTIFIER> -s <SNAPSHOT_NAME>

Once you have taken your DB instance snapshot, you can view them on the RDS Management dashboard under the Snapshots page, as shown in the following screenshot:

The snapshot dashboard allows you to perform various operations on your DB snapshots including copying DB snapshots from one region to another for high availability, restoring the state of a DB instance based on a particular snapshot, as well as options to migrate your MySQL database completely over to the Amazon Aurora database engine!

We have already discussed the concept of read replicas in some depth, and how they can be useful for offloading the read operations from your primary DB instance as well as providing a mechanism using which you can create and set up Read Replicas across AWS regions. In this section, we are going to check out a few simple steps using which you can create and set up read replicas for your own environment using the RDS Management dashboard.

To get started, first select your newly created database from the RDS dashboard, as shown in the following screenshot. Next, using the Instance Actions tab, select the Create Read Replica option:

This will bring up the Create Read Replica DB Instance page, as shown in the following screenshot. The page is pretty self-explanatory and easy to configure. Start off by selecting an appropriate DB Instance Class from the dropdown list. You can alternatively select a high-end DB instance class here as compared to the primary DB instance. Next, select a Storage Type for your Read Replica DB instance. In this case, I have opted to go for the General Purpose (SSD) volumes:

Next, select your primary DB instance as the source for your Read Replica using the Read Replica Source dropdown list, and provide a suitable and unique name for your Read Replica in the DB Instance Identifier field, as shown in the preceding screenshot.

Now comes the fun part where you actually get to specify where you wish to deploy your Read Replica DB instance. Remember that you can have a maximum of five read replicas for a single primary DB instance, so ideally have your replicas spread out across the AZs that are present in your operating region or even have them residing in a different region altogether. Select an appropriate Destination Region and its corresponding Availability Zone. In this case, I have opted for the same region (US West (Oregon)) as well as same AZ (us-west-2a) as my primary DB instance.

Besides the placement of your replica instance, you will also need to make it a part of your existing DB Subnet Group. Select the same subnet group as provided for your primary DB instance from the Destination DB Subnet Group field, as shown in the following screenshot. Leave the rest of the fields to their default values and click on the Create Read Replica option:

Here's what will happen next. First up, RDS will start off by taking a snapshot of your primary DB instance. During this process, the DB instance will face a brief moment of IO freeze which is an expected behavior. Here's a handy tip that you can use to avoid the IO freeze! Deploy your DB instances using the multi-AZ deployment. Why? Well, because when it comes to taking the snapshot, RDS will perform the snapshot on the primary DB instance's standby copy, thereby not affecting any performance on your primary DB instance. Once the snapshot is taken, RDS will start to spin up a new Read Replica based on your specified configurations, as shown in the following screenshot.

During the replica's creation phase, your primary DB instance will change from a backing up state to modifying, and ultimately back to available status once the Replica is launched. Each Replica will behave as a DB instance on its own; hence, each of them will be provided with a unique DB endpoint as well. Refer to the following screenshot as an example of multiple Replicas:

In case you create multiple Replicas at the same time using the same primary DB instance, then RDS will only perform the snapshot activity once, and that too at the start of the first replica's creation process. You can even perform the same process using the AWS CLI's rds-create-db-instance-read-replica command, as shown in the following:

# rds-create-db-instance-read-replica <REPLICA_NAME> -s <DATABASE_IDENTIFIER>

In this case, RDS will create a new Replica DB instance based on your supplied database identifier value while keeping all the configurations same as that of the primary DB instance. To know more about the various options and related operations that you can perform using this command, refer to http://docs.aws.amazon.com/AmazonRDS/latest/CommandLineReference//CLIReference-cmd-CreateDBInstanceReadReplica.html.

Once your Read Replica instance is created and functioning, you can promote it as a primary DB instance as well. This feature comes in real handy when you have to perform a DB failure recovery, where your primary DB instance fails and you need to direct all traffic to the newly promoted Read Replica, and so on. To promote any Read Replica instance, all you need to do is select it from the RDS Management dashboard and select the Promote Read Replica option from the Instance Action drop-down list. This will bring up the Promote Read Replica page, as shown in the following screenshot:

Enable the automatic backups as well as fill out the Backup Retention Period and Backup Window details as per your requirements. Click on Continue to proceed to the next page. Acknowledge the Replica instance's promotion and click on Yes, Promote to complete the process.

During this process, your Read Replica instance will reboot itself once, post which it will become available as a standalone DB instance. You can then perform all sorts of activities on this DB instance, such as taking manual snapshots and creating new Read Replica instances from it as well.

You can promote a Read Replica using the AWS CLI as well. Type in the following command while replacing the <REPLICA_NAME> value with your own Replica instance's name:

# rds-promote-read-replica <REPLICA_NAME> 
--backup-retention-period 7 
--preferred-backup-window 00:00-00:30

The preceding command will promote the <REPLICA_NAME> to a standalone primary DB instance. It will also set the automated backup retention period to 7 and configure the backup window for half an hour between 00:00 UTC and 00:30 UTC.

AWS provides a variety of tools and services to track and monitor the performance of your DB instances—the most popular and commonly used being Amazon CloudWatch itself. Besides this, RDS, too, comes with a list of simple tools that you can use to keep an eye on your DB instances. For example, you can list and view the DB instance's alarms and events by simply selecting the DB instance from the RDS Management dashboard, as shown in the following screenshot:

You can additionally view the DB instance's security group and snapshot events using this page as well. RDS will store the events for a period of 14 days, after which they are deleted. The DB instance quick view page also displays the DB instance's memory as well as storage utilization in near real time. Each of these fields has a custom threshold that RDS sets. If the threshold value is crossed, RDS will automatically trigger notifications and alarms to inform you about the same. You can also view the database's Read/Write IOPS value using this page.

RDS also provides a page using which you can view the DB Instance's real time performance graphs. To do so, simply select Launch DB Instance and the Show Monitoring option, as shown in the following screenshot:

Each graph can be further expanded by selecting it. You can optionally view graphs for the past hour or a later duration by selecting the appropriate time from the Time Range dropdown list.

Furthermore, RDS also allows you to view your database's essential logs using the RDS Management dashboard. Select your DB instance, and from the dashboard, select the Logs option. This will bring up the Logs page, as shown in the following screenshot:

You can use this page to view as well as download the appropriate logs as per your requirements. RDS obtains logs from the database at short, regular intervals (mostly 5 minutes) and stores them in files that rotate as well. Selecting the Watch option adjoining a log file will display the log file in real time within your browser. You can view up to 1,000 lines of your logs at a time using this feature.

Once you have completed work with your DB instances, it is equally important to clean up your environment as well. You can delete a DB instance at any time you want using both the RDS Management dashboard and the AWS CLI.

To delete a DB instance using the RDS Management dashboard, select the Delete option from the Instance Actions dropdown list. You will be prompted to Create a final Snapshot? for your DB instance before you proceed, as shown in the following screenshot:

It is strongly recommended that you create a snapshot of your DB instance before you go ahead and delete it. Once you select the Delete option, RDS will delete the DB instance along with all the automated backups that were taken earlier. The manual snapshots, however, are not deleted and thus can be used to restore your DB instance to its original state if you want to revert to your original settings.

To delete a DB instance using the AWS CLI, simply type in the following command and replace <DATABASE_IDENTIFIER> with the name of your DB instance:

# aws rds-delete-db-instance <DATABASE_IDENTIFIER> 
--final-db-snapshot-identifier MyFinalDBSnapshot

The command will delete your DB Instance but will additionally first create a snapshot for it by the name of MyFinalDBSnapshot.