Step-by-Step Guide to move Amazon RDS Database Instance from Public Subnet to Private Subnet

Introduction to Amazon RDS

Amazon RDS is a relational database web service provided by Amazon. It makes it easy to set up and use a cloud-related website. Provides an inexpensive way to use industry-leading RDBMS software as a managed service. Amazon Web Service (AWS) has this fantastic service that, you do not need to purchase any server or install any website software for it.

You have just signed up for the AWS RDS web service and started using the RDBMS features after some initial configurations that include memory and CPU capacity sharing etc. Amazon RDS is an Online Transaction Processing (OLTP) type of database. The Main use case is a transactional database (rather than an analytical database). Amazon RDS supports these database engines:

Amazon Aurora
MySQL
MariaDB
Oracle
SQL Server
PostgreSQL

RDS is a fully managed service, and you cannot do SSH to RDS Instance.

Customized Cloud Solutions to Drive your Business Success

Cloud Migration
Devops
AIML & IoT

Know More

Brief about Amazon VPC

Amazon Virtual Private Cloud (Amazon VPC) provides a reasonably separated space for AWS cloud where you can deploy AWS resources to the virtual network you define.

You have complete control over your virtual network location, including the choice of your IP address range, subnet configuration, and configuration of routing tables and network gates.

You can easily customize the network configuration of your Amazon Virtual Private Cloud. For example, you can create a public subnet for web servers that can access the Internet and can also set up your backend system such as Databases or application servers on a private subnet.

You can provide multiple layers of security, including security groups and a network access control list, to help control access to Amazon EC2 conditions on each subnet.

Scenario Overview

Consider a scenario where there is Amazon Relational Database Service (Amazon RDS) DB instance in the public subnet. I require to change the subnet of my DB instance from a public to a private subnet within the same VPC and make my DB instance completely private. What is the simplest and quickest method to achieve this?

Amazon RDS does not provide an option to change the subnet group of your DB instance, with the same VPC. However, you can use the workaround method. In this blog, you will learn to move your DB instance from a public subnet to a private subnet and make your DB instance private.

The advantages of using this method include:

Avoids the need to create a new DB instance
Avoids using the snapshot-restore process
Minimizes the downtime involved in creating a new instance and diverting traffic. The only downtime you see is the failover time.

Step-by-Step Guide to move RDS from the Public Subnet to the Private Subnet

I have my RDS Database running in the public subnet, and I need to move it to the private subnet.

Step 1: Disable Multi-AZ deployments and public accessibility on your DB Instance

Note: If your DB instance is already in Single-AZ with the Public accessibility parameter, set to No, you can skip this step and proceed to the next step to discover your IP address.

To modify your DB instance first disable a multi-AZ option by modifying RDS, follow these steps:

Go to the AWS RDS console.
From the navigation pane, choose Databases and then choose the DB instance which needs to be modified.
Click on Modify.
From the Modify DB Instance page, for multi-AZ deployment and public accessibility, select No.
Choose Continue and review the changes.
Choose Apply immediately to apply your changes.

Step1

Step 2: Discover the IP address of your DB instance

After your DB instance has returned to the running/Available state, run dig on the DB instance’s endpoint to find its underlying IP address:

dig <rds-endpoint>

1	dig <rds-endpoint>

Output:

db-RDS-instance.xxxxxxxx.us-east-1.rds.amazonaws.com. 5 IN A 10.0.2.133

1	db-RDS-instance.xxxxxxxx.us-east-1.rds.amazonaws.com. 5 IN A 10.0.2.133

With the Above private IP, you can find which subnet this RDS DB Instance is using. This is the subnet that your primary instance uses.

In this practical, we have used two public subnets.

Public Subnet 1: 10.0.1.0/24

Public Subnet2: 10.0.2.0/24

Because the IP is falling under 10.0.2.0/24, you can conclude that the instance is placed in Public Subnet2.

Step 3: Remove Public Subnets and add Private Subnets to your DB instance

Add all required private subnets in your subnet group. Also, delete all public subnets from the subnet group except for the one which is in use. In this example, you delete everything except Public Subnet2 because it is being used by your RDS DB instance.

Step3a

Step3b

Note: Private subnet is a subnet that is associated with a route table that has no route to an Internet gateway.

Go to RDS Console
From the navigation pane, choose Subnet groups and the subnet group associated with your DB instance.
Choose Edit.
From the Add subnets section, choose the availability zone and private subnets you want to add.
Select the public subnets you want to delete, and then choose Remove.
Choose Save.

Step 4: Enable the Multi-AZ deployment option of your DB Instance

From the navigation pane, choose Databases and then choose the DB instance you want to modify.
Choose Modify.
From the Modify DB Instance page, for multi-AZ deployment choose yes.
Choose Continue and review the summary of modifications.
Choose Apply immediately to apply your changes.

Step 5: Reboot your DB instance with failover and after that disable the multi-AZ option

When your DB instance failover, the secondary, which is using the private IP, becomes the primary DB Instance and the public subnet becomes the secondary DB Instance.

After you have rebooted your DB instance with failover, you need to remove the secondary which is now in the public subnet. To do this, modify your DB instance again to disable the multi-AZ option. You can do this by modifying and setting multi-AZ deployment to No.

Step5

Step5b

Step 6: Remove the public subnet in the Subnet group

Remove all remaining public subnets from the subnet group.
Check that there are only private subnets present in the subnet group.
If your DB instance was previously in multi-AZ deployment, enable it again.

Note: Removing subnets from the subnet group is a configuration from the RDS side. It does not mean you are deleting any subnets from the VPC.

Conclusion

It is recommended that your AWS RDS instances are not present on a public subnet. This is because the public subnet does not provide a logically isolated environment for RDS instances to function and operate.

Get your new hires billable within 1-60 days. Experience our Capability Development Framework today.

Cloud Training
Customized Training
Experiential Learning

About CloudThat

CloudThat is also the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft gold partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding RDS or other consulting opportunities and I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package that is CloudThat’s offerings.

FAQs

1. Why do we keep the RDS instance in a private subnet?

ANS: – In general, you want to keep as many resources as possible out of public view on your network. Placing your RDS instance on a public subnet will allow traffic to be routed over the public internet and connected to your RDS instance. Although it is password protected, this is one method to prevent access, but if you want to secure this database, you should take as many steps as possible to minimize incoming traffic. It’s best to keep any resources you do not want the public internet to access on a private subnet, using a VPN or Direct Connect to that host. Alternatively, you can use the bastion host, although note that this would again be a public host. In addition to increasing security, ensure that the RDS instance is internal only and has strict security groups.

2. What are the risk factors if we create RDS in a public subnet?

ANS: – Remember that by making your database publicly available, you are effectively removing the highest layer of security you have. Even though you have a strong password, attackers can develop several ways to get in (not just brute force the password). Even if they do not get there, they can potentially prevent you from accessing it through several attacks, whether overwhelming resources (CPU, memory, disk) or maxing out the total number of available connections or ports. I would go as far as to say your DB should never need direct public access, at the very least look at using some bastion host or look at using a client VPN (AWS managed or OpenVPN) if you are in a pinch. budget (you can always turn them off when not in use).

3. How do I control the actions that my systems and users can take on specific Amazon RDS resources?

ANS: – You can control the actions that AWS IAM users and groups can perform with Amazon RDS resources. You do this by referencing Amazon RDS resources in the AWS IAM policies you apply to your users and groups. Amazon RDS resources that can be referenced in an AWS IAM policy include DB instances, DB snapshots, read replicas, DB security groups, DB option groups, DB parameter groups, event subscriptions, and DB subnet groups. In addition, you can tag these resources and add additional metadata to them. Using tagging, you can categorize your resources (e.g. “Development” DB instances, “Production” DB instances, and “Test” DB instances) and write AWS IAM policies that specify the permissions (i.e., actions) that can be performed on the resources. with the same marks.

WRITTEN BY Nitin Taneja

Nitin Taneja is a Research Associate at CloudThat. He is very fascinated by modern technologies like Cloud Computing, DevOps, Machine Learning, and many more. He has helped customers in migrating the whole infrastructure to the cloud and also helped in enhancing cloud security, and cost optimization in Cloud.