Introduction

Customers are increasingly choosing VMware Cloud on AWS to migrate their applications from on-premises VMware virtual environments without refactoring. Even when aiming for future cloud-native architecture, VMware Cloud on AWS is often chosen as the first step. In this article, I will introduce methods for migrating databases using VMware Cloud on AWS as the starting point.

Customers can also use AWS DMS to migrate the databases running on VMware Cloud on AWS to Amazon Relational Database Service (Amazon Aurora and Amazon RDS). This provides a next step of cloud journey for modernization, while still keeping applications on VMware Cloud on AWS with minimum impact or risk to their business.

Then, I will guide you how to migrate a database running on VMware Cloud on AWS to Amazon Aurora by using AWS DMS.

About AWS DMS

AWS DMS is one of AWS’s migration services and is trusted by customers globally to securely migrate 1,000,000 databases with minimal downtime.

AWS DMS with VMware Cloud on AWS

In this post, I will demonstrate how AWS DMS enables you to migrate MySQL running on VMware Cloud on AWS to Amazon Aurora. Amazon Aurora is a modern relational database service offering performance and high availability at scale, offers open-source MySQL and PostgreSQL compatible editions, and supports a range of developer tools for building serverless and machine learning (ML)-driven applications.

Overview

The following architecture overview shows how AWS DMS migrates a MySQL database (DB VM) running on VMware Cloud on AWS to Amazon Aurora deployed in a connected VPC via an Elastic Network Interface (ENI).

Please note that all the communication in the Figure above is kept private since the communication between VMware Cloud on AWS and the connected VPC is internally connected via an ENI.

Pre-requisites

General

• WordPress (App VM) and MySQL (DB VM) are running on VMware Cloud on AWS. In this example, I used the following environment.

  • VMware Cloud on AWS: SDDC version 1.22
  • App VM: Cent OS Linux 7, WordPress 6.2
  • DB VM: Cent OS Linux 7, MySQL 8.0
  • AWS DMS: Engine version 3.4.7
  • Amazon Aurora: version 3 compatible with MySQL 8.0

• All required communication between VMware Cloud on AWS and Connected VPC is allowed in firewall rules of VMware Cloud on AWS and a security group of the connected VPC, and established

• All required actions are allowed in AWS Identity and Access management (IAM) policies for AWS DMS. For more information about AWS DMS access requirements, please see Security in AWS Database Migration Service.

• MySQL and Amazon Aurora versions are compatible, and supported by AWS DMS

Database details

Destination database location

• Amazon Aurora (MySQL compatible) is running within the Connected VPC

Source database

• MySQL is already set up as WordPress database

Steps

For this example, I’ll walk through AWS DMS configurations covering the following sections:

1. Create a replication instance in the connected VPC
2. Create source and destination endpoints
3. Create and execute a database migration task
4. Switch DB access for WordPress from MySQL to Amazon Aurora and test

Step 1. Create an AWS DMS replication instance

When you create an AWS DMS replication instance, AWS DMS creates it on an Amazon EC2 instance in a VPC. You use this replication instance to perform your database migration. You can choose the Multi-AZ option if you need high availability and failover support.

In this example, I chose Single-AZ option and deployed the replication instance in the Connected VPC.

Create a DMS replication instance in the connected VPC

Create a replication instance in the Connected VPC.

Parameters check

You can choose parameters following your environments and requirements

Step 2. Create source and destination endpoints

Create endpoint

Create an endpoint for both Source (MySQL side) and Target (Amazon Aurora side).

An endpoint provides connection, data store type, and location information about your data store. AWS DMS uses this information to connect to a data store and migrate data from a source endpoint to a target endpoint. You can specify additional connection attributes for an endpoint by using endpoint settings.

Create a source endpoint

First, create a source endpoint. Register access information for the DB VM (MySQL) running on VMware Cloud on AWS.

Create a target endpoint

Next, create a target endpoint. Register your access information for Amazon Aurora running on the Connected VPC.

(Optional) target Endpoint connection test

Before creating the Target endpoint, you can test a connection to the replication instance.

Then, the pre-migration setup with AWS DMS is now complete.

Step 3. Create and execute a database migration task

An AWS DMS task is where all the work happens. You specify what tables (or views) and schemas to use for your migration and any special processing, such as logging requirements, control table data, and error handling.

A task can consist of three major phases:

• Migration of existing data (Full load)
• The application of cached changes
• Ongoing replication (Change Data Capture)

For more information and an overview of how AWS DMS migration tasks migrate data, please refer to High-level view of AWS DMS

Migration of existing data

In this example, I simply chose “Migration of existing data” to migrate data from MySQL to Amazon Aurora.

And, I chose MySQL schema "wordpress" to migrate to Amazon Aurora.

You can check the execution status in “Status”.

With this, I could migrate the MySQL data to Amazon Aurora.

Next, let’s confirm the data migration from WordPress applicaiton.

Step 4. Switch WordPress' database access from MySQL to Amazon Aurora and test

After database migration, let’s test with the WordPress application. Once updating the “wp-config.php” configuration file to switch DB access for WordPress (App VM), the WordPress accesses Amazon Aurora.

Switching DB access for WordPress (App VM)

Migration check

As shown below, I can see that all my WordPress posts had been successfully migrated.

Additional Considerations

• If you conduct a similar database migration with AWS DMS in production environment, please make sure that you follow these security guidelines.

  • Amazon Aurora security
  • Security in AWS Database Migration Service
  • About VMware Cloud on AWS Networking and Security

• You also need to consider the cost. In this example, I used AWS DMS with on-demand Amazon EC2 instance to run as a replication instance so the on-demand utilization will be charged. On the other hand, the data transfer between the VMware Cloud on AWS SDDC and connected VPC will not incur any egress costs since the SDDC and destined Amazon EC2 instance reside in the same AWS Availability Zone (AZ). For more details about the cost, please refer to AWS Database Migration Service pricing.

• If you use other VPCs as a database migration destination rather than a Connected VPC, you can use AWS Transit Gateway (TGW) and VMware Transit Connect (VTGW) for a network connectivity.

• AWS DMS can use many of the most popular data engines as a source for data replication. The database source can be a self-managed engine running on an Amazon EC2 instance or an on-premises database. Or it can be a data source on an AWS service such as Amazon RDS or Amazon S3. For a comprehensive list of valid sources, please see Sources for AWS DMS. For more detailed prerequisites about AWS DMS, please refer to Prerequisites for AWS Database Migration Service.

Conclusion

It is not difficult to imagine that database migration is tough, but AWS DMS can greatly lower the hurdles in that process. I would be happy if this post encourages you to consider further modernization. There are many reference materials in AWS DMS. A summary is provided below. Please check them out as well.

Additional Resources

• Data Warehousing and Business Intelligence for VMware Cloud on AWS

• Account and VPC Considerations for VMware Cloud on AWS

• VMware Cloud on AWS Hybrid Network Design Patterns

• How to Migrate from MySQL to Amazon Aurora using AWS SCT and AWS DMS