In this video, you’ll see how to standardize database migrations with AWS Database Migration Service (AWS DMS) and AWS Service Catalog.
With this capability, you can migrate databases to AWS quickly and securely, allow your databases to remain fully operational during migrations
and migrate your data to and from widely used commercial and open-source databases.
For the purposes of this example, we’ve already deployed our publicly available CloudFormation stacks into our environment,
which provisioned the necessary resources and Service Catalog products required to conduct this database migration.
For more information on this setup, please check out the links in the description for this video.
To get started, let’s navigate to Service Catalog.
Here’s the portfolio that was provisioned from the CloudFormation stack we ran.
And here are all the products associated with that portfolio.
On the Groups, roles, and users tab,
we can see the role in our environment that has the necessary permissions to work with the provisioned products.
We can drill into any of these products to see the baseline version that was deployed and view the template file associated with it.
Now let’s start our deployments.
First, we’ll launch a product to deploy an example infrastructure for our database migration.
This step is for illustrative purposes, as you will most likely have your own infrastructure running at this point.
Let’s provide a name.
Next, we’ll choose the Availability Zones we’d like to use for the subnets in our virtual private cloud (VPC).
Next, we’ll put in our Workstation CIDR.
Last, we’ll put in a password and launch the product.
Let’s take note of this highlighted information from our database infrastructure.
We’ll need the security groups and subnets later on.
Let’s go back to our products.
Next, we’ll provision the target database with Amazon RDS.
To do so, we’ll launch the Migrations - RDS MSSQL Database Instance product.
Let’s name our provisioned product “Target RDS.”
Next, we’ll put in a password for the target database.
Now let’s reference our database infrastructure to specify the security group that the RDS instance will use.
Next, we’ll specify our subnets, once again using our infrastructure as reference.
We’ll select the target VPC subnets.
Finally, let’s proceed and launch the product.
Now that the deployment has successfully completed, let’s find the endpoint.
The endpoint for the VPC instance will come in handy when we deploy the migration components, so let’s take note of it.
Let's go back to our product.
Next, we’ll deploy an instance that will be used as the utility server for migrations,
which will contain the necessary scripts and the AWS Schema Conversion Tool.
To do so, we’ll launch the Migrations - Utility Server product.
Let’s provide a name for this instance.
Next, we’ll choose the target VPC subnets that we’ll deploy the server to.
Next, let’s specify a password and security group for this instance.
In selecting the utility security group, we’ll once again refer to our database infrastructure.
Finally, let’s launch the product.
Let’s confirm that the instance has been successfully launched, and then go back to our products.
Now we’re ready to deploy the components of DMS.
First, we’ll provide a name.
Again, we’ll choose our target VPC subnets.
Next, we’ll specify the security group designated for DMS in our database infrastructure.
Next, we’ll enter the private IP address for the endpoint and the password for our source database.
Now we’ll paste in the endpoint for the Target RDS instance that was deployed earlier,
along with the target database password.
Let’s launch the product and wait to see that it provisioned successfully.
Now, with everything provisioned, let’s create a database migration task.
To do so, we’ll navigate over to DMS.
The resource summary pane shows the deployments we’ve conducted.
Let’s create a database migration task.
First, we’ll configure the task with an identifier,
replication instance,
source database,
target database,
and migration type.
In this case, we’ll retain the default task settings, except we’ll enable data validation between the source database and the target.
Now we’ll add a selection rule for the migration.
For the purposes of this example, we’ll enter a schema consisting of default wildcard values, meaning everything will be migrated.
Finally, let’s create the migration task.
As you can see, our migration was created successfully.
Our task is configured for on-going replication to keep our source and target databases in sync.
If needed, we can modify, restart, or delete the task from the Actions menu.
You’ve just seen how to standardize database migrations with AWS DMS and AWS Service Catalog.
You can learn more about this topic in the description and links for this video.
Thanks for watching. Now it’s your turn to try.