1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Solution Architect Professional for AWS - Domain Seven: Scalability and Elasticity

Setting up RDS

Start course

Welcome to domain Seven - Scalability and Elasticity - in the Solution Architect Professional for AWS learning path. In this group of lectures, we will walk through building a flexible, available and highly resilient application in the Amazon web services environment.


Welcome back, in this lesson we are setting up our RDS instance. RDS is AWS' Relational Databases Service. It comes in many flavors, each with its own set of advantages and disadvantages. For our application we will using MySQL as the database engine. RDS makes eliminating a single point of failure extremely simple. If you recall from our last lesson, we set up three subnets, one in each Availability Zone dedicated to the database tier. Each database instance has specific needs and requires a number of IP addresses to be available to it for its managed services such as Backups and Maintenance. By giving an instance its own subnet, it will not need to compete for IP addresses with other services. Even though we've created our subnets with the purpose of housing our database instances, we have to explicitly tell RDS which subnets to use. This is where Subnet Groups come in. A Subnet Group is simply a collection of subnets where RDS can fire up its instances. To create a Subnet Group, we go to RDS Dashboard via the link in the AWS Console. Once there we click on the Subnet Group's link. Next click on the Create DB Subnet Group button. We start by adding a Name for our Subnet Group along with a Description. We select our one and only VPC, and Availability Zone's drop-down is filled in. So let's select an Availability Zone. In the Subnet drop-down we can only see Subnet IDs, but that's okay. Repeat this for the remaining Availability Zones. When finished, click the Create button. This will take us back to the Subnet Group listings where we can see the Subnet Group we just created. Now it's time to create our database instance. From the RDS Dashboard, click through to the database instance and then click on the Launch button. This will walk us through the creation process. Our application will be using the MySQL engine since we plan to use a Multi-AZ Deployment. We ensure that, and this option is selected before we continue. Next we are presented with the Database Details. The default License Model and Engine Version are acceptable for our application. We are going to change the Instance Class to t1.micro. Set Provisioned IOPS to No, and the Allocated Storage down to five gigabytes. These selections are not advised for a true production environment as it will result in very poor performance, something that we're just not concerned with in this series. Lastly, we create a Database Identifier and the credentials before hitting Next. This will bring us to the Advanced Settings step. The first configuration option we see is for the VPC, which has already defaulted to our one and only VPC. For the Database Subnet Group, we select the group we previously created. We don't want our instance to be Publicly Accessible, meaning we need to ensure the Publicly Accessible option is set to No. Up next we select a VPC Security Group. We already have a Security Group we created prior to these series that we're doing, so we're gonna use that. Now we Name the Database. This is very important because this is what our application will be using when it connects to the database. The default Port is 3306, which is what we want for our MySQL instance. We don't need to change the Parameter or Options Group at this time. Parameter and Options Groups are useful when you need to configure a database setting that is not available from the AWS Console. You can find out more information about Parameter and Option Groups in the RDS documentation on AWS. The Backup section allows us to set a Retention Period and Backup Window. Retention Period will be based off of your requirements, and Backup Window is useful if you want to limit backups to a time when user activity is low. For our application the default settings are acceptable. The Maintenance section gives you the option of having Minor Versions automatically applied to your instances. If you want upgrades to automatically happen, you can also set a Maintenance Window. Again the default options are suitable for us. Finally, we Launch the app Database Instance, which begins the creation process and puts us back on the Database Instance list. Creating a Multi-Availability Zone database will take a few minutes, so let's fast forward to what it looks like when it finally completes, here we are. Let's select our Instance and check out the details. To connect to our Instance from our application, we need to take note of the Endpoint alias. This alias in conjunction with the Database Name and credentials is what will be used to make a connection. It always points to the primary instance. If the primary becomes unavailable, a standby instance is promoted as primary and the alias is redirected to it. The unreachable instance will become a standby once it is available again. The switchover may cause a brief service interruption between the time the primary is determined to be unhealthy and a standby is promoted. However, this is just a small inconvenience that can be masked with other techniques, and is outweighed by the fact that RDS handles this for us without any intervention. At any point we can see which Availability Zones host the primary instance from this screen. Our primary instance is currently running in us-east-1a. In a later session we will use this screen to demonstrate a successful failover to a new Availability Zone. With our RDS Instance operational, we can move on to setting up our Autoscaling Policies.

About the Author
Andrew Larkin
Head of Content
Learning Paths

Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built  70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+  years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.