I didn't select a VPC when creating a MySQL RDS database, so it created it inside an auto-generated "default" VPC. I'm now unable to add it to any of my pre-defined security groups, or access it from instances in my existing VPC. The obvious solution would be to relocate it to the proper VPC, but there doesn't seem to be any option to edit the VPC on the "Modify db instance" screen. Is there any way to select a different VPC, or is my only option to delete the db and re-create it inside the correct VPC?


Amazon has recently issued a press release announcing that you can now change the VPC for existing RDS instances:

You can now easily change the Amazon Virtual Private Cloud (Amazon VPC) used by your Amazon RDS DB instance. You can specify a new VPC for an existing DB instance deployed in Single-AZ configuration by using the Amazon RDS Management Console, the Amazon RDS API, or the AWS Command Line Tools. In addition, if you are running your DB instance on the EC2-Classic environment, you can switch to the EC2-VPC environment by modifying your existing DB instance. If your AWS account was created before 2013-12-04, you are potentially running RDS on the EC2-Classic environment.

This feature is available for all regions supported by Amazon RDS, and is available for all supported versions of MySQL, MariaDB, Microsoft SQL Server, Oracle, and PostgreSQL.

Note that this feature is only supported for DB instances running in Single-AZ deployment. If you would like to change the VPC environment of a DB instance in a Multi-AZ deployment, you can temporarily modify your instance to a Single-AZ deployment and then re-enable Multi-AZ once you have changed to the EC2-VPC environment.

  • 2
    One thing to note: You can change the VPC but the Availability Zone of the database will NOT change. So if your db is in a VPC on subnet us-west-2a but the other does not have a subnet in that AZ, it will not let you change to that VPC – Matt Dodge Jun 15 '17 at 23:09

Simple - take a snapshot of your current RDS instance and then restore that snapshot to a new instance in your VPC.

  • 2
    The VPC drop-down was disabled for me until I said "yes" to Multi-AZ deployment. – Ian Phillips Sep 19 '14 at 0:12
  • How should I handle data that is added while I load the snapshot? Is there a way to minimize the downtime? – iGili Sep 28 '14 at 22:59
  • RDS is perfectly capable of acting as a MySQL solace to another system, so perhaps that might be the way to go. – EEAA Sep 28 '14 at 23:00

To avoid downtime when migrating to a new VPC you should set up Multi-AZ DB instances for your original RDS cluster so that the creation of a snapshot will not cause a brief I/O suspension. The cluster should also have binary logging enabled so that when you load your snapshot in the new VPC you can set up replication between the databases to restore any data that may have been inserted or updated after the snapshot was created.

Follow this guide from RDS docs


I had to do this with RDS Aurora and had to make slight modifications to the above guide:

  • When restoring from an Aurora snapshot you cannot set the parameter groups so the instance gets the default parameters automatically. Once the instance is available change the parameters to include binary logging and reboot it.

  • Running SHOW MASTER STATUS\G will not give you the correct binary log file and position of the original db at the time the snapshot was taken, the reboot of the instance created a new binary log file. Instead run SHOW BINARY LOGS; to find the previous log file and the file_size and use those values when setting up replication.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.