I have an Amazon Relational Database Service (Amazon RDS) DB instance that’s in a public subnet. I want to move my DB instance to a private subnet within the same virtual price cloud (VPC), and make the DB instance private.
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 following workaround to move your DB instance from a public subnet to a private subnet. When you use this workaround, you don't need to create a new DB instance or use the snapshot-restore process. The workaround also minimizes downtime when you create a new instance and divert traffic. Only the failover time results in noticeable downtime.
Note: Use this workaround only for RDS DB instances. If your DB instance is part of an Aurora cluster, then use the clone option. Or, follow this resolution, but don't turn off Multi-AZ. Instead, delete and recreate the readers.
Resolution
Turn off Multi-AZ deployments and public accessibility on your DB instance
If you already set your DB instance to Single-AZ with the Public accessibility parameter set to No, then skip this step.
To turn off Multi-AZ deployments for your DB instance, complete these steps:
- Open the Amazon RDS console.
- From the navigation pane, choose Databases. Then, choose the DB instance.
- Choose Modify.
- From the Modify DB Instance page, for Multi-AZ deployment and Public accessibility, choose No.
- Choose Continue, and then review the summary of modifications.
- Choose Apply immediately or Apply during the next scheduled maintenance window.
Note: Because the modification causes your DB to reboot, downtime occurs. For more information, see Using the Apply Immediately setting.
- 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 IP address:
dig rds_endpoint
Note: Replace rds_endpoint with your DB instance's endpoint.
Example output:
db-RDS-instance.xxxxxxxx.us-east-1.rds.amazonaws.com. 5 IN A 172.39.5.213
From the private IP address, you can find the subnet that your primary instance uses.
The following subnets are found in this example:
- subnet 1: 172.39.5.0/24
- subnet 2: 172.39.4.0/24
Because the IP address is under 172.39.5.0/24, the instance is in subnet 1.
Remove the public subnets and add private subnets on your DB instance
Add all the private subnets in the subnet group. Also, delete all public subnets from the subnet group, except for the one that your primary instance uses. In the previous example, delete everything except subnet 1 because the DB instance uses this subnet.
Complete the following steps:
- Open the Amazon RDS console.
- From the navigation pane, choose Subnet groups. Then, choose the subnet group that's associated with your DB instance.
- Choose Edit.
- From the Add subnets section, select the Availability Zone and private subnets.
- Select the public subnets to delete, and then choose Remove.
- Choose Save.
Turn on Multi-AZ on your DB instance
Turn on the Multi-AZ deployment for your DB instance. The new secondary instance 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 instance becomes the primary instance. As a result, your new primary instance uses the private IP address. After you reboot your DB instance with failover, remove the new secondary instance that's now in the public subnet. To remove the secondary instance, set Multi-AZ deployment to No to turn off Multi-AZ.
Remove the public subnet
Complete the following steps:
- Remove the remaining public subnet from the subnet group.
Note: Remove the subnets from the subnet group on the RDS side. You don't need to delete any subnets from the VPC.
- Check that there are only private subnets in the subnet group.
- If your DB instance was previously in a Multi-AZ deployment, then turn on Multi-AZ deployment again.
Related information
Multi-AZ DB cluster deployments