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.
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.
SHOW MASTER STATUS\Gwill 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.