Cloud technology is hands down one of the biggest tech revolutions of our times. It’s sheer magic just to think of the fact that you could run an entire organization out of a remote location and still access features and modules as seamlessly as you would in your premise.

With the competition being stiff in the cloud technology space, there are multiple vendors who are eyeing the attention and time of users to get to use their solutions. At the same time, companies of all sizes and scales – from small businesses to enterprises – all want to spend the minimum on setting up and maintaining their own cloud space.

If you’ve been one of those and you recently decided to go for Cloud AWS Database Migration your needs, this post is just for you. In this, we explore in detail the technicalities associated with an on-premise database to cloud migration service and discuss how it works as well.

So, let’s get started.

What is DMS?

AWS Database Migration Service (DMS) is a cloud service that makes it easy to migrate relational databases, data warehouses, NoSQL databases, and other types of data stores. This service is used to migrate your data into the AWS Cloud, between on-premises instances (through an AWS Cloud setup), or between combinations of cloud and on-premises setups.

What Are the Benefits of DMS?

There are several advantages one could experience by using DMS. To give you a quick idea, here are some of them:

• Cost-Effective — you pay only for the computing resources used during the migration process.
• Easy — It does not require any type of Driver or application installation. Nor does it require any changes to the source database most of the time.
• Reliable — Multi-AZ option allows you to have high availability for database migration and continuous data replication.
• Minimal Downtime — In the presence of DMS, your source database is continuously replicated even when your source database remains operational.
• Supports a wide range of Databases — It supports homogeneous migrations such as Oracle to Oracle, as well as heterogeneous migrations between different database platforms, such as Oracle to Amazon Aurora. It can also move data between SQL, NoSQL, etc.

Types of AWS Database Migrations

For the uninitiated, there are two types of migrations – homogenous and heterogeneous. The differences are pretty simple if you think about it. Let’s look at them briefly.

Homogeneous Database Migration

• In this type of migration, the source and target database engines are the same or compatible like Oracle to Amazon RDS for Oracle, MySQL to Amazon Aurora, MySQL to Amazon RDS for MySQL, or Microsoft SQL Server to Amazon RDS for SQL Server.
• The source database can be in your own premises running on an Amazon EC2 or it can be an Amazon RDS database. The target can be a database in Amazon EC2 or Amazon RDS.

Heterogeneous Database Migration

• In this type of migration, the source and target database engines are different.  Oracle to Amazon Aurora, Oracle to PostgreSQL, or Microsoft SQL Server to MySQL migrations.
• As a first step, use the AWS Schema Conversion Tool to convert the source schema and code to match that of the target database and use the AWS Database Migration Service to migrate data from the source database to the target database.
• As the second step, all the required data type conversions get automatically done by the AWS DMS during the migration. The target is the database in Amazon EC2 or Amazon RDS.

The Anatomy Of AWS

Click here for pricing and here for the schema conversion tool.

Lab: How to do database migration using AWS DMS from on-prem EC2 MySQL to RDS Aurora?

The technicalities associated with this could be tough. So, here’s a detailed step-by-step walkthrough with a screenshot is available below

1. Open AWS DMS console to quickly get started. Click on “Create replication instance”.

2. Fill in the details as required like a name for the instance, description, instance class, etc. as shown below.

3. Under the Advanced security and network configuration, select the replication subnet group, availability zone, and a KMS master key as shown in the above image.

4. Hit the create button, and you will see a replication instance in the list shown below.

5. Now, in the left navigation panel, click on the “Endpoints” and proceed to “Create endpoint.” Refer to the image below –

Now, under the “Test endpoint connection” section, select the VPC, replication instance and click on “Run Test”. Once the status changes to “successful”, click on “Create endpoint.” Refer below:

6. Now, let’s move to the Amazon RDS console and click on “Create database” and select Amazon Aurora, and choose other settings like the ones mentioned in the below image.

Your brand-new Aurora MySQL DB is ready as shown below:

You can view the connection details by clicking on the newly created Aurora DB. A popup will appear with the connection details.

8. Now, again revisit the “Endpoints” section from the left navigation pane and create a new endpoint for the target. Select the endpoint type as “Target endpoint”.

9. Next, enter a name for the endpoint identifier, select the target engine as “Amazon Aurora MySQL”, access to the endpoint database as “Provide access information manually”, enter the server name, enter the port “3306”, a user name and a password.

10. Under the “Test endpoint connection”, select the VPC, the replication instance, and then “Run test”. Wait till status changes to “successful” and then click on “Create endpoint”.

11. Now, let’s move to the “Database migration tasks” from the left navigation pane and click on “Create task.”

12. In the“Task configuration” section, enter relevant details like the name for the task identifier. Select the replication instance, source database endpoint, target database endpoint, and migration type and for the task, settings use the below details.

13. Under “Table mappings”, select editing mode “Wizard”.

14. Once you are done with the Create task, you will see the newly created task in the list and the status changes to “Ready” as well as you can see the “Progress” bar too.

Conclusion 

This was pretty extensive, right? When you understand the techniques of AWS application migration, it isn’t that tedious. We’re sure the post helped you in many ways. Share it with others in your circle that you think would benefit from it.