How can I move an Amazon RDS DB instance from a public subnet to private subnet within the same VPC?

Last updated: 2022-06-23

I have an Amazon Relational Database Service (Amazon RDS) DB instance that is in a public subnet. I want to move my DB instance from a public to a private subnet within the same VPC, and make my DB instance completely private. How can I do this?

Short description

Amazon RDS doesn't provide an option to change the subnet group of your DB instance, within the same VPC. However, you can use the workaround method in this article to move your DB instance from a public subnet to a private subnet. Performing this action makes your DB instance private.

This method has a number of advantages, including:

  • You don't need to create a new DB instance
  • You don't need to use the snapshot-restore process
  • It minimizes the downtime involved in creating a new instance and diverting traffic. The only downtime that you see is the failover time.

Resolution

Turn off Multi-AZ deployments and public accessibility on your DB instance

If your DB instance is already set to Single-AZ with the Public accessibility parameter set to No, then skip this step.

To modify your DB instance to turn off Multi-AZ deployments, follow these steps:

  1. Sign in to the Amazon RDS console.
  2. From the navigation pane, choose Databases, and then choose the DB instance that you want to modify.
  3. Choose Modify.
  4. From the Modify DB Instance page, for Multi-AZ deployment and Public accessibility, choose No.
  5. Choose Continue, and then review the summary of modifications.
  6. Choose Apply immediately to apply your changes.
  7. Review your changes, and if correct, choose Modify DB Instance to save.

Discover the IP address of your DB instance

After your DB instance returns to the Available state, run dig on the DB instance's endpoint to find its underlying IP address:

dig <rds-endpoint>

Output:

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

From the private IP, you can find which subnet your primary instance is using.

In this example, the list of subnet CIDR is as follows:

  • subnet1 -> 172.39.5.0/24
  • subnet2 -> 172.39.4.0/24

Because the IP is falling under 179.39.5.0/24, you can conclude that the instance is placed in subnet1.

Remove the public subnets and add private subnets on your DB instance

Add all the required private subnets in the subnet group. Also, delete all public subnets from the subnet group except for the one that is used by your primary. In the previous example, you delete everything except subnet1 because it is used by your DB instance.

Note: A private subnet is a subnet that is associated with a route table that has no route for an internet gateway.

  1. Sign in to the Amazon RDS console.
  2. From the navigation pane, choose Subnet groups, and then choose the subnet group that is associated with your DB instance.
  3. Choose Edit.
  4. From the Add subnets section, choose the Availability Zone and private subnets that you want to add.
  5. Select the public subnets that you want to delete, and then choose Remove.
  6. Choose Save.

Turn on Multi-AZ on your DB instance

Modify the DB instance to turn on the Multi-AZ deployment. The new secondary launches in one of the remaining private subnets.

Reboot your DB instance with failover and turn off Multi-AZ deployment

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

After you reboot your DB instance with failover, remove the secondary, which is now in the public subnet. To do this, modify the DB instance to turn off Multi-AZ, again. You can do this by setting Multi-AZ deployment to No.

Remove the public subnet

  1. Remove the remaining public subnet from the subnet group.
    Note: Removing subnets from the subnet group is a configuration from the RDS side. It doesn't involve deleting any subnets from the VPC.
  2. Check that there are only private subnets in the subnet group.
  3. If your DB instance was previously in Multi-AZ deployment, then turn Multi-AZ deployment on again.

This solution involves failover and turning on/turning off Multi-AZ so there are few things to consider. For more information, see Multi-AZ DB instance deployments.

Note: This method is specific for RDS DB instances. If your DB instance is part of Aurora cluster, then you can use the clone option. Or you can follow the steps in this article, but instead of turning off Multi-AZ, you should delete and recreate the readers.


Did this article help?


Do you need billing or technical support?