AWS Database Migration Service (DMS) automates the migration process to AWS database services. You can use DMS to migrate a wide range of data types, from any data source, to the AWS cloud. The process works by first connecting DMS to your source database. DMS then reads the data, prepares it for compatibility with the target database, and then transfers the data according to predefined migration tasks.
AWS DMS offers many more automated features; however, it is not a fully-automated service. You do need to set up the process, and that requires an understanding of DMS components and processes. In this post, we’ll explain AWS DMS benefits, pricing, and components. We’ll also show how NetApp Cloud Volumes ONTAP can help simplify the migration process and address database workload challenges in the cloud.
In this article, you will learn:
AWS Database Migration Service (DMS) is a service you can use to migrate from any database to AWS. You can use this service for both homogeneous (x to x) or heterogeneous (x to y) and on or offline migrations. DMS supports migration to Amazon RDS, Aurora, RedShift, DynamoDB, and DocumentDB.
To use the Database Migration Service you do not need to install agents or alter your source database (in most cases). Instead the migration process is controlled from the AWS Management Console. Once started, migration is a managed service that is resilient and self-healing.
Learn more about AWS migration in our guide: 5 Steps to the Cloud: AWS Migration Checklist. Or read about other AWS Cloud Migration Services.
There are several benefits of using AWS Database Migration Service over traditional migration methods. These include:
As mentioned, one of the benefits of AWS Database Migration Service is that it is available for free for specific services. This access is provided for the first six months which should be more than enough to get you through a standard migration. After that, you are charged the same as when using DMS with one of the not listed services.
If you are past the six-month period, or are using a different service pricing is as follows:
|
|
Single AZ |
Multi AZ |
|
Instance costs |
From $0.018 — $3.30 per hour |
From $0.036 — $6.60 per hour |
|
Storage costs |
$0.115 per GB per mth |
$0.23 per GB per mth |
|
Data transfer |
Free for all data transferred into DMS and any data transferred between DMS and RDS or EC2 instances in the same AZ.
If you migrate data to a different AZ or region, or migrate outside of AWS pricing starts at $0.0047 per hour. |
|
When using AWS Database Migration Service, you connect the service to your source database. The service then reads the data, formats it to match the requirements of your target database, and transfers the data according to the migration task you have defined. These processes occur primarily in-memory for greater performance. However, large transfers, logs, and cached transactions require disk storage or buffering.
Once replication from source to target begins, DMS begins monitoring your database for changes. This is done with Change Data Capture processes, known as AWS DMS CDC. CDC ensures that your data remains consistent between databases during the transfer process. It does this by caching changes made during migration and processing the changes once the primary migration task is over.
After the initial transfer is complete, Database Migration Service works through any cached items, applying changes to the target as needed. The service continues to monitor for and cache changes during this time and until you transfer your workloads and shut down your source database.
When operating Database Migration Service there are several components that you should be familiar with.
Amazon DMS Components
Replication instance
A replication instance is a managed EC2 instance that is used to host replication tasks. There are multiple replication instance types you can choose from, including:
Endpoints
To transfer data, AWS Database Migration Service uses an endpoint to connect to your target and source databases. The type of endpoint varies according to your database type, but all endpoints generally require the same information. This includes endpoint type, engine type, server name, port number, encryption protocols, and credentials.
Database replication tasks
Replication tasks define what data is moved between your target and source database and when. When creating a replication task, you need to define which replication instance to use, your target and source endpoints, and your migration type option.
The table below explains the migration options available to you.
|
Full load |
This option migrates the data that currently exists in your database when the task is started. It does not account for changes made after data has been replicated.
This is a good option when you can pause workloads for migration or if you are okay with not capturing changes. For example, if you are creating a test migration. |
|
Full load + CDC |
This option migrates data at the time of task start and caches data changes for later replication. Once changes are replicated, this option continues to monitor your database until the task is ended.
This is a good option when you have large databases to transfer and cannot afford to or simply don’t want to pause workloads. Using this option you can migrate your database well in advance of when you shift your workloads over, giving you greater flexibility in your migration. |
|
CDC only |
This option only migrates changes made to the database since the task was started. It does not perform any initial transfer of data.
This option is useful when you are using another method to transfer databases but still need to capture changes to keep databases synced. For example, if you can start a CDC only task immediately after exporting a database copy. You can then import your copy into your target database while collecting changes with the DMS task. |
Schema migration and conversion
When performing a homogenous migration, Database Migration Service attempts to create a target schema. However, this isn’t always possible. For example, if you are migrating an Oracle database, a target schema isn’t created to ensure security. In these cases, you’ll need to use tools such as Oracle SQL Developer, pgAdmin III, or MySQL Workbench.
For heterogeneous migrations, you also need to take additional steps because AWS Database Migration Service is not able to perform schema conversions. For this conversion, you can use a third-party tool, or you can use AWS Schema Conversion Tool (SCT).
SCT enables you to automatically convert your source schema to a compatible format for your target database. This includes the conversion of most code objects, including stored procedures, functions, and views. It is also able to scan your database applications for legacy SQL Server or Oracle functions and update functions to an equivalent AWS service. If the tool is unable to convert objects, it marks each for you to manually handle.
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP supports up to a capacity of 368TB, and supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
In particular, Cloud Volumes ONTAP helps in addressing database workloads challenges in the cloud, and filling the gap between your cloud-based database capabilities and the public cloud resources it runs on. You can leverage Cloud Volumes ONTAP features to ensure your data remains available and secure as you migrate it to AWS.