If you would like to read the other parts in this article series please go to:
- Doing your Database on AWS (Part 1)
- Doing your Database on AWS (Part 3)
- Doing your Database on AWS (Part 4)
Introduction
In Part 1 of this series, we discussed the evolution of the digital database from the rudimentary programs of the 1960s to today’s sophisticated twenty-first century applications, and delved into the benefits – and a few drawbacks – of the relatively new phenomenon of the cloud-based database or DBaaS (Database as a Service). Then we got into some specifics about the different options that Amazon Web Services offers for putting your database into the cloud, with a brief overview of Amazon Relational Database Service (RDS), which is the choice for traditional structured databases built on the Structured Query Language (SQL).
Moving a database into a VPC
Before we can start talking about working with a database in a VPC, you have to get your database into a VPC. Sometimes you may need to move a database instance into a VPC. That might or might not involve creating a VPC.
If you’re using the newer EC2-VPC platform, a default VPC is already created for you, and by default whenever you create a new database instance, it is put into that default VPC. However, if you’re using the older EC2-Classic platform, there is no default VPC so you have to create one, as we discussed in Part 1. You can also create more VPCs in addition to the default one.
If you have a database that is not in a VPC and need to move it into a VPC, it’s not a quick one-step operation. Once you’ve created the VPC, you then have to add subnets, create a DB subnet group, create a VPC security group, create a snapshot of the current database instance that you’ll be moving to the VPC and finally restore the database snapshot to the VPC, subnet group and VPC security group that you want to use.
It’s a multi-step process, but Amazon makes it fairly straightforward as long as you follow their instructions, and they do have very detailed instructions for each of these procedures. A few things to be aware of include the following:
Adding subnets to the VPC
Your VPC can span multiple Availability Zones but your subnets cannot. You can add subnets to each Availability Zone. You can have up to five VPCs per region and up to two hundred subnets per VPC (you can request to have Amazon increase your limit if you should need more). AWS will assign a unique identifier to each of your subnets.
Creating the DB subnet group
Your next step is to create a DB subnet group and then add the subnets in your VPC to it. This is done from the Amazon RDS console and it’s a pretty simple procedure. You just click the Subnet Groups link, click Create DB Subnet Group, enter a name and a description for your group, then select your VPC from the drop-down list and click Add all subnets. Then click the Yes, Create button and click Close.
Now you have a new DB subnet group and it will show up in the list in the RDS console.
Creating the VPC security group
Your next step is to create a VPC security group, which must be done before you can create the database instance. You can create as many as 100 security groups in a VPC, and each security group can have up to 50 rules. You can make separate rules for inbound and outbound traffic. By default all outbound traffic is allowed and no inbound traffic is allowed.
Note that security groups only allow you to filter on the destination ports, not on the source ports. Also be aware that you can’t use security groups that were created in EC2-Classic with the instances that are in your VPC.
Creating a security group is as easy as opening the VPC console, clicking Security Groups and clicking the Create Security Group button. Give it a name and description, select the ID from the menu and click Yes, Create. The newly created security group will have one outbound traffic rule that allows all outbound traffic from the instance, so in order to restrict this, or to allow inbound traffic, you will need to create your own rules.
To add rules, you do this on the Inbound Rules tab in the Security Groups section of the VPC console. Select the rule type (inbound or outbound) select the protocol, specify the source and save.
Creating the DB instance in the VPC
Now it’s time to create a DB snapshot. You have to take the database that you want to move offline to do this. The snapshot creates a backup of the database instance that you can then restore to the VPC where you want it to reside. You create a snapshot from the RDS console.
The process takes a few clicks but is relatively painless. Click DB Instances, then Instance Actions, and then Take DB Snapshot. In the dialog box that is displayed, enter a name for the snapshot and click the Yes, Take Snapshot button. You can also create a snapshot from the command line if you prefer, using the following command:
PROMPT>rds-create-db-snapshot –I mydsinstance –s mydbsnapshot
Finally, you restore the snapshot to the VPC. When you restore a snapshot, it creates a new DB instance in the VPC. In the RDS console, click Snapshots and then select the DB snapshot that you want to move to the VPC. Click Restore Snapshot. You will need to specify the VPC, DB subnet group and VPC security group that you want to use.
Creating a new DB instance in a PC
To create a new database instance in your VPC, you follow the same steps of creating a VPC, adding subnets, creating a DB subnet group and creating a VPC security group. If you have a default VPC, the subnet group is already created. If you want the database instance to be accessed publicly, you will need to update DNS support for the VPC to enable DNS hostnames and DNS resolution.
When DNS hostnames are enabled for a VPC, Amazon will assign public and private DNS hostnames to the database instance. In the VPC console, select your VPC from the Your VPCs list and if DNS resolution and DNS hostnames are not enabled (if the summary says “no”), click Actions, then Edit DNS Resolution or Edit DNS Hostnames. Select Yes in the dialog box and then save. You can also use the modify-vpc-attributes command in the AWS command line interface. Read more about using DNS with a VPC, with links to instructions for using the command line interfaces here.
If you should want to hide your database instance from the Internet so that it cannot be publicly accessed, but you have other applications that need to be accessed across the Internet, you can create a VPC that has both a public subnet and a private subnet. If your VPC has a public IP address, you can use the PubliclyAccessible parameter when you launch a database instance inside a VPC to control whether or not the DB instance name resolves to the public IP address.
In the Configure Advanced Settings dialog box in the Launch DB Instance Wizard, select No in the drop-down box for the Publicly Accessible field.
In addition, the security group that is used by the database instance controls whether or not public access is allowed.
Working with the DB instance
Now that you have either moved a database instance into your VPC or created a new database instance in the VPC, you can work with it. Note that your VPC will need to have a security group that allows access to the database instance, since the default security group, as described above, allows only outbound access. Also be aware that the CIDR blocks in your subnets will need to be of sufficient size to accommodate extra IP addresses for RDS to use when it is conducting maintenance tasks.
Summary
In Part 2 of this multi-part series on Amazon Web Services’ options for moving your databases into the cloud, we continued the discussion that we began in Part 1 concerning the Amazon Relationship Database Service (RDS) and in particular, how to move a database instance to a VPC or create a new database instance in a VPC, as well as how to work with your database instance in the VPC.
In Part 3, we will move on to discuss Amazon’s DynamoDB services, which would be your database option of choice for less structured and less predictable data that doesn’t lend itself to the traditional SQL-based tabular model.
If you would like to read the other parts in this article series please go to:
