In this article, I am going to show you how to migrate an Amazon Relational Database Service (Amazon RDS) DB instance from one virtual private cloud (VPC) to another in the same AWS account. This is useful especially when you want to place your application stack and database in different VPCs for security reasons.
But this sort of approach has few limitations.
When you move the RDS DB instance to a new network and configure the new VPC, the DB instance reboots. So, change the VPC during a planned change window that is outside the RDS weekly maintenance window.
The DB instance you’re migrating must be a single instance with no standby. It must not be a member of a cluster.
Amazon RDS must not be in multiple Availability Zones. Convert the DB instance to a single AZ, and then convert it back to a Multi-AZ DB instance after moving to the new VPC.
Amazon RDS must not have any read replicas. Remove the read replicas, and then add read replicas after the DB instance is moved to the new VPC.
The subnet group created in the target VPC must have subnets from the Availability Zone where the source database is running. If the AZs are different, then the operation fails.
Let’s get started!
Please visit my GitHub Repository for RDS articles and GitHub Repository for VPC articles on various topics being updated on constant basis.
Objectives:
1. Create RDS Database Instance
2. Create a new VPC, Subnets, Route Tables, VPC Security Group
3. Create a new DB subnet group
4. Modify the Amazon RDS DB instance to use the new DB subnet group
Pre-requisites:
- AWS user account with admin access, not a root account.
- an IAM role with permissions required for the VPC, subnets, and Amazon RDS console
Resources Used:
Amazon RDS documentation
AWS IAM Documentation
Amazon VPC documentation
Steps for implementation to this project:
1. Create RDS Database Instance
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2. Create a new VPC, Subnets, Route Tables, VPC Security Group
Create a new VPC
1
2
3
Create new Subnets
1
2
3
- Create subnet
Create a new Route Table
1
2
3
4
Create a new VPC Security Group
1
2
3
- Create security group
3. Create a new DB subnet group.
1
2
- Create
4. Modify the Amazon RDS DB instance to use the new DB subnet group
1
2
3
4
5
6
7
8
9
10
11
- Continue
12
13
14
- When the migration to the target VPC is complete, the target VPC's default security group is assigned to the Amazon RDS DB instance.
15
16
- choose Events in the left navigation pane.
- Confirm that the process moved the DB instance to the target VPC
17
Cleanup
- delete RDS instance
- delete VPC and its components
What we have done so far
I have successfully moved an Amazon RDS DB instance to a new VPC, by first changing its subnet group.
Top comments (3)
Other Option:
using AWS Database Migration Service (DMS) to replicate the database and performing a blue/green deployment would be a better option to minimize downtime compared to directly updating the DB subnet group. Here are a few reasons why:
DMS uses replication to keep the source and target databases synchronized. This allows setting up the target database in the new VPC ahead of time. Once replication catches up, you can switch over applications to the target database with minimal interruption.
With blue/green deployment, the target database instance is already available and ready to take traffic once applications are redirected. This reduces downtime.
DMS supports continuous replication which helps maintain a more up-to-date copy of the database in the new VPC. This keeps the recovery point objective (RPO) low
Let me know your views.
I forgot - I have a post written on DMS Migration - Database Migration steps with the AWS CLI - 1 and 2. Just have to modify the VPC. Will try to do it when I have time.
yes, that is also an option