Menu
AWS Database Migration Service
User Guide (Version API Version 2016-01-01)

Working with a Replication Instance in AWS Database Migration Service

When you create an AWS DMS replication instance, AWS DMS creates the replication instance 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 your database migration. The replication instance provides high availability 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. This approach provides data redundancy, eliminates I/O freezes, and minimizes latency spikes.


             AWS Database Migration Service replication instance

AWS DMS uses a replication instance to connect to your source data store, read the source data, and format the data for consumption by the target data store. A replication instance also loads the data into the target data store. 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.

You can create an AWS DMS replication instance in the following AWS Regions.

Region Name
Asia Pacific (Tokyo) Region ap-northeast-1
Asia Pacific (Seoul) Region ap-northeast-2
Asia Pacific (Mumbai) Region ap-south-1
Asia Pacific (Singapore) Region ap-southeast-1
Asia Pacific (Sydney) Region ap-southeast-2
Canada (Central) Region ca-central-1
EU (Frankfurt) Region eu-central-1
EU (Ireland) Region eu-west-1
EU (London) Region eu-west-2
South America (São Paulo) Region sa-east-1
US East (N. Virginia) Region us-east-1
US East (Ohio) Region us-east-2
US West (N. California) Region us-west-1
US West (Oregon) Region us-west-2

AWS DMS supports a special AWS Region called AWS GovCloud (US) that is designed to allow US government agencies and customers to move more sensitive workloads into the cloud. AWS GovCloud (US) addresses the US government's specific regulatory and compliance requirements. For more information about AWS GovCloud (US), see What Is AWS GovCloud (US)?

Following, you can find out more details about replication instances.

Selecting the Right AWS DMS Replication Instance for Your Migration

AWS DMS creates the replication instance on an Amazon Elastic Compute Cloud (Amazon EC2) instance. AWS DMS currently supports the T2, C4, and R4 Amazon EC2 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. They also work well 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 for computer-intensive workloads. They achieve significantly higher packet per second (PPS) performance, lower network jitter, and lower network latency. AWS DMS can be CPU-intensive, especially when performing heterogeneous migrations and replications such as migrating from Oracle to PostgreSQL. C4 instances can be a good choice for these situations.

  • The R4 instance classes are memory optimized for memory-intensive workloads. Ongoing migrations or replications of high-throughput transaction systems using DMS can, at times, consume large amounts of CPU and memory. R4 instances include more memory per vCPU.

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 AWS Database Migration Service pricing page.

Replication Instance Type

vCPU

Memory (GB)

General Purpose

dms.t2.micro

1

1

dms.t2.small

1

2

dms.t2.medium

2

4

dms.t2.large

2

8

Compute Optimized

dms.c4.large

2

3.75

dms.c4.xlarge

4

7.5

dms.c4.2xlarge

8

15

dms.c4.4xlarge

16

30

Memory Optimized

dms.r4.large

2

15.25

dms.r4.xlarge

4

30.5

dms.r4.2xlarge

8

61

dms.r4.4xlarge

16

122

dms.r4.8xlarge

32

244

To help you determine which replication instance class would work best for your migration, let’s look at the change data capture (CDC) process that the AWS DMS replication instance uses.

Let’s assume that you’re running a full load plus CDC task (bulk load plus ongoing replication). In this case, the task has its own SQLite repository to store metadata and other information. Before AWS DMS starts a full load, these steps occur:

  • AWS DMS starts capturing changes for the tables it's migrating from the source engine’s transaction log (we call these cached changes). After full load is done, these cached changes are collected and applied on the target. Depending on the volume of cached changes, these changes can directly be applied from memory, where they are collected first, up to a set threshold. Alternatively, they can be applied from disk, where changes are written when they can't be held in memory.

  • After cached changes are applied, by default AWS DMS starts a transactional apply on the target instance.

During the applied cached changes phase and ongoing replications phase, AWS DMS uses two stream buffers, one each for incoming and outgoing data. AWS DMS also uses an important component called a sorter, which is another memory buffer. Following are two important uses of the sorter component (which has others):

  • It tracks all transactions and makes sure that it forwards only relevant transactions to the outgoing buffer.

  • It makes sure that transactions are forwarded in the same commit order as on the source.

As you can see, we have three important memory buffers in this architecture for CDC in AWS DMS. If any of these buffers experience memory pressure, the migration can have performance issues that can potentially cause failures.

When you plug heavy workloads with a high number of transactions per second (TPS) into this architecture, you can find the extra memory provided by R4 instances useful. You can use R4 instances to hold a large number of transactions in memory and prevent memory-pressure issues during ongoing replications.

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 private replication instance has a private IP address that you can't access outside the replication network. A replication instance should have a private IP address when both source and target databases are 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

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.

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. You can have minor version updates applied automatically by choosing the Auto minor version upgrade console option.

AWS DMS Maintenance Window

Every AWS DMS replication instance has a weekly maintenance window during which any available system changes are applied. You can think of the maintenance window as an opportunity to control when modifications and software patching occurs.

If AWS DMS determines that maintenance is required during a given week, the maintenance occurs during the 30-minute maintenance window you chose when you created the replication instance. AWS DMS completes most maintenance during the 30-minute maintenance window. However, a longer time might be required for larger changes.

The 30-minute maintenance window that you selected when you created the replication instance is from an 8-hour block of time allocated for each AWS Region. If you don't specify a preferred maintenance window when you create your replication instance, AWS DMS assigns one on a randomly selected day of the week. For a replication instance that uses a Multi-AZ deployment, a failover might be required for maintenance to be completed.

The following table lists the maintenance window for each AWS Region that supports AWS DMS.

Region Time Block
Asia Pacific (Sydney) Region 12:00–20:00 UTC
Asia Pacific (Tokyo) Region 13:00–21:00 UTC
Asia Pacific (Mumbai) Region 17:30–01:30 UTC
Asia Pacific (Seoul) Region 13:00–21:00 UTC
Asia Pacific (Singapore) Region 14:00–22:00 UTC
Canada (Central) Region 06:29–14:29 UTC
EU (Frankfurt) Region 23:00–07:00 UTC
EU (Ireland) Region 22:00–06:00 UTC
EU (London) Region 06:00–14:00 UTC
South America (São Paulo) Region 00:00–08:00 UTC
US East (N. Virginia) Region 03:00–11:00 UTC
US East (Ohio) Region 03:00–11:00 UTC
US West (N. California) Region 06:00–14:00 UTC
US West (Oregon) Region 06:00–14:00 UTC
AWS GovCloud (US) 06:00–14:00 UTC

Effect of Maintenance on Existing Migration Tasks

When an AWS DMS migration task is running on an instance, the following events occur when a patch is applied:

  • If the tables in the migration task are in the replicating ongoing changes phase (CDC), AWS DMS pauses the task for a moment while the patch is applied. The migration then continues from where it was interrupted when the patch was applied.

  • If AWS DMS is migrating a table when the patch is applied, AWS DMS restarts the migration for the table.

Changing the Maintenance Window Setting

You can change the maintenance window time frame using the AWS Management Console, the AWS CLI, or the AWS DMS API.

Changing the Maintenance Window Setting Using the AWS Console

You can change the maintenance window time frame using the AWS Management Console.

To change the preferred maintenance window using the AWS console

  1. Sign in to the AWS Management Console and choose AWS DMS.

  2. In the navigation pane, choose Replication instances.

  3. Choose the replication instance you want to modify and choose Modify.

  4. Expand the Maintenance section and choose a date and time for your maintenance window.

    
                            modify a replication instance
  5. Choose Apply changes immediately.

  6. Choose Modify.

Changing the Maintenance Window Setting Using the CLI

To adjust the preferred maintenance window, use the AWS CLI modify-replication-instance command with the following parameters.

  • --replication-instance-identifier

  • --preferred-maintenance-window

Example

The following AWS CLI example sets the maintenance window to Tuesdays from 4:00–4:30 a.m. UTC.

aws dms modify-replication-instance \ --replication-instance-identifier myrepinstance \ --preferred-maintenance-window Tue:04:00-Tue:04:30
Changing the Maintenance Window Setting Using the API

To adjust the preferred maintenance window, use the AWS DMS API ModifyReplicationInstance action with the following parameters.

  • ReplicationInstanceIdentifier = myrepinstance

  • PreferredMaintenanceWindow = Tue:04:00-Tue:04:30

Example

The following code example sets the maintenance window to Tuesdays from 4:00–4:30 a.m. UTC.

https://dms.us-west-2.amazonaws.com/ ?Action=ModifyReplicationInstance &DBInstanceIdentifier=myrepinstance &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-09-01 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request &X-Amz-Date=20140425T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3

Working with Replication Engine Versions

The replication engine is the core AWS DMS software that runs on your replication instance and performs the migration tasks you specify. AWS periodically releases new versions of the AWS DMS replication engine software, with new features and performance improvements. Each version of the replication engine software has its own version number, to distinguish it from other versions.

When you launch a new replication instance, it runs the latest AWS DMS engine version unless you specify otherwise. For more information, see Working with a Replication Instance in AWS Database Migration Service.

If you have a replication instance that is currently running, you can upgrade it to a more recent engine version. (AWS DMS doesn't support engine version downgrades.) For more information, including a list of replication engine versions, see the following section.

Deprecating a Replication Instance Version

Occasionally AWS DMS deprecates older versions of the replication instance. Beginning April 2, 2018, AWS DMS will disable creation of any new replication instance version 1.9.0. This version was initially supported in AWS DMS on March 15, 2016, and has since been replaced by subsequent versions containing improvements to functionality, security, and reliability.

Beginning on July 29, 2018, at 0:00 UTC, all DMS replication instances running version 1.9.0 will be scheduled for automatic upgrade to the latest available version during the maintenance window specified for each instance. We recommend that you upgrade your instances before that time, at a time that is convenient for you.

You can initiate an upgrade of your replication instance by using the instructions in the following section, Upgrading the Engine Version of a Replication Instance .

For migration tasks that are running when you choose to upgrade the replication instance, tables in the full load phase at the time of the upgrade are reloaded from the start once the upgrade is complete. Replication for all other tables should resume without interruption once the upgrade is complete. We recommend testing all current migration tasks on the latest available version of AWS DMS replication instance before upgrading the instances from version 1.9.0.

Upgrading the Engine Version of a Replication Instance

AWS periodically releases new versions of the AWS DMS replication engine software, with new features and performance improvements. The following is a summary of available AWS DMS engine versions.

Version Summary
2.4.x
  • Support for replication of Oracle index tablespaces.

  • Support for canned access ACLs to support cross account access with S3 endpoints.

2.3.x
  • Support for S3 as an AWS DMS source.

  • Support for replication of tablespaces for Oracle as an AWS DMS source only.

  • Support for Oracle active data guard standby as a source for Oracle as an AWS DMS source only.

2.2.x
  • Support for Microsoft SQL Server 2016, as either an AWS DMS source or an AWS DMS target.

  • Support for SAP ASE 16, as either an AWS DMS source or an AWS DMS target.

  • Support for Microsoft SQL Server running on Microsoft Azure, as an AWS DMS source only. You can perform a full migration of existing data; however, change data capture (CDC) is not available.

1.9.x Cumulative release of AWS DMS replication engine software.

Upgrading the Engine Version Using the Console

You can upgrade an AWS DMS replication instance using the AWS Management Console.

To upgrade a replication instance using the console

  1. Open the AWS DMS console at https://console.aws.amazon.com/dms/.

  2. In the navigation pane, choose Replication instances.

  3. Choose your replication engine, and then choose Modify.

  4. For Replication engine version, choose the version number you want, and then choose Modify.

Note

Upgrading the replication instance takes several minutes. When the instance is ready, its status changes to available.

Upgrading the Engine Version Using the CLI

You can upgrade an AWS DMS replication instance using the AWS CLI, as follows.

To upgrade a replication instance using the AWS CLI

  1. Determine the Amazon Resource Name (ARN) of your replication instance by using the following command.

    aws dms describe-replication-instances \ --query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"

    In the output, take note of the ARN for the replication instance you want to upgrade, for example: arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY

  2. Determine which replication instance versions are available by using the following command.

    aws dms describe-orderable-replication-instances \ --query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"

    In the output, take note of the engine version number or numbers that are available for your replication instance class. You should see this information in the output from step 1.

  3. Upgrade the replication instance by using the following command.

    aws dms modify-replication-instance \ --replication-instance-arn arn \ --engine-version n.n.n

    Replace arn in the preceding with the actual replication instance ARN from the previous step.

    Replace n.n.n with the engine version number that you want, for example: 2.2.1

Note

Upgrading the replication instance takes several minutes. You can view the replication instance status using the following command.

aws dms describe-replication-instances \ --query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"

When the replication instance is ready, its status changes to available.

Setting Up a Network for a Replication Instance

AWS DMS always creates the replication instance in a VPC based on Amazon Virtual Private Cloud (Amazon VPC). You specify the VPC where your replication instance is located. You can use your default VPC for your account and AWS 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 access control lists (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.

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 RDS DB instance or an 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.


                             AWS Database Migration Service All in one VPC example

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 an AWS 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 an example configuration using VPC peering. Here, the source database on an Amazon EC2 instance in a VPC connects by VPC peering to a VPC. This VPC contains the replication instance and the target database on an Amazon RDS DB instance.


                             AWS Database Migration Service replication instance

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

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.


                             AWS Database Migration Service replication 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. This host must be able to bridge traffic from the 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.


                             AWS Database Migration Service 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 appears to come from the public IP address of the replication instance, not the private IP address.

You can use ClassicLink with a proxy server to connect an Amazon RDS DB instance that is not in a VPC to an 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 AWS 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.

Because the replication instance in the VPC cannot directly access the source DB instance on the EC2-Classic platform using ClassicLink, you must use a proxy server. The proxy server connects 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. Port forwarding on the proxy server allows communication between the source DB instance and the target DB instance in the VPC.


                        AWS Database Migration Service using ClassicLink

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 AWS 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 to use. 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. 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.

  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.

    
                             AWS Database Migration Service replication instance
    For This Option Do This

    Identifier

    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 AWS Region you selected. You can choose to add some intelligence to the name such as including the AWS Region and task you are performing, for example DMS-default-VPC.

    Description

    Type a brief description of the replication subnet group.

    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 a Replication Instance

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). 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 AWS 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, S3, Amazon Elastic Block Store (Amazon EBS), and Amazon Redshift.

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

Creating a Replication Instance

Your first task in migrating a database is to create a replication instance that has sufficient storage and processing power to perform the tasks you assign and migrate data from your source database to the target database. The required size of this instance varies depending on the amount of data you need to migrate and the tasks that you need the instance to perform. For more information about replication instances, see Working with a Replication Instance in AWS Database Migration Service.

The procedure following assumes that you have chosen the AWS DMS console wizard. You can also do this step by selecting Replication instances from the AWS DMS console's navigation pane and then selecting Create replication instance.

To create a replication instance by using the AWS console

  1. On the Create replication instance page, specify your replication instance information. The following table describes the settings.

    
                            Create a replication instance
    For This Option Do This

    Name

    Type a name for the replication instance that contains from 8 to 16 printable ASCII characters (excluding /,", and @). The name should be unique for your account for the AWS Region you selected. You can choose to add some intelligence to the name, such as including the AWS Region and task you are performing, for example west2-mysql2mysql-instance1.

    Description

    Type a brief description of the replication instance.

    Instance class

    Choose an instance class with the configuration you need for your migration. Keep in mind that the instance must have enough storage, network, and processing power to successfully complete your migration. For more information on how to determine which instance class is best for your migration, see Working with a Replication Instance in AWS Database Migration Service.

    Replication engine version

    By default, the replication instance runs the latest version of the AWS DMS replication engine software. We recommend that you accept this default; however, you can choose a previous engine version if necessary.

    VPC

    Choose the Amazon Virtual Private Cloud (Amazon VPC) you want to use. If your source or your target database is in a VPC, choose that VPC. If your source and your target databases are in different VPCs, ensure that they are both in public subnets and are publicly accessible, and then choose the VPC where the replication instance is to be located. The replication instance must be able to access the data in the source VPC. If neither your source nor your target database is in a VPC, select a VPC where the replication instance is to be located.

    Multi-AZ

    Use this optional parameter to create a standby replica of your replication instance in another Availability Zone for failover support. If you intend to use change data capture (CDC) or ongoing replication, you should enable this option.

    Publicly accessible

    Choose this option if you want the replication instance to be accessible from the Internet.

  2. Choose the Advanced tab, shown following, to set values for network and encryption settings if you need them. The following table describes the settings.

    
                            Advanced Tab
    For This Option Do This

    Allocated storage (GB)

    Storage is primarily consumed by log files and cached transactions. For caches transactions, storage is used only when the cached transactions need to be written to disk. Therefore, AWS DMS doesn’t use a significant amount of storage. Some exceptions include the following:

    • Very large tables that incur a significant transaction load. Loading a large table can take some time, so cached transactions are more likely to be written to disk during a large table load.

    • Tasks that are configured to pause before loading cached transactions. In this case, all transactions are cached until the full load completes for all tables. With this configuration, a fair amount of storage might be consumed by cached transactions.

    • Tasks configured with tables being loaded into Amazon Redshift. However, this configuration isn't an issue when Amazon Aurora is the target.

    In most cases, the default allocation of storage is sufficient. However, it’s always a good idea to pay attention to storage-related metrics and scale up your storage if you find you are consuming more than the default allocation.

    Replication Subnet Group

    Choose the replication subnet group in your selected VPC where you want the replication instance to be created. If your source database is in a VPC, choose the subnet group that contains the source database as the location for your replication instance. For more information about replication subnet groups, see Creating a Replication Subnet Group.

    Availability zone

    Choose the Availability Zone where your source database is located.

    VPC Security group(s)

    The replication instance is created in a VPC. If your source database is in a VPC, select the VPC security group that provides access to the DB instance where the database resides.

    KMS master key

    Choose the encryption key to use to encrypt replication storage and connection information. If you choose (Default) aws/dms, the default AWS Key Management Service (AWS KMS) key associated with your account and AWS Region is used. A description and your account number are shown, along with the key's ARN. For more information on using the encryption key, see Setting an Encryption Key and Specifying KMS Permissions.

  3. Specify the Maintenance settings. The following table describes the settings. For more information about maintenance settings, see AWS DMS Maintenance Window.

    
                        Maintenance Tab
    For This Option Do This

    Auto minor version upgrade

    Select to have minor engine upgrades applied automatically to the replication instance during the maintenance window.

    Maintenance window

    Choose a weekly time range during which system maintenance can occur, in Universal Coordinated Time (UTC).

    Default: A 30-minute window selected at random from an 8-hour block of time per AWS Region, occurring on a random day of the week.

  4. Choose Create replication instance.

Modifying a Replication Instance

You can modify the settings for a replication instance to, for example, change the instance class or to increase storage.

When you modify a replication instance, you can apply the changes immediately. To apply changes immediately, you select the Apply changes immediately option in the AWS Management Console, you use the --apply-immediately parameter when calling the AWS CLI, or you set the ApplyImmediately parameter to true when using the AWS DMS API.

If you don't choose to apply changes immediately, the changes are put into the pending modifications queue. During the next maintenance window, any pending changes in the queue are applied.

Note

If you choose to apply changes immediately, any changes in the pending modifications queue are also applied. If any of the pending modifications require downtime, choosing Apply changes immediately can cause unexpected downtime.

To modify a replication instance by using the AWS console

  1. Sign in to the AWS Management Console and select AWS DMS.

  2. In the navigation pane, choose Replication instances.

  3. Choose the replication instance you want to modify. The following table describes the modifications you can make.

    For This Option Do This

    Name

    You can change the name of the replication instance. Type a name for the replication instance that contains from 8 to 16 printable ASCII characters (excluding /,", and @). The name should be unique for your account for the AWS Region you selected. You can choose to add some intelligence to the name, such as including the AWS Region and task you are performing, for example west2-mysql2mysql-instance1.

    Instance class

    You can change the instance class. Choose an instance class with the configuration you need for your migration. Changing the instance class causes the replication instance to reboot. This reboot occurs during the next maintenance window or can occur immediately if you select the Apply changes immediately option.

    For more information on how to determine which instance class is best for your migration, see Working with a Replication Instance in AWS Database Migration Service.

    Replication engine version

    You can upgrade the engine version that is used by the replication instance. Upgrading the replication engine version causes the replication instance to shut down while it is being upgraded.

    Multi-AZ

    You can change this option to create a standby replica of your replication instance in another Availability Zone for failover support or remove this option. If you intend to use change data capture (CDC), ongoing replication, you should enable this option.

    Allocated storage (GB)

    Storage is primarily consumed by log files and cached transactions. For caches transactions, storage is used only when the cached transactions need to be written to disk. Therefore, AWS DMS doesn’t use a significant amount of storage. Some exceptions include the following:

    • Very large tables that incur a significant transaction load. Loading a large table can take some time, so cached transactions are more likely to be written to disk during a large table load.

    • Tasks that are configured to pause before loading cached transactions. In this case, all transactions are cached until the full load completes for all tables. With this configuration, a fair amount of storage might be consumed by cached transactions.

    • Tasks configured with tables being loaded into Amazon Redshift. However, this configuration isn't an issue when Amazon Aurora is the target.

    In most cases, the default allocation of storage is sufficient. However, it’s always a good idea to pay attention to storage related metrics and scale up your storage if you find you are consuming more than the default allocation.

    VPC Security Group(s)

    The replication instance is created in a VPC. If your source database is in a VPC, select the VPC security group that provides access to the DB instance where the database resides.

    Auto minor version upgrade

    Choose this option to have minor engine upgrades applied automatically to the replication instance during the maintenance window or immediately if you select the Apply changes immediately option.

    Maintenance window

    Choose a weekly time range during which system maintenance can occur, in Universal Coordinated Time (UTC).

    Default: A 30-minute window selected at random from an 8-hour block of time per AWS Region, occurring on a random day of the week.

    Apply changes immediately

    Choose this option to apply any modifications you made immediately. Depending on the settings you choose, choosing this option could cause an immediate reboot of the replication instance.

Rebooting a Replication Instance

You can reboot an AWS DMS replication instance to restart the replication engine. A reboot results in a momentary outage for the replication instance, during which the instance status is set to Rebooting. If the AWS DMS instance is configured for Multi-AZ, the reboot can be conducted with a failover. An AWS DMS event is created when the reboot is completed.

If your AWS DMS instance is a Multi-AZ deployment, you can force a failover from one AWS Availability Zone to another when you reboot. When you force a failover of your AWS DMS instance, AWS DMS automatically switches to a standby instance in another Availability Zone. Rebooting with failover is beneficial when you want to simulate a failure of an AWS DMS instance for testing purposes.

If there are migration tasks running on the replication instance when a reboot occurs, no data loss occurs and the task resumes once the reboot is completed. If the tables in the migration task are in the middle of a bulk load (full load phase), DMS restarts the migration for those tables from the beginning. If tables in the migration task are in the ongoing replication phase, the task resumes once the reboot is completed.

You can't reboot your AWS DMS replication instance if its status is not in the Available state. Your AWS DMS instance can be unavailable for several reasons, such as a previously requested modification or a maintenance-window action. The time required to reboot an AWS DMS replication instance is typically small (under 5 minutes).

Rebooting a Replication Instance Using the AWS Console

To reboot a replication instance, use the AWS console.

To reboot a replication instance using the AWS console

  1. Sign in to the AWS Management Console and select AWS DMS.

  2. In the navigation pane, choose Replication instances.

  3. Choose the replication instance you want to reboot.

  4. Choose Reboot.

  5. In the Reboot replication instance dialog box, choose Reboot With Failover? if you have configured your replication instance for Multi-AZ deployment and you want to fail over to another AWS Availability Zone.

  6. Choose Reboot.

Rebooting a Replication Instance Using the CLI

To reboot a replication instance, use the AWS CLI reboot-replication-instance command with the following parameter:

  • --replication-instance-arn

Example Simple Reboot

The following AWS CLI example reboots a replication instance.

aws dms reboot-replication-instance \ --replication-instance-arn arnofmyrepinstance

Example Simple Reboot with Failover

The following AWS CLI example reboots a replication instance with failover.

aws dms reboot-replication-instance \ --replication-instance-arn arnofmyrepinstance \ --force-failover
Rebooting a Replication Instance Using the API

To reboot a replication instance, use the AWS DMS API RebootReplicationInstance action with the following parameters:

  • ReplicationInstanceArn = arnofmyrepinstance

Example Simple Reboot

The following code example reboots a replication instance.

https://dms.us-west-2.amazonaws.com/ ?Action=RebootReplicationInstance &DBInstanceArn=arnofmyrepinstance &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-09-01 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request &X-Amz-Date=20140425T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3

Example Simple Reboot with Failover

The following code example reboots a replication instance and fails over to another AWS Availability Zone.

https://dms.us-west-2.amazonaws.com/ ?Action=RebootReplicationInstance &DBInstanceArn=arnofmyrepinstance &ForceFailover=true &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-09-01 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request &X-Amz-Date=20140425T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3

Deleting a Replication Instance

You can delete an AWS DMS replication instance when you are finished using it. If you have migration tasks that use the replication instance, you must stop and delete the tasks before deleting the replication instance.

If you close your AWS account, all AWS DMS resources and configurations associated with your account are deleted after two days. These resources include all replication instances, source and target endpoint configuration, replication tasks, and SSL certificates. If after two days you decide to use AWS DMS again, you recreate the resources you need.

Deleting a Replication Instance Using the AWS Console

To delete a replication instance, use the AWS console.

To delete a replication instance using the AWS console

  1. Sign in to the AWS Management Console and select AWS DMS.

  2. In the navigation pane, choose Replication instances.

  3. Choose the replication instance you want to delete.

  4. Choose Delete.

  5. In the dialog box, choose Delete.

Deleting a Replication Instance Using the CLI

To delete a replication instance, use the AWS CLI delete-replication-instance command with the following parameter:

  • --replication-instance-arn

Example Delete

The following AWS CLI example deletes a replication instance.

aws dms delete-replication-instance \ --replication-instance-arn <arnofmyrepinstance>
Deleting a Replication Instance Using the API

To delete a replication instance, use the AWS DMS API DeleteReplicationInstance action with the following parameters:

  • ReplicationInstanceArn = <arnofmyrepinstance>

Example Delete

The following code example deletes a replication instance.

https://dms.us-west-2.amazonaws.com/ ?Action=DeleteReplicationInstance &DBInstanceArn=arnofmyrepinstance &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-09-01 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request &X-Amz-Date=20140425T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3

DDL Statements Supported by AWS DMS

You can execute data definition language (DDL) statements on the source database during the data migration process. These statements are 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.