Converting Your AWS EC2 & RDS Instances To Amazon VPC

Amazon VPC has come along way since it was first introduced. For those who are not familiar the Amazon VPC (Virtual Private Cloud), it allows us to provision our own section of the cloud. Here we can manage our own routing tables, subnets, internal static IP addresses as well as create VPN (Virtual Private Network) connections to our VPC. Now that Amazon VPC has evolved, it’s good practice to always put our instances inside of a VPC. This can present somewhat of a problem if you already have EC2 (Elastic Compute Cloud) and RDS (Relational Database Service) instances running outside of a VPC. Running our database instance inside of a VPC allows our instance to run on a private network and not open to the internet. Outside of a VPC, your database server is open to the general internet/public, which is a huge security issue.

If you’re looking for a “nitty gritty” detail course on Amazon Web Services and Amazon VPC you can view our AWS Certified Solutions Architect – Associate Level course module over at The Linux Academy. Now, we can get started.

Goals

We’ll already assume that you have a VPC created and we need to do the following:

  • move your already existing EC2 instances into the VPC
  • reconfigure IP address or the Elastic Load Balancer
  • create an RDS instance inside the VPC

Seems simple, but if you miss a step, your EC2 instances won’t communicate with your RDS instance.

Create AMI’s For The EC2 Instances

The first step is to create AMI’s (Amazon Machine Images) for your current running EC2 instances or the instances you wish to launch into the VPC. From the AMI’s, we will launch new instances and specify the location we want to launch them in (i.e. EC2 or into a designated VPC).

Console

  1. Select the instance you wish to create an AMI from
  2. Right hand click -> Select Create AMI
  3. Repeat for all instances you wish to launch into your VPC

Automating Creation of All Running Instancse With Command Line Tools 

  1. Make sure you have command line tools installed

ec2-create-image i-instance-id –name “To VPC” –description “Server to VPC” –no-reboot -b [-b, –blockdevicemapping mapping ]

Launch New Instances From The AMI

Now that we have created our AMI’s, we’ll need to launch new instances from the AMI. We’ll do this the same way you normally would, except for in the options, we’ll select the VPC we’d like to launch the instance into.

  1. Click on AMI’s on the left hand side in the console
  2. Right hand click on the AMI you wish to launch
  3. Select VPC and the subnet to launch the EC2 instance into.
  4. Repeat for all instances.

Screen Shot 2013-09-23 at 11.09.17 AM

Converting RDS Instance Into VPC

Converting our RDS instances is a little more complicated. When converting EC2 instances, we can create an image and launch that image into the VPC. However, with RDS, when you take a snapshot of your database, you cannot launch it into a VPC. RDS also requires that you have two private subnets that create what’s called an “RDS Subnet Group”. In order to create an RDS instance inside of a VPC, we need to have the subnet group. At a bare minimum, we will three create subnets as part of our VPC. One public subnet for our web facing instances and at least two private subnets so we can make our RDS Subnet Group. We can launch other instances into those private subnets if needed as well.

Create Two Private Subnets

  1. Open your VPC console
  2. Select subnets -> create subnet
  3. Create two private subnets in separate availability zones

Create RDS subnet group

  1. Open your RDS console
  2. Select Subnet Groups -> Create DB Subnet Group
  3. Name your subnet group -> select the VPC -> add both subnets to your subnet group. Again the subnets will need to be from separate availability zones.

Create An RDS VPC Instance

  1. Instances -> Launch RDS Instance
  2. Under DB Instance Details -> Navigate through regular settings configuration until you arrive at “Additional Config”
  3. Select the VPC you’d like to launch your instance into.

Screen Shot 2013-09-23 at 11.19.10 AM

Dump Old MySQL Database
In order to get your current data from your database you’ll need to dump the contents of your database into a file. If you’re using MySQL, you’ll use the program “mysqldump”. As a note make sure you do this from a database that is not running in the VPC and can still communicate with your original db instance.

mysqldump -u user -p -h hostname database_name > database_dump.db

Upload the database dump to one of your instances running in your public VPC that we created above. From there, we’ll use the mysql command line to dump the data into your new VPC RDS Database.¬†Since only instances inside the VPC can communicate with other instances inside the VPC you’ll only be able to import the data from to the new RDS intances from an ec2 instance that is running inside of your VPC.

mysql -u user -p -h new_vpc_rds_hostname database_name < database_dump.db

Make sure to update all your code and references to the old RDS hostname to the new VPC RDS hostname.

Security Groups

Even inside of the VPC, in order for your instances to communicate with each other, they need to be configured to do so. You can place your RDS instances behind the same VPC Security group as your EC2 instances. By doing this, you will not need to make any security group configuration changes. If you chose to place your RDS instance in a separate security group, you’ll need to add a rule to the RDS security group allowing your EC2 Security groups access through the MySQL port (port 3306) or DMZ access to the security group. You do this by navigating under the RDS security group settings and then by selecting the drop down under “connection type” and selecting “EC2 security group”.

Screen Shot 2013-09-23 at 11.28.03 AM

Conclusion

Running your AWS infrastructure inside of a VPC creates many benefits for your app. Going forward, Amazon says that it is best practice to always use a VPC for any application you are going to run. When running inside of a VPC, it’s important to take note of which subnets are private and public, and remember that security groups apply the same way they do in regular EC2 instances.