Introduction to AWS DMS. amazon web services AWS Database Migration Service

AWS Database Migration Service User Guide

Migration: A High-Level View

Introduction to AWS DMS

AWS Database Migration Service (AWS DMS) is a web service that you can use to migrate data from a source database to a target database. To work with AWS DMS, one of your databases must be on an AWS service. You can't migrate from an on-premises database to another on-premises database.

Migration: A High-Level View

To perform a database migration, AWS DMS connects to the source database, reads the source data, formats the data for consumption by the target database, and loads the data into the target database.

Most of this processing happens in memory, though large transactions might require some buffering to disk. Cached transactions and log files are also written to disk.

At a high level, when using AWS DMS, you do the following:

• Provision a replication server

• Define source and target endpoints (databases)

• Create one or more tasks to migrate data between the source and target databases.

A typical task consists of three major phases:

• The full load of existing data

• The application of cached changes

• Ongoing replication

During the full load, AWS DMS loads data from tables on the source database to tables on the target database, eight tables at a time. While the full load is in progress, any changes made to the tables being loaded are cached on the replication server; these are the cached changes. It’s important to note that change capture for a given table doesn't begin until the full load for that table is started. In other words, the point when change capture starts will be different for each individual table.

When the full load for a given table is complete, AWS DMS immediately begins to apply the cached changes for that table. When all tables have been loaded, AWS DMS begins to collect changes as transactions for the ongoing replication phase. After AWS DMS applies all cached changes, tables are

API Version API Version 2016-01-01

3

AWS Database Migration Service User Guide

AWS DMS Components transactionally consistent. At this point, AWS DMS moves to the ongoing replication phase, applying changes as transactions.

At the start of the ongoing replication phase, a backlog of transactions generally causes some lag between the source and target databases. The migration eventually reaches a steady state after working through this backlog of transactions. At this point, you can shut down your applications, allow any remaining transactions to be applied to the target, and bring your applications up, now pointing at the target database.

AWS DMS creates the target schema objects necessary to perform the migration. However, AWS DMS takes a minimalist approach and creates only those objects required to efficiently migrate the data. In other words, AWS DMS creates tables, primary keys, and in some cases unique indexes, but it doesn't create any other objects that are not required to efficiently migrate the data from the source. For example, it doesn't create secondary indexes, non-primary key constraints, or data defaults.

In most cases, when performing a migration, you will also want to migrate most or all of the source schema. If you are performing a homogeneous migration (between two databases of the same engine type), you migrate the schema by using your engine’s native tools to export and import the schema itself, without any data. If your migration is heterogeneous (between two databases that use different engine types), you can use the AWS Schema Conversion Tool to generate a complete target schema for you. If you use the tool, any dependencies between tables such as foreign key constraints need to be disabled during the migration's “full load” and “cached change apply” phases. If performance is an issue, removing or disabling secondary indexes during the migration process will help. For more information on the AWS Schema Conversion Tool, see AWS Schema Conversion Tool .

AWS DMS Components

The components you work with when using AWS DMS include the following:

Replication instance

The AWS DMS replication instance runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance. The replication instance provides high-availability and failover support using a Multi-

AZ deployment. In a Multi-AZ deployment, AWS DMS automatically provisions and maintains a synchronous standby replica of the replication instance in a different Availability Zone. The primary replication instance is synchronously replicated across Availability Zones to a standby replica. This approach provides data redundancy, eliminate I/O freezes, and minimize latency spikes during system backups.

AWS DMS uses a replication server that connects to the source database, reads the source data, formats the data for consumption by the target database, and loads the data into the target database. Most of this processing happens in memory. However, large transactions might require some buffering on disk. Cached transactions and log files are also written to disk. When creating your replication server, you should consider the following:

• EC2 instance class — Some of the smaller EC2 instance classes are sufficient for testing the service or for small migrations. If your migration involves a large number of tables, or if you intend to run multiple concurrent replication tasks, you should consider using one of the larger instances. We recommend this approach because AWS DMS consumes a fair amount of memory and CPU.

• Storage — Depending on the EC2 instance class you select, your replication server comes with either 50 GB or 100 GB of data storage. This storage is used for log files and any cached changes collected during the load. If your source system is busy or takes large transactions, or if you’re running multiple tasks on the replication server, you might need to increase this amount of storage. Usually the default amount is sufficient.

Source endpoint

The change capture process that AWS DMS uses when replicating ongoing changes from a source endpoint collects changes to the database logs by using the database engine's native API. Each

API Version API Version 2016-01-01

4

AWS Database Migration Service User Guide

Sources source engine has specific configuration requirements for exposing this change stream to a given user account. Most engines require some additional configuration to make the change data consumable in a meaningful way, without data loss, for the capture process. For example, Oracle requires the addition of supplemental logging, and MySQL requires row-level bin logging. When using Amazon RDS as a source, we recommend ensuring that backups are enabled and that the source database is configured to retain change logs for a sufficient time (24 hours is usually enough).

Target endpoint

Task

Whenever possible, AWS DMS attempts to create the target schema for you. Sometimes, AWS DMS can't create the schema—for example, AWS DMS won't create a target Oracle schema for security reasons. For MySQL database targets, you can use extra connection parameters to have AWS DMS migrate all objects to the specified database and schema or create each database and schema for you as it finds the schema on the source.

You can create one of three possible types of migration tasks:

• Migrate existing data — If you can afford an outage long enough to copy your existing data, this option is a good one to choose. This option simply migrates the data from your source database to your target database, creating tables when necessary.

• Migrate existing data and replicate ongoing changes — This option performs a full data load while capturing changes on the source. Once the full load is complete, captured changes are applied to the target. Eventually the application of changes reaches a steady state. At this point you can shut down your applications, let the remaining changes flow through to the target, and then restart your applications pointing at the target.

• Replicate data changes only — In some situations it might be more efficient to copy existing data using a method other than AWS DMS. For example, in a homogeneous migration, using native export/import tools might be more efficient at loading the bulk data. In this situation, you can use AWS DMS to replicate changes starting when you start your bulk load to bring and keep your source and target databases in sync

By default AWS DMS starts your task as soon as you create it. However, in some situations, you might want to postpone the start of the task. For example, when using the AWS Command Line Interface

(AWS CLI), you might have a process that creates a task and a different process that starts the task based on some triggering event. As needed, you can postpone your task's start.

Schema and code migration

AWS DMS doesn't perform schema or code conversion. You can use tools such as Oracle SQL

Developer, MySQL Workbench, or pgAdmin III to move your schema if your source and target are the same database engine. If you want to convert an existing schema to a different database engine, you can use the AWS Schema Conversion Tool. It can create a target schema and also can generate and create an entire schema: tables, indexes, views, and so on. You can also use the tool to convert PL/

SQL or TSQL to PgSQL and other formats. For more information on the AWS Schema Conversion

Tool, see AWS Schema Conversion Tool .

Sources for AWS Database Migration Service

You can use the following databases as a source for data migration using AWS Database Migration

Service.

On-premises and EC2 instance databases

• Oracle versions 10.2 and later, 11g, and up to 12.1, for the Enterprise, Standard, Standard One, and

Standard Two editions

API Version API Version 2016-01-01

5

AWS Database Migration Service User Guide

Targets

• Microsoft SQL Server versions 2005, 2008, 2008R2, 2012, and 2014, for the Enterprise, Standard,

Workgroup, and Developer editions. The Web and Express editions are not supported.

• MySQL versions 5.5, 5.6, and 5.7

• MariaDB (supported as a MySQL-compatible data source)

• PostgreSQL version 9.4 and later

• MongoDB

• SAP Adaptive Server Enterprise (ASE) 15.7 and later

Amazon RDS instance databases

• Oracle versions 11g (versions 11.2.0.3.v1 and later) and 12c, for the Enterprise, Standard, Standard

One, and Standard Two editions

• Microsoft SQL Server versions 2008R2, 2012, and 2014, for the Enterprise, Standard, Workgroup, and

Developer editions. Note that change data capture (CDC) operations are not supported. The Web and

Express editions are not supported.

• MySQL versions 5.5, 5.6, and 5.7

• MariaDB (supported as a MySQL-compatible data source)

• PostgreSQL 9.4 and later. Note that Change Data Capture (CDC) is only supported for versions 9.4.9

and higher and 9.5.4 and higher. The rds.logical_replication

parameter, which is required for CDC, is supported only in these versions and later.

• Amazon Aurora (supported as a MySQL-compatible data source)

Targets for AWS Database Migration Service

You can use the following databases as a target for data replication using AWS Database Migration

Service.

On-premises and Amazon EC2 instance databases

• Oracle versions 10g, 11g, 12c, for the Enterprise, Standard, Standard One, and Standard Two editions

• Microsoft SQL Server versions 2005, 2008, 2008R2, 2012, and 2014, for the Enterprise, Standard,

Workgroup, and Developer editions. The Web and Express editions are not supported.

• MySQL, versions 5.5, 5.6, and 5.7

• MariaDB (supported as a MySQL-compatible data target)

• PostgreSQL, versions 9.3 and later

• SAP Adaptive Server Enterprise (ASE) 15.7 and later

Amazon RDS instance databases, Amazon Redshift, Amazon DynamoDB, and Amazon S3

• Oracle versions 11g (versions 11.2.0.3.v1 and later) and 12c, for the Enterprise, Standard, Standard

One, and Standard Two editions

• Microsoft SQL Server versions 2008R2, 2012, and 2014, for the Enterprise, Standard, Workgroup, and

Developer editions. The Web and Express editions are not supported.

• MySQL, versions 5.5, 5.6, and 5.7

• MariaDB (supported as a MySQL-compatible data target)

• PostgreSQL, versions 9.3 and later

API Version API Version 2016-01-01

6

AWS Database Migration Service User Guide

Replication Instances

• Amazon Aurora (supported as a MySQL-compatible data target)

• Amazon Redshift

• Amazon S3

• Amazon DynamoDB

Replication Instances for AWS Database Migration

Service

AWS DMS creates a replication instance that runs on an Amazon Elastic Compute Cloud (Amazon

EC2) instance in a VPC based on the Amazon Virtual Private Cloud (Amazon VPC) service. You use this replication instance to perform the database migration. The replication instance provides highavailability and failover support using a Multi-AZ deployment when you select the Multi-AZ option.

In a Multi-AZ deployment, AWS DMS automatically provisions and maintains a synchronous standby replica of the replication instance in a different Availability Zone. The primary replication instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy, eliminate I/O freezes, and minimize latency spikes.

AWS DMS currently supports the T2 and C4 instance classes for replication instances. The T2 instance classes are low-cost standard instances designed to provide a baseline level of CPU performance with the ability to burst above the baseline. They are suitable for developing, configuring, and testing your database migration process, and for periodic data migration tasks that can benefit from the CPU burst capability. The C4 instance classes are designed to deliver the highest level of processor performance and achieve significantly higher packet per second (PPS) performance, lower network jitter, and lower network latency. You should use C4 instance classes if you are migrating large databases and want to minimize the migration time.

Each replication instance has a specific configuration of memory and vCPU. The following table shows the configuration for each replication instance type. For pricing information, see the Amazon Database

Migration Service pricing page .

Replication Instance Type

General Purpose dms.t2.micro

dms.t2.small

dms.t2.medium

dms.t2.large

Compute Optimized dms.c4.large

dms.c4.xlarge

vCPU

1

1

2

2

2

4

Memory (GB)

1

2

4

8

3.75

7.5

API Version API Version 2016-01-01

7

AWS Database Migration Service User Guide

Public and Private Replication Instances

Replication Instance Type

dms.c4.2xlarge

dms.c4.4xlarge

vCPU

8

16

Memory (GB)

15

30

Public and Private Replication Instances

You can specify whether a replication instance has a public or private IP address that the instance uses to connect to the source and target databases. A replication instance should have a public IP address if the source or target database is located in a network that is not connected to the replication instance's VPC by using a virtual private network (VPN), AWS Direct Connect, or VPC peering.

A private replication instance has a private IP address that cannot be accessed outside the replication network. A replication instance should have a private IP address when both the source and target databases are located in the same network that is connected to the replication instance's VPC by using a

VPN, AWS Direct Connect, or VPC peering.

A VPC peering connection is a networking connection between two VPCs that enables routing using each

VPC’s private IP addresses as if they were in the same network. For more information about VPC peering, see VPC Peering in the Amazon VPC User Guide.

AWS DMS Maintenance Window

Periodically, AWS DMS performs maintenance on AWS DMS resources. Maintenance most often involves updates to the replication instance or the replication instance's operating system (OS). You can manage the time period for your maintenance window and see maintenance updates using the AWS CLI or AWS

DMS API. The AWS DMS console is not currently supported for this work.

You can manually apply maintenance items at your convenience, or wait for the automatic maintenance process initiated by AWS DMS during your weekly maintenance window. You can find out whether a maintenance update is available for your replication instance by using the AWS CLI or AWS DMS API.

Maintenance items require that AWS DMS take your replication instance offline for a short time.

Maintenance that requires a resource to be offline includes required operating system or instance patching. Required patching is automatically scheduled only for patches that are related to security and instance reliability. Such patching occurs infrequently (typically once or twice a year) and seldom requires more than a fraction of your maintenance window.

Use the

DescribeReplicationInstances

API action to determine if there are pending modifications to your replication instance and to see the current time period for your maintenance window.

The

PendingModifiedValues

parameter indicates what parameter changes are pending. The

PreferredMaintenanceWindow

parameter shows the current time period for your maintenance window.

To change the time of the maintenance window, use the

ModifyReplicationInstance

API action and set the

PreferredMaintenanceWindow

parameter to your preferred time period.

The default maintenance window time period is determined by the AWS Region. The following table lists the maintenance window for each AWS Region that supports AWS DMS.

Region

Asia Pacific (Sydney) Region

Asia Pacific (Tokyo) Region

Time Block

12:00–20:00 UTC

13:00–21:00 UTC

API Version API Version 2016-01-01

8

AWS Database Migration Service User Guide

Setting Up a Network for Database Migration

Region Time Block

Asia Pacific (Mumbai) Region 17:30–01:30 UTC

Asia Pacific (Seoul) Region 13:00–21:00 UTC

14:00–22:00 UTC Asia Pacific (Singapore)

Region

Canada (Central) Region 06:29–14:29 UTC

EU (Frankfurt) Region

EU (Ireland) Region

EU (London) Region

South America (São Paulo)

Region

US East (N. Virginia) Region

US East (Ohio) Region

US West (N. California)

Region

US West (Oregon) Region

20:00–04:00 UTC

22:00–06:00 UTC

06:00–14:00 UTC

23:00–07:00 UTC

03:00–11:00 UTC

03:00–11:00 UTC

06:00–14:00 UTC

06:00–14:00 UTC

Setting Up a Network for Database Migration

AWS DMS always creates the replication instance in an Amazon Virtual Private Cloud (Amazon VPC), and you specify the VPC where your replication instance is located. You can use your default VPC for your account and region, or you can create a new VPC. The VPC must have two subnets in at least one

Availability Zone.

The Elastic Network Interface (ENI) allocated for the replication instance in your VPC must be associated with a security group that has rules that allow all traffic on all ports to leave (egress) the VPC. This approach allows communication from the replication instance to your source and target database endpoints, as long as correct egress rules are enabled on the endpoints. We recommend that you use the default settings for the endpoints, which allows egress on all ports to all addresses.

The source and target endpoints access the replication instance that is inside the VPC either by connecting to the VPC or by being inside the VPC. The database endpoints must include network

ACLs and security group rules (if applicable) that allow incoming access from the replication instance.

Depending on the network configuration you are using, you can use the replication instance VPC security group, the replication instance's private or public IP address, or the NAT Gateway's public IP address.

These connections form a network that you use for data migration.

Network Configurations for Database Migration

You can use several different network configurations with AWS Database Migration Service. The following are common configurations for a network used for database migration.

Topics

•

Configuration with All Database Migration Components in One VPC (p. 10)

•

Configuration with Two VPCs (p. 10)

API Version API Version 2016-01-01

9

AWS Database Migration Service User Guide

Network Configurations for Database Migration

•

Configuration for a Network to a VPC Using AWS Direct Connect or a VPN (p. 11)

•

Configuration for a Network to a VPC Using the Internet (p. 11)

•

Configuration with an Amazon RDS DB instance not in a VPC to a DB instance in a VPC Using

ClassicLink (p. 11)

Configuration with All Database Migration Components in One

VPC

The simplest network for database migration is for the source endpoint, the replication instance, and the target endpoint to all be in the same VPC. This configuration is a good one if your source and target endpoints are on an Amazon Relational Database Service (Amazon RDS) DB instance or an Amazon

Elastic Compute Cloud (Amazon EC2) instance.

The following illustration shows a configuration where a database on an Amazon EC2 instance connects to the replication instance and data is migrated to an Amazon RDS DB instance.

The VPC security group used in this configuration must allow ingress on the database port from the replication instance. You can do this by either ensuring that the security group used by the replication instance has ingress to the endpoints, or by explicitly allowing the private IP address of the replication instance.

Configuration with Two VPCs

If your source endpoint and target endpoints are in different VPCs, you can create your replication instance in one of the VPCs and then link the two VPCs by using VPC peering.

A VPC peering connection is a networking connection between two VPCs that enables routing using each VPC’s private IP addresses as if they were in the same network. We recommend this method for connecting VPCs within a region. You can create VPC peering connections between your own VPCs or with a VPC in another AWS account within the same AWS region. For more information about VPC peering, see VPC Peering in the Amazon VPC User Guide.

The following illustration shows a configuration where the source database on an Amazon EC2 instance in a VPC is connected by using VPC peering to a VPC containing the replication instance and the target database on an Amazon RDS DB instance.

The VPC security groups used in this configuration must allow ingress on the database port from the replication instance.

API Version API Version 2016-01-01

10

AWS Database Migration Service User Guide

Network Configurations for Database Migration

Configuration for a Network to a VPC Using AWS Direct Connect or a VPN

Remote networks can connect to a VPC using several options such as AWS Direct Connect or a software or hardware VPN connection. These options are often used to integrate existing on-site services, such as monitoring, authentication, security, data, or other systems, by extending an internal network into the AWS cloud. By using this type of network extension, you can seamlessly connect to AWS-hosted resources such as a VPC.

The following illustration shows a configuration where the source endpoint is an on-premises database in a corporate data center. It is connected by using AWS Direct Connect or a VPN to a VPC that contains the replication instance and a target database on an Amazon RDS DB instance.

In this configuration, the VPC security group must include a routing rule that sends traffic destined for a specific IP address or range to a host that can bridge traffic from the Amazon VPC into the on-premises

VPN. In this case, the NAT host includes its own security group settings that must allow traffic from the replication instance’s private IP address or security group into the NAT instance.

Configuration for a Network to a VPC Using the Internet

If you don't use a VPN or AWS Direct Connect to connect to AWS resources, you can use the Internet to migrate a database to an Amazon EC2 instance or Amazon RDS DB instance. This configuration involves a public replication instance in a VPC with an Internet gateway that contains the target endpoint and the replication instance.

To add an Internet gateway to your VPC, see Attaching an Internet Gateway in the Amazon VPC User

Guide.

The VPC security group must include routing rules that send traffic not destined for the VPC by default to the Internet gateway. In this configuration, the connection to the endpoint will appear to come from the public IP address of the replication instance, not the private IP address.

Configuration with an Amazon RDS DB instance not in a VPC to a DB instance in a VPC Using ClassicLink

You can use ClassicLink, in conjunction with a proxy server, to connect an Amazon RDS DB instance that is not in a VPC to a AWS DMS replication server and DB instance that reside in a VPC. ClassicLink allows you to link an EC2-Classic DB instance to a VPC in your account, within the same region. After you've created the link, the source DB instance can communicate with the replication instance inside the VPC using their private IP addresses. Since the replication instance in the VPC cannot directly access

API Version API Version 2016-01-01

11

AWS Database Migration Service User Guide

Creating a Replication Subnet Group the source DB instance on the EC2-Classic platform using ClassicLink, you must use a proxy server to connect the source DB instance to the VPC containing the replication instance and target DB instance.

The proxy server uses ClassicLink to connect to the VPC, and port forwarding on the proxy server allows communication between the source DB instance and the target DB instance in the VPC.

For step-by-step instructions on creating a ClassicLink for use with AWS DMS, see Using ClassicLink with

AWS Database Migration Service (p. 204) .

Creating a Replication Subnet Group

As part of the network to use for database migration, you need to specify what subnets in your Amazon

Virtual Private Cloud (Amazon VPC) you plan to use. A subnet is a range of IP addresses in your VPC in a given Availability Zone. These subnets can be distributed among the Availability Zones for the region where your VPC is located.

You create a replication instance in a subnet that you select, and you can manage what subnet a source or target endpoint uses by using the AWS DMS console.

You create a replication subnet group to define which subnets will be used. You must specify at least one subnet in two different Availability Zones.

To create a replication subnet group

1. Sign in to the AWS Management Console and choose AWS Database Migration Service. Note that if you are signed in as an AWS Identity and Access Management (IAM) user, you must have the appropriate permissions to access AWS DMS. For more information on the permissions required for

database migration, see IAM Permissions Needed to Use AWS DMS (p. 42)

.

2. In the navigation pane, choose Subnet Groups.

3. Choose Create Subnet Group.

4. On the Edit Replication Subnet Group page, shown following, specify your replication subnet group information. The following table describes the settings.

API Version API Version 2016-01-01

12

AWS Database Migration Service User Guide

Setting an Encryption Key

For This Option

Identifier

Do This

Type a name for the replication subnet group that contains from 8 to 16 printable ASCII characters

(excluding /,", and @). The name should be unique for your account for the region you selected. You can choose to add some intelligence to the name such as including the region and task you are performing, for example

DMSdefault-VPC

.

Type a brief description of the replication subnet group.

Description

VPC

Choose the VPC you want to use for database migration.

Keep in mind that the VPC must have at least one subnet in at least two Availability Zones.

Available Subnets

Choose the subnets you want to include in the replication subnet group. You must select subnets in at least two

Availability Zones.

5. Choose Add to add the subnets to the replication subnet group.

6. Choose Create.

Setting an Encryption Key for AWS Database

Migration Service

AWS DMS encrypts the storage used by a replication instance and the endpoint connection information.

To encrypt the storage used by a replication instance, AWS DMS uses a master key that is unique to your

AWS account. You can view and manage this master key with AWS Key Management Service (AWS KMS).

API Version API Version 2016-01-01

13

AWS Database Migration Service User Guide

Tagging

You can use the default master key in your account ( aws/dms

) or a custom master key that you create. If you have an existing AWS KMS encryption key, you can also use that key for encryption.

You can specify your own encryption key by supplying a KMS key identifier to encrypt your AWS DMS resources. When you specify your own encryption key, the user account used to perform the database migration must have access to that key. For more information on creating your own encryption keys and giving users access to an encryption key, see the

KMS Developer Guide

.

If you don't specify a KMS key identifier, then AWS DMS uses your default encryption key. KMS creates the default encryption key for AWS DMS for your AWS account. Your AWS account has a different default encryption key for each AWS region.

To manage the keys used for encrypting your AWS DMS resources, you use KMS. You can find KMS in the

AWS Management Console by choosing Identity & Access Management on the console home page and then choosing Encryption Keys on the navigation pane. KMS combines secure, highly available hardware and software to provide a key management system scaled for the cloud. Using KMS, you can create encryption keys and define the policies that control how these keys can be used. KMS supports AWS

CloudTrail, so you can audit key usage to verify that keys are being used appropriately. Your KMS keys can be used in combination with AWS DMS and supported AWS services such as Amazon RDS, Amazon

Simple Storage Service (Amazon S3), Amazon Elastic Block Store (Amazon EBS), and Amazon Redshift.

Once you have created your AWS DMS resources with a specific encryption key, you cannot change the encryption key for those resources. Make sure to determine your encryption key requirements before you create your AWS DMS resources.

Tagging AWS Database Migration Service

Resources

You can use AWS Database Migration Service tags to add metadata to your AWS DMS resources. In addition, these tags can be used with IAM policies to manage access to AWS DMS resources and to control what actions can be applied to the AWS DMS resources. Finally, these tags can be used to track costs by grouping expenses for similarly tagged resources.

All AWS DMS resources can be tagged:

• Replication instances

• Endpoints

• Replication tasks

• Certificates

An AWS DMS tag is a name-value pair that you define and associate with an AWS DMS resource. The name is referred to as the key. Supplying a value for the key is optional. You can use tags to assign arbitrary information to an AWS DMS resource. A tag key could be used, for example, to define a category, and the tag value could be a item in that category. For example, you could define a tag key of

“project” and a tag value of “Salix,” indicating that the AWS DMS resource is assigned to the Salix project.

You could also use tags to designate AWS DMS resources as being used for test or production by using a key such as environment=test or environment =production. We recommend that you use a consistent set of tag keys to make it easier to track metadata associated with AWS DMS resources.

Use tags to organize your AWS bill to reflect your own cost structure. To do this, sign up to get your AWS account bill with tag key values included. Then, to see the cost of combined resources, organize your billing information according to resources with the same tag key values. For example, you can tag several

API Version API Version 2016-01-01

14

AWS Database Migration Service User Guide

API resources with a specific application name, and then organize your billing information to see the total cost of that application across several services. For more information, see Cost Allocation and Tagging in

About AWS Billing and Cost Management.

Each AWS DMS resource has a tag set, which contains all the tags that are assigned to that AWS DMS resource. A tag set can contain as many as ten tags, or it can be empty. If you add a tag to an AWS DMS resource that has the same key as an existing tag on resource, the new value overwrites the old value.

AWS does not apply any semantic meaning to your tags; tags are interpreted strictly as character strings.

AWS DMS might set tags on an AWS DMS resource, depending on the settings that you use when you create the resource.

The following list describes the characteristics of an AWS DMS tag.

• The tag key is the required name of the tag. The string value can be from 1 to 128 Unicode characters in length and cannot be prefixed with "aws:" or "dms:". The string might contain only the set of

Unicode letters, digits, white-space, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\

\-]*)$").

• The tag value is an optional string value of the tag. The string value can be from 1 to 256 Unicode characters in length and cannot be prefixed with "aws:" or "dms:". The string might contain only the set of Unicode letters, digits, white-space, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\

\-]*)$").

Values do not have to be unique in a tag set and can be null. For example, you can have a key-value pair in a tag set of project/Trinity and cost-center/Trinity.

You can use the AWS CLI or the AWS DMS API to add, list, and delete tags on AWS DMS resources. When using the AWS CLI or the AWS DMS API, you must provide the Amazon Resource Name (ARN) for the AWS

DMS resource you want to work with. For more information about constructing an ARN, see

Constructing an Amazon Resource Name (ARN) for Use with AWS Database Migration Service (p. 16)

.

Note that tags are cached for authorization purposes. Because of this, additions and updates to tags on

AWS DMS resources might take several minutes before they are available.

API

You can add, list, or remove tags for a AWS DMS resource using the AWS DMS API.

• To add a tag to an AWS DMS resource, use the

AddTagsToResource

operation.

• To list tags that are assigned to an AWS DMS resource, use the

ListTagsForResource

operation.

• To remove tags from an AWS DMS resource, use the

RemoveTagsFromResource

operation.

To learn more about how to construct the required ARN, see Constructing an Amazon Resource Name

(ARN) for Use with AWS Database Migration Service (p. 16) .

When working with XML using the AWS DMS API, tags use the following schema:

<Tagging>

<TagSet>

<Tag>

<Key>Project</Key>

<Value>Trinity</Value>

</Tag>

<Tag>

API Version API Version 2016-01-01

15

AWS Database Migration Service User Guide

Constructing an ARN

<Key>User</Key>

<Value>Jones</Value>

</Tag>

</TagSet>

</Tagging>

The following table provides a list of the allowed XML tags and their characteristics. Note that values for

Key and Value are case dependent. For example, project=Trinity and PROJECT=Trinity are two distinct tags.

Tagging element

TagSet

Tag

Key

Value

Description

A tag set is a container for all tags assigned to an Amazon RDS resource.

There can be only one tag set per resource. You work with a TagSet only through the AWS DMS API.

A tag is a user-defined key-value pair. There can be from 1 to 10 tags in a tag set.

A key is the required name of the tag. The string value can be from 1 to 128

Unicode characters in length and cannot be prefixed with "dms:" or "aws:".

The string might only contain only the set of Unicode letters, digits, whitespace, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-]*)$").

Keys must be unique to a tag set. For example, you cannot have a key-pair in a tag set with the key the same but with different values, such as project/

Trinity and project/Xanadu.

A value is the optional value of the tag. The string value can be from 1 to

256 Unicode characters in length and cannot be prefixed with "dms:" or

"aws:". The string might only contain only the set of Unicode letters, digits, white-space, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\

\-]*)$").

Values do not have to be unique in a tag set and can be null. For example, you can have a key-value pair in a tag set of project/Trinity and cost-center/

Trinity.

Constructing an Amazon Resource Name (ARN) for

Use with AWS Database Migration Service

If you use the AWS CLI or AWS Database Migration Service API to automate your database migration, then you need to know about working with an Amazon Resource Name (ARN). Resources that are created in Amazon Web Services are identified by an ARN, which is a unique identifier. If you use the AWS CLI or

AWS DMS API to set up your database migration, you must supply the ARN of the resource you want to work with.

An ARN for an AWS DMS resource uses the following syntax: arn:aws:dms:

<region>

:

<account number>

:

<resourcetype>

:

<resourcename>

In this syntax:

•

<region>

is the AWS Region ID of the region where the AWS DMS resource was created, such as uswest-2

.

API Version API Version 2016-01-01

16

AWS Database Migration Service User Guide

Constructing an ARN

The following table shows AWS region names and the values you should use when constructing an

ARN.

Region

Asia Pacific (Tokyo) Region

Asia Pacific (Seoul) Region

Asia Pacific (Mumbai) Region

Asia Pacific (Singapore) Region

Asia Pacific (Sydney) Region

Canada (Central) Region

EU (Frankfurt) Region

EU (Ireland) Region

EU (London) Region

Name

ap-northeast-1 ap-northeast-2 ap-south-1 ap-southeast-1 ap-southeast-2 ca-central-1 eu-central-1 eu-west-1 eu-west-2

South America (São Paulo) Region

US East (N. Virginia) Region

US East (Ohio) Region

US West (N. California) Region sa-east-1 us-east-1 us-east-2 us-west-1

US West (Oregon) Region us-west-2

•

<account number>

is your account number with dashes omitted. To find your account number, log in to your AWS account at http://aws.amazon.com, choose My Account/Console, and then choose My

Account.

•

<resourcetype>

is the type of AWS DMS resource.

The following table shows the resource types you should use when constructing an ARN for a particular AWS DMS resource.

AWS DMS Resource

Type

ARN Format

Replication instance

Endpoint arn:aws:dms:<

region

>: <

account

>:rep: <

resourcename

> arn:aws:dms:<

region

>:<

account

>:endpoint: <

resourcename

>

Replication task arn:aws:dms:<

region

>:<

account

>: task:<

resourcename

>

•

<resourcename>

is the resource name assigned to the AWS DMS resource. This is a generated arbitrary string.

The following table shows examples of ARNs for AWS DMS resources with an AWS account of

123456789012, which were created in the US East (N. Virginia) region, and has a resource name :

Resource Type

Replication instance

Sample ARN

arn:aws:dms:us-east-1:123456789012:rep:QLXQZ64MH7CXF4QCQMGRVYVXAI

API Version API Version 2016-01-01

17

Resource Type

Endpoint

Migration task

AWS Database Migration Service User Guide

Supported DDL Statements

Sample ARN

arn:aws:dms:useast-1:123456789012:endpoint:D3HMZ2IGUCGFF3NTAXUXGF6S5A arn:aws:dms:us-east-1:123456789012:task:2PVREMWNPGYJCVU2IBPTOYTIV4

DDL Statements Supported by AWS Database

Migration Service

You can execute data definition language (DDL) statements on the source database during the data migration process. These statements will be replicated to the target database by the replication server.

Supported DDL statements include the following:

• Create table

• Drop table

• Rename table

• Add column

• Drop column

• Rename column

• Change column data type

For information about which DDL statements are supported for a specific source, see the topic describing that source.

LOB Support for Source Databases

For This Option

Include LOB columns in replication

Do This

Large objects, (LOBs) can sometimes be difficult to migrate between systems. AWS DMS offers a number of options to help with the tuning of LOB columns. To see which and when datatypes are considered LOBS by AWS DMS, see the

AWS DMS documentation.

Don't include LOB columns - When you migrate data from one database to another, you might take the opportunity to rethink how your LOBs are stored, especially for heterogeneous migrations. If you want to do so, there’s no need to migrate the LOB data.

Full LOB mode - In full LOB mode AWS DMS migrates all LOBs from source to target regardless of size. In this configuration, AWS DMS has no information about the maximum size of LOBs to expect. Thus, LOBs are migrated one at a time, piece by piece. Full LOB mode can be quite slow.

API Version API Version 2016-01-01

18

For This Option

Max LOB size (K)

LOB chunk size (K)

AWS Database Migration Service User Guide

LOB Support for Source Databases

Do This

Limited LOB mode - In limited LOB mode, you set a maximum size LOB that AWS DMS should accept. Doing so allows AWS DMS to pre-allocate memory and load the LOB data in bulk. LOBs that exceed the maximum LOB size are truncated and a warning is issued to the log file. In

limited

LOB mode you get significant performance gains over full

LOB mode. We recommend that you use limited LOB mode whenever possible.

Note

With Oracle, LOBs are treated as VARCHAR data types whenever possible. This approach means

AWS DMS fetches them from the database in bulk, which is significantly faster than other methods.

The maximum size of a VARCHAR in Oracle is 64K, therefore a limited LOB size of less than 64K is optimal when Oracle is your source database.

When a task is configured to run in limited LOB mode, this option determines the maximum size LOB that AWS DMS accepts. Any LOBs that are larger than this value will be truncated to this value.

When a task is configured to use full LOB mode, AWS DMS retrieves LOBs in pieces. This option determines the size of each piece. When setting this option, pay particular attention to the maximum packet size allowed by your network configuration. If the LOB chunk size exceeds your maximum allowed packet size, you might see disconnect errors.

API Version API Version 2016-01-01

19