# Working with an AWS DMS replication instance
When you create an AWS DMS replication instance, AWS DMS creates it on an Amazon EC2 instance in a virtual private cloud (VPC) based on the Amazon VPC service. You use this replication instance to perform your database migration. By using a replication instance, you can get high availability and failover support with a Multi-AZ deployment when you choose 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\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-conceptual2.png)
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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS supports a special AWS Region called AWS GovCloud (US) that is designed to allow US government agencies and customers to move 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)?](http://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
Following, you can find out more details about replication instances.
**Topics**
+ [
# Choosing the right AWS DMS replication instance for your migration
](CHAP_ReplicationInstance.Types.md)
+ [
# Selecting the best size for a replication instance
](CHAP_BestPractices.SizingReplicationInstance.md)
+ [
# Working with replication engine versions
](CHAP_ReplicationInstance.EngineVersions.md)
+ [
# Public and private replication instances
](CHAP_ReplicationInstance.PublicPrivate.md)
+ [
# IP addressing and network types
](CHAP_ReplicationInstance.IPAddressing.md)
+ [
# Setting up a network for a replication instance
](CHAP_ReplicationInstance.VPC.md)
+ [
# Setting an encryption key for a replication instance
](CHAP_ReplicationInstance.EncryptionKey.md)
+ [
# Creating a replication instance
](CHAP_ReplicationInstance.Creating.md)
+ [
# Modifying a replication instance
](CHAP_ReplicationInstance.Modifying.md)
+ [
# Rebooting a replication instance
](CHAP_ReplicationInstance.Rebooting.md)
+ [
# Deleting a replication instance
](CHAP_ReplicationInstance.Deleting.md)
+ [
# Working with the AWS DMS maintenance window
](CHAP_ReplicationInstance.MaintenanceWindow.md)
# Choosing the right AWS DMS replication instance for your migration
AWS DMS creates the replication instance on an Amazon EC2 instance. AWS DMS currently supports the T3, C5, C6i, R5, and R6i Amazon EC2 instance classes for replication instances:
+ T3 instances are the next-generation burstable general-purpose instance type. This type provides a baseline level of CPU performance with the ability to burst CPU usage at any time for as long as required. T3 instances offer a balance of compute, memory, and network resources and are designed for applications with moderate CPU usage that experience temporary spikes in use. T3 instances accumulate CPU credits when a workload is operating below baseline threshold. Each earned CPU credit provides the T3 instance the opportunity to burst with the performance of a full CPU core for one minute when needed.
T3 instances can burst at any time for as long as required in `unlimited` mode. For more information on `unlimited` mode, see [Working with unlimited mode for burstable performance instances](#CHAP_ReplicationInstance.Types.UnlimitedMode).
+ C5 instances are the next-generation instance type to deliver cost-effective high performance at a low price per compute ratio for running advanced compute-intensive workloads. This includes workloads such as high-performance web servers, high-performance computing (HPC), batch processing, ad serving, highly scalable multiplayer gaming, and video encoding. Other workloads C5 instances are suited to include scientific modeling, distributed analytics, and machine and deep learning inference. The C5 instances are available with a choice of processors from Intel and AMD.
+ C6i instances offer up to 15% better compute price performance over comparable Gen5 instances for a wide variety of workloads, and always-on memory encryption. C6i instances are an ideal fit for compute-intensive workloads such as batch processing, distributed analytics, high performance computing (HPC), ad serving, highly scalable multiplayer gaming, and video encoding.
+ R5 instances are the next generation of memory-optimized instance types for Amazon EC2. R5 instances are well-suited for memory-intensive applications such as high performance databases, distributed web scale in-memory caches, midsize in-memory databases, real time big data analytics, and other enterprise applications. Ongoing migrations or replications of high-throughput transaction systems using AWS DMS can also consume large amounts of CPU and memory.
+ R6i instances offer up to 15% better compute price performance over comparable Gen5 instances for a wide variety of workloads, and always-on memory encryption. R6i instances are SAP Certified and are ideal for workloads such as SQL and noSQL databases, distributed web scale in-memory caches like Memcached and Redis OSS, in-memory databases like SAP HANA, and real time big data analytics like Hadoop and Spark clusters.
+ C7i instances offer better compute performance over comparable previous generation instances. For AWS DMS workloads, C7i instances excel at accelerating data transformation processes, handling compute-heavy schema conversions, and maintaining consistent throughput during high-volume migration tasks. These instances provide an ideal balance of compute performance that require sustained CPU performance.
+ R7i instances offer better compute performance over comparable previous generation instances, combined with high memory capacity for memory-intensive workloads. For AWS DMS workloads, R7i instances are particularly well-suited for tasks involving large databases that process high volumes of concurrent database transactions, enabling efficient handling of memory-intensive replication scenarios and complex data validation processes that require substantial memory buffers.
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 service pricing page](https://aws.amazon.com/dms/pricing/).
**General Purpose Replication Instance Types**
| Type | vCPU | Memory (GiB) |
| --- | --- | --- |
| dms.t3.micro | 2 | 1 |
| dms.t3.small | 2 | 2 |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**Compute Optimized Replication Instance Types**
| Type | vCPU | Memory (GiB) |
| --- | --- | --- |
| dms.c5.large | 2 | 4 |
| dms.c5.xlarge | 4 | 8 |
| dms.c5.2xlarge | 8 | 16 |
| dms.c5.4xlarge | 16 | 32 |
| dms.c5.9xlarge | 36 | 72 |
| dms.c5.12xlarge | 48 | 96 |
| dms.c5.18xlarge | 72 | 144 |
| dms.c5.24xlarge | 96 | 192 |
| dms.c6i.large | 2 | 4 |
| dms.c6i.xlarge | 4 | 8 |
| dms.c6i.2xlarge | 8 | 16 |
| dms.c6i.4xlarge | 16 | 32 |
| dms.c6i.8xlarge | 32 | 64 |
| dms.c6i.12xlarge | 48 | 96 |
| dms.c6i.16xlarge | 64 | 128 |
| dms.c6i.24xlarge | 96 | 192 |
| dms.c6i.32xlarge | 128 | 256 |
| dms.c7i.large | 2 | 4 |
| dms.c7i.xlarge | 4 | 8 |
| dms.x7i.2xlarge | 8 | 16 |
| dms.x7i.4xlarge | 16 | 32 |
| dms.x7i.8xlarge | 32 | 64 |
| dms.x7i.12xlarge | 48 | 96 |
| dms.x7i.16xlarge | 64 | 128 |
| dms.x7i.24xlarge | 96 | 192 |
| dms.x7i.48xlarge | 192 | 384 |
**Memory Optimized Replication Instance Types**
| Type | vCPU | Memory (GiB) |
| --- | --- | --- |
| dms.r5.large | 2 | 16 |
| dms.r5.xlarge | 4 | 32 |
| dms.r5.2xlarge | 8 | 64 |
| dms.r5.4xlarge | 16 | 128 |
| dms.r5.8xlarge | 32 | 256 |
| dms.r5.12xlarge | 48 | 384 |
| dms.r5.16xlarge | 64 | 512 |
| dms.r5.24xlarge | 96 | 768 |
| dms.r6i.large | 2 | 16 |
| dms.r6i.xlarge | 4 | 32 |
| dms.r6i.2xlarge | 8 | 64 |
| dms.r6i.4xlarge | 16 | 128 |
| dms.r6i.8xlarge | 32 | 256 |
| dms.r6i.12xlarge | 48 | 384 |
| dms.r6i.16xlarge | 64 | 512 |
| dms.r6i.24xlarge | 96 | 768 |
| dms.r6i.32xlarge | 128 | 1024 |
| dms.r7i.large | 2 | 16 |
| dms.r7i.xlarge | 4 | 32 |
| dms.r7i.2xlarge | 8 | 64 |
| dms.r7i.4xlarge | 16 | 128 |
| dms.r7i.8xlarge | 32 | 256 |
| dms.r7i.12xlarge | 48 | 384 |
| dms.r7i.16xlarge | 64 | 512 |
| dms.r7i.24xlarge | 96 | 768 |
| dms.r7i.48xlarge | 192 | 1536 |
The tables above list all of the AWS DMS replication instance types, but the types that are available in your region might vary. To see the replication instance types available in your region, you can run the following [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html) command:
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [
## Deciding what instance class to use
](#CHAP_ReplicationInstance.Types.Deciding)
+ [
## Working with unlimited mode for burstable performance instances
](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## Deciding what instance class to use
To help determine which replication instance class might work best for you, let's look at the change data capture (CDC) process that AWS DMS 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. Or 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 process 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 R5 and R6i instances useful. You can use R5 and R6i instances to hold a large number of transactions in memory and prevent memory-pressure issues during ongoing replications.
## Working with unlimited mode for burstable performance instances
A burstable performance instance configured as `unlimited`, such as a T3 instance, can sustain high CPU utilization for any period of time whenever required. The hourly instance price can automatically cover all CPU usage spikes. It does so if the average CPU utilization of the instance is at or below the baseline over a rolling 24-hour period or the instance lifetime, whichever is shorter.
For the vast majority of general-purpose workloads, instances configured as `unlimited` give enough performance without any additional charges. If the instance runs at higher CPU utilization for a prolonged period, it can do so for a flat additional rate per vCPU-hour. For information about T3 instance pricing, see "T3 CPU Credits" in [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
For more information on `unlimited` mode for T3 instances, see [Unlimited mode for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) in the *Amazon EC2 User Guide*.
**Important**
If you use a `dms.t3.micro` instance under the [AWS Free Tier](https://aws.amazon.com/free/) offer and use it in `unlimited` mode, charges might apply. In particular, charges might apply if your average utilization over a rolling 24-hour period exceeds the baseline utilization of the instance. For more information, see [Baseline utilization](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) in the *Amazon EC2 User Guide*.
T3 instances launch as `unlimited` by default. If the average CPU usage over a 24-hour period exceeds the baseline, you incur charges for surplus credits. In some cases, you might launch T3 Spot Instances as `unlimited` and plan to use them immediately and for a short duration. If you do so with no idle time for accruing CPU credits, you incur charges for surplus credits. We recommend that you launch your T3 Spot Instances in standard mode to avoid paying higher costs. For more information, see [Surplus credits can incur charges](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits), [T3 Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances), and [Standard mode for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) in the *Amazon EC2 User Guide*.
# Selecting the best size for a replication instance
Choosing the appropriate replication instance depends on several factors of your use case. To help understand how replication instance resources are used, see the following discussion. It covers the common scenario of a full load \$1 CDC task.
During a full load task, AWS DMS loads tables individually. By default, eight tables are loaded at a time. AWS DMS captures ongoing changes to the source during a full load task so the changes can be applied later on the target endpoint. The changes are cached in memory; if available memory is exhausted, changes are cached to disk. When a full load task completes for a table, AWS DMS immediately applies the cached changes to the target table.
After all outstanding cached changes for a table have been applied, the target endpoint is in a transactionally consistent state. At this point, the target is in-sync with the source endpoint with respect to the last cached changes. AWS DMS then begins ongoing replication between the source and target. To do so, AWS DMS takes change operations from the source transaction logs and applies them to the target in a transactionally consistent manner. (This process assumes batch optimized apply isn't selected). AWS DMS streams ongoing changes through memory on the replication instance, if possible. Otherwise, AWS DMS writes changes to disk on the replication instance until they can be applied on the target.
You have some control over how the replication instance handles change processing, and how memory is used in that process. For more information on how to tune change processing, see [Change processing tuning settings](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
## Factors to consider
Memory and disk space are key factors in selecting an appropriate replication instance for your use case. Following, you can find a discussion of the use case characteristics to analyze to choose a replication instance.
+ Database and table size
Data volume helps determine the task configuration to optimize full load performance. For example, for two 1 TB schemas, you can partition tables into four tasks of 500 GB and run them in parallel. The possible parallelism depends on the CPU resource available in the replication instance. That's why it's a good idea understand the size of your database and tables to optimize full load performance. It helps determine the number of tasks that you can possibly have.
+ Large objects
The data types that are present in your migration scope can affect performance. Particularly, large objects (LOBs) impact performance and memory consumption. To migrate a LOB value, AWS DMS performs a two-step process. First, AWS DMS inserts the row into the target without the LOB value. Second, AWS DMS updates the row with the LOB value. This has an impact on the memory, so it's important to identify LOB columns in the source and analyze their size.
+ Load frequency and transaction size
Load frequency and transactions per second (TPS) influence memory usage. A high number of TPS or data manipulation language (DML) activities leads to high usage of memory. This happens because DMS caches the changes until they are applied to the target. During CDC, this leads to swapping (writing to the physical disk due to memory overflow), which causes latency.
+ Table keys and referential integrity
Information about the keys of the table determines the CDC mode (batch apply or transactional apply) that you use to migrate data. In general, transactional apply is slower than batch apply. For long-running transactions, there can be many changes to migrate. When you use transactional apply, AWS DMS might require more memory to store the changes compared to batch apply. If you migrate tables without primary keys, batch apply will fail and the DMS task moves to transactional apply mode. When referential integrity is active between tables during CDC, AWS DMS uses transactional apply by default. For more information about batch apply compared to transactional apply, see [How can I use the DMS batch apply feature to improve CDC replication performance? ](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/).
Use these metrics to determine if you need the replication instance to be compute optimized or memory optimized.
## Common issues
You might face the following common issues that cause resource contention on the replication instance during migration. For information on the replication instance metrics, see [Replication instance metrics](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch).
+ If the memory in a replication instance becomes insufficient, this results in writing data to the disk. Reading from the disk can cause latency, which you can avoid by sizing the replication instance with enough memory.
+ The disk size assigned to the replication instance can be smaller than required. The disk size is used when data in memory spills over; it's also used to store the task logs. The maximum IOPS depends on it too.
+ Running multiple tasks or tasks with high parallelism affects CPU consumption of the replication instance. This slows down the processing of the tasks and results in latency.
## Best practices
Consider these two most common best practices when sizing a replication instance. For more information, see [Best practices for AWS Database Migration Service](CHAP_BestPractices.md).
1. Size your workload and understand if it's computer-intensive or memory-intensive. Based on this, you can determine the class and size of the replication instance:
+ AWS DMS processes LOBs in memory. This operation requires a fair amount of memory.
+ The number of tasks and the number of threads impact CPU consumption. Avoid using more than eight `MaxFullLoadSubTasks` during the full load operation.
1. Increase the disk space assigned to the replication instance when you have a high workload during full load. Doing this lets the replication instance use the maximum IOPS assigned to it.
The preceding guidelines don't cover all possible scenarios. It's important to consider the specifics of your particular use case when you determine the size of your replication instance.
The preceding tests show CPU and memory vary with different workloads. Particularly, LOBs affect memory, and task count or parallelism affect the CPU. After your migration is running, monitor the CPU, freeable memory, free storage, and IOPS of your replication instance. Based on the data you gather, you can size your replication instance up or down as needed.
# 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 an AWS DMS replication instance](CHAP_ReplicationInstance.md).
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 about replication engine versions, see [AWS DMS release notes](CHAP_ReleaseNotes.md).
## 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/v2/](https://console.aws.amazon.com/dms/v2/).
1. In the navigation pane, choose **Replication instances**.
1. Choose your replication engine, and then choose **Modify**.
1. For **Engine version**, choose the version number you want, and then choose **Modify**.
**Note**
We recommend that you stop all tasks before upgrading the Replication Instance. If you don't stop the task, AWS DMS will stop the task automatically before the upgrade. If you stop the task manually, you will need to start the task manually after the upgrade is complete. Upgrading the replication instance takes several minutes. When the instance is ready, its status changes to **available**.
## Upgrading the engine version using the AWS 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`
1. 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, note 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.
1. 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: `3.4.5`
**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**.
# Public and private replication instances
You can specify if 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. You use a private instance when both source and target databases are in the same network that is connected to the virtual private cloud (VPC) of the replication instance. The network can be connected to the VPC by using a virtual private network (VPN), Direct Connect, or VPC peering.
A *VPC peering* connection is a networking connection between two VPCs. It allows 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](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) in the *Amazon VPC User Guide*.
A *public replication instance* can use the VPC security group of the replication instance, and the replication instance's public IP address or the NAT gateway's public IP address. These connections form a network that you use for data migration.
# IP addressing and network types
AWS DMS always creates your replication instance in an Amazon Virtual Private Cloud (VPC). When you create your VPC, you can determine the IP addressing to use: either IPv4 or IPv6, or both. Then, when you create or modify a replication instance, you can specify use of an IPv4 address protocol or an IPv6 address protocol using *dual-stack mode*.
**IPv4 addresses**
When you create a VPC, you can specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block, such as 10.0.0.0/16. A subnet group defines the range of IP addresses in this CIDR block. These IP addresses can be private or public.
A private IPv4 address is an IP address that's not reachable over the internet. You can use private IPv4 addresses for communication between your replication instance and other resources, such as Amazon EC2 instances, in the same VPC. Each replication instance has a private IP address for communication in the VPC.
A public IP address is an IPv4 address that is reachable from the internet. You can use public addresses for communication between your replication instance and resources on the internet. You control whether your replication instance receives a public IP address.
**Dual-stack mode and IPv6 addresses**
When you have resources that must communicate with your replication instance over IPv6, use *dual-stack mode*. To use dual-stack mode, make sure that each subnet in the subnet group that you associate with the replication instance has an IPv6 CIDR block associated with it. You can create a new replication subnet group or modify an existing replication subnet group to meet this requirement. Each IPv6 address is globally unique. The IPv6 CIDR block for your VPC is automatically assigned from the Amazon pool of IPv6 addresses. You can't choose the range yourself.
DMS disables Internet Gateway access for IPv6 endpoints of private dual-stack mode replication instances. DMS does this to ensure that your IPv6 endpoints are private and can only be accessed from within your VPC.
You can use the AWS DMS Console to create or modify a replication instance, and specify dual-stack mode in the **Network type** section. The following image shows the **Network type** section in the console.
![\[AWS Database Migration Service Network Type\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-network-type.png)
**References**
+ For mode information about IPv4 and IPv6 addresses, see [IP Addressing](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) in the *Amazon VPC User Guide*.
+ For more information about creating a replication instance using dual-stack mode, see [Creating a replication instance](CHAP_ReplicationInstance.Creating.md).
+ For mode information about modifying a replication instance, see [Modifying a replication instance](CHAP_ReplicationInstance.Modifying.md).
# Setting up a network for a replication instance
AWS DMS always creates the replication instance in a VPC based on 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.
Make sure that the elastic network interface allocated for your replication instance's VPC is associated with a security group. Also, make sure this security group's rules let all traffic on all ports leave (egress) the VPC. This approach allows communication from the replication instance to your source and target database endpoints, if correct ingress 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. How you set this up depends on the network configuration that you use. 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.
**Note**
Since an IP address can change as a result of changes to underlying infrastructure, we recommend you use a VPC CIDR range, or route your replication instance outbound traffic through a NAT GW associated Elastic IP. For more information about creating a VPC, including a CIDR block, see [Work with VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) in the *Amazon Virtual Private Cloud User Guide*. For more information about Elastic IP addresses, see [Elastic IP addresses](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html) in the *Amazon Elastic Compute Cloud User Guide*.
## 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
](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [
### Configuration with multiple VPCs
](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [
### Configuration with shared VPCs
](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [
### Configuration for a network to a VPC using Direct Connect or a VPN
](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [
### Configuration for a network to a VPC using the internet
](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [
### Configuration with an RDS DB instance not in a VPC to a DB instance in a VPC using ClassicLink
](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [
### Configuration for a network connecting to AWS services
](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [
### Configuration for a network connecting to AWS services using VPC endpoints
](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [
### Configuration for a network connecting to AWS services using the internet
](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
When practical, we recommend that you create a DMS replication instance in the same Region as your target endpoint, and in the same VPC or subnet as your target endpoint.
### 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\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
The VPC security group used in this configuration must allow ingress on the database port from the replication instance. You can do this in a couple of ways. You can ensure that the security group used by the replication instance has ingress to the endpoints. Or you can allow the VPC CIDR range, NAT GW Elastic IP, or private IP address of the replication instance if you are using one. But we do not recommend you use the private IP address of the replication instance, because it can break your replication if the replication IP address changes.
### Configuration with multiple VPCs
If your source endpoint and target endpoints are in different VPCs, you can create your replication instance in one of the VPCs. You can 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. You can create a VPC peering connection between your own VPCs, with a VPC in another AWS account, or with a VPC in a different AWS Region. For more information about VPC peering, see [VPC peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) 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\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
To implement VPC peering, follow the instructions in [Work with VPC peering connections](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html) located in the *Amazon Virtual Private Cloud, VPC Peering* documentation. Be sure the route table of one VPC contains the CIDR block of the other. For example, if VPC A is using destination 10.0.0.0/16 and VPC B is using destination172.31.0.0, the route table of VPC A should contain 172.31.0.0, and route table of VPC B must contain 10.0.0.0/16. For more detailed information, see [Update your route tables for VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) in the *Amazon Virtual Private Cloud, VPC Peering* documentation.
The VPC security groups used in this configuration must allow ingress on the database port from the replication instance, or it should allow ingress on the CIDR block for the VPC being peered.
### Configuration with shared VPCs
AWS DMS treats subnets that are shared to a participating customer account in an organization just like regular subnets in the same account. Below is a description of how AWS DMS handles VPCs, subnets, and how you can use shared VPCs.
You can configure your network configuration to operate in custom subnets or VPCs by creating `ReplicationSubnetGroup` objects. When you create a `ReplicationSubnetGroup`, you can choose to specify subnets from a particular VPC in your account. The list of subnets you specify must include at least two subnets that are in separate availability zones, and all subnets must be in the same VPC. When creating a `ReplicationSubnetGroup`, customers only specify subnets. AWS DMS will determine the VPC on your behalf, as each subnet is linked to exactly one VPC.
When you create an AWS DMS `ReplicationInstance` or a AWS DMS `ReplicationConfig`, you can choose to specify a `ReplicationSubnetGroup` and/or a VPC Security Group in which the `ReplicationInstance` or Serverless Replication operates. If not specified, AWS DMS chooses the customer default `ReplicationSubnetGroup` (which AWS DMS creates on your behalf if not specified for all subnets in the default VPC) and the default VPC Security Group.
You can choose to run your migrations in an availability zone that you specify, or in any of the availability zones in your `ReplicationSubnetGroup`. When AWS DMS attempts to create a Replication Instance or start a Serverless Replication, it translates the availability zones of your subnets into availability zones in the core service account, to ensure that we launch instances in the correct Availability Zone even if Availability Zone mappings aren’t identical between the two accounts.
If you use a shared VPC, you will need to ensure you create `ReplicationSubnetGroup` objects that map to the subnets you wish to use from a shared VPC. When you create a `ReplicationInstance` or a `ReplicationConfig`, you must specify a `ReplicationSubnetGroup` for the shared VPC, and specify a VPC security group that you created for your shared VPC with your Create request.
Note the following about using a shared VPC:
+ The VPC owner can't share a resource with a participant, but the participant can create a service resource in the owner's subnet.
+ The VPC owner can't access a resource (such as a replication instance) that the participant creates, because all resources are account-specific. However, as long as you create the replication instance in the shared VPC, it can access the resources in the VPC regardless of the owning account, as long as the replication endpoint or task had the correct permissions.
+ Since resources are account-specific, other participants can't access resources owned by other accounts. There are no permissions that you can give other accounts to let them access resources created in the shared VPC with your account.
### Configuration for a network to a VPC using 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 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\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-scenarioDirect.png)
In this configuration, the VPC security group must include a routing rule that sends traffic destined for a VPC CIDR range or specific IP address 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. These settings must allow traffic from the replication instance's VPC CIDR range, or private IP address, or security group into the NAT instance. But we do not recommend you use the private IP address of the replication instance, because it can break your replication if the replication IP address changes.
### Configuration for a network to a VPC using the internet
If you don't use a VPN or Direct Connect to connect to AWS resources, you can use the internet to migrate your database. In this case, you can migrate to either an Amazon EC2 instance or an 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\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-scenarioInternet.png)
To add an internet gateway to your VPC, see [Attaching an internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) in the *Amazon VPC User Guide*.
The VPC route table 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. For more information, see [VPC Route Tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) in the *Amazon VPC User Guide*.
### Configuration with an RDS DB instance not in a VPC to a DB instance in a VPC using ClassicLink
| |
| --- |
| We are retiring EC2-Classic on August 15, 2022. We recommend that you migrate from EC2-Classic to a VPC. For more information, see [Migrate from EC2-Classic to a VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) in the Amazon EC2 User Guide and the blog [ EC2-Classic Networking is Retiring – Here’s How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/). |
To connect an Amazon RDS DB instance not in a VPC to a DMS replication server and DB instance in a VPC, you can use ClassicLink with a proxy server.
ClassicLink enables 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 can't directly access the source DB instance on the EC2-Classic platform using ClassicLink, you 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\]](http://docs.aws.amazon.com/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### Using ClassicLink with AWS Database Migration Service
You can connect an Amazon RDS DB instance that is not in a VPC to an AWS DMS replication server and DB instance that are in a VPC. To do so, you can use Amazon EC2 ClassicLink with a proxy server.
The following procedure shows how to use ClassicLink for this purpose. This procedure connects an Amazon RDS source DB instance that is not in a VPC to a VPC containing an AWS DMS replication instance and a target DB instance.
+ Create an AWS DMS replication instance in a VPC. (All replication instances are created in VPCs.)
+ Associate a VPC security group to the replication instance and the target DB instance. When two instances share a VPC security group, they can communicate with each other by default.
+ Set up a proxy server on an EC2 Classic instance.
+ Create a connection using ClassicLink between the proxy server and the VPC.
+ Create AWS DMS endpoints for the source and target databases.
+ Create an AWS DMS task.
**To use ClassicLink to migrate a database on a DB instance not in a VPC to a database on a DB instance in a VPC**
1. Create an AWS DMS replication instance and assign a VPC security group:
1. Sign in to the AWS Management Console and open the AWS DMS console at [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
If you're signed in as an AWS Identity and Access Management (IAM) user, make sure that you have the appropriate permissions to access AWS DMS. For more information about the permissions required for database migration, see [IAM permissions needed to use AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. On the **Dashboard** page, choose **Replication Instance**. Follow the instructions at [Step 1: Create a replication instance using the AWS DMS console](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance) to create a replication instance.
1. After you have created the AWS DMS replication instance, open the EC2 service console. C **Network Interfaces** from the navigation pane.
1. Choose the *DMSNetworkInterface*, and then choose **Change Security Groups** from the **Actions** menu.
1. Choose the security group you want to use for the replication instance and the target DB instance.
1. Associate the security group from the last step with the target DB instance:
1. Open the Amazon RDS service console. Choose **Instances** from the navigation pane.
1. Choose the target DB instance. For **Instance Actions**, choose **Modify**.
1. For the **Security Group** parameter, choose the security group you used in the previous step.
1. Choose **Continue**, and then **Modify DB Instance**.
1. Step 3: Set up a proxy server on an EC2 Classic instance using NGINX. Use an AMI of your choice to launch an EC2 Classic instance. The example below is based on the AMI Ubuntu Server 14.04 LTS (HVM).
To set up a proxy server on an EC2 Classic instance
1. Connect to the EC2 Classic instance and install NGINX using the following commands:
```
Prompt> sudo apt-get update
Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz
Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz
Prompt> cd nginx-1.9.12
Prompt> sudo apt-get install build-essential
Prompt> sudo apt-get install libpcre3 libpcre3-dev
Prompt> sudo apt-get install zlib1g-dev
Prompt> sudo ./configure --with-stream
Prompt> sudo make
Prompt> sudo make install
```
1. Edit the NGINX daemon file, `/etc/init/nginx.conf`, using the following code:
```
# /etc/init/nginx.conf – Upstart file
description "nginx http daemon"
author "email"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
env DAEMON=/usr/local/nginx/sbin/nginx
env PID=/usr/local/nginx/logs/nginx.pid
expect fork
respawn
respawn limit 10 5
pre-start script
$DAEMON -t
if [ $? -ne 0 ]
then exit $?
fi
end script
exec $DAEMON
```
1. Create an NGINX configuration file at `/usr/local/nginx/conf/nginx.conf`. In the configuration file, add the following:
```
# /usr/local/nginx/conf/nginx.conf - NGINX configuration file
worker_processes 1;
events {
worker_connections 1024;
}
stream {
server {
listen DB instance port number;
proxy_pass DB instance identifier:DB instance port number;
}
}
```
1. From the command line, start NGINX using the following commands:
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. Create a ClassicLink connection between the proxy server and the target VPC that contains the target DB instance and the replication instance:
1. Open the EC2 console and choose the EC2 Classic instance that is running the proxy server.
1. For **Actions**, choose **ClassicLink**, then choose **Link to VPC**.
1. Choose the security group that you used earlier in this procedure.
1. Choose **Link to VPC**.
1. Step 5: Create AWS DMS endpoints using the procedure at [Step 2: Specify source and target endpoints](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints). Make sure to use the internal EC2 DNS hostname of the proxy as the server name when specifying the source endpoint.
1. Create an AWS DMS task using the procedure in [Step 3: Create a task and migrate data](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks).
### Configuration for a network connecting to AWS services
To connect with AWS services, use either an internet connection or Virtual Private Cloud (VPC) endpoints. This applies when:
Your source or target endpoints use AWS services like:
+ AWS Secrets Manager
+ Amazon Simple Storage Service
Your target endpoint is an AWS service such as:
+ Amazon S3
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ Amazon OpenSearch Service
+ Amazon Athena
### Configuration for a network connecting to AWS services using VPC endpoints
VPC endpoints provide secure connections between your AWS resources, connecting VPC resources to AWS services without requiring internet access. Your applications in private subnets can access AWS services while staying within the AWS network, improving security and reducing latency. Please refer to the image below:
![\[\]](http://docs.aws.amazon.com/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
For more information, see [Configuring VPC endpoints as AWS DMS source and target endpoints](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) and [Configuring AWS DMS secrets manager VPC Endpoint](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html).
### Configuration for a network connecting to AWS services using the internet
A replication instance needs internet access to connect with AWS resources during data migration.
For more information regarding private and public subnets within a VPC, see [Example: VPC with servers in private subnets and NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) in the *Amazon Virtual Private Cloud User Guide*. You must ensure to test your network configuration for connectivity with any required service.
## Creating a replication subnet group
As part of the network to use for database migration, you need to specify which subnets in your virtual private cloud (VPC) that you plan to use. This VPC must be based on the Amazon VPC service. 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.
When you create a replication instance or an instance profile in the AWS DMS console, you can use the subnet that you choose.
You create a replication subnet group to define which subnets to use. You must specify subnets in at least two Availability Zones.
**To create a replication subnet group**
1. Sign in to the AWS Management Console and open the AWS DMS console at [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
If you're signed in as an IAM user, make sure that you have the appropriate permissions to access AWS DMS. For more information about the permissions required for database migration, see [IAM permissions needed to use AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. In the navigation pane, choose **Subnet groups**.
1. Choose **Create subnet group**.
1. On the **Create replication subnet group** page, specify your replication subnet group information. The following table describes the settings.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. Choose **Create subnet group**.
## Resolving domain endpoints using DNS
Usually, an AWS DMS replication instance uses the Domain Name System (DNS) resolver in an Amazon EC2 instance to resolve domain endpoints. If you require DNS resolution, you can use the Amazon Route 53 Resolver. For more information about using Route 53 DNS Resolver, see [Getting started with Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html).
For information about how to use your own on-premises name server to resolve certain endpoints using the Amazon Route 53 Resolver, see [Using your own on-premises name server](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
# 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 AWS KMS key that is unique to your AWS account. You can view and manage this KMS key with AWS Key Management Service (AWS KMS). You can use the default KMS key in your account (`aws/dms`) or a KMS 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](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*.
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 AWS KMS. You can find AWS KMS in the AWS Management Console by searching for **KMS** on the navigation pane.
AWS KMS combines secure, highly available hardware and software to provide a key management system scaled for the cloud. Using AWS KMS, you can create encryption keys and define the policies that control how these keys can be used. AWS KMS supports AWS CloudTrail, so you can audit key usage to verify that keys are being used appropriately. Your AWS KMS keys can be used in combination with AWS DMS and other supported AWS services. Supported AWS services include Amazon RDS, Amazon 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. This replication instance requires sufficient storage and processing power to perform the tasks that 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 an AWS DMS replication instance](CHAP_ReplicationInstance.md).
**To create a replication instance by using the AWS console**
1. Choose **Replication instances** in the navigation pane of the AWS DMS console and then choose **Create replication instance**.
1. On the **Create replication instance** page, specify your replication instance information. The following table describes the settings you can make.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Choose the **Advanced** tab to set values for network and encryption settings if you need them. The following table describes the settings.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Specify the **Maintenance** settings. The following table describes the settings. For more information about maintenance settings, see [Working with the AWS DMS maintenance window](CHAP_ReplicationInstance.MaintenanceWindow.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. 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, choose the **Apply changes immediately** option in the AWS Management Console. Or use the `--apply-immediately` parameter when calling the AWS CLI, or set the `ApplyImmediately` parameter to `true` when using the 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 open the AWS DMS console at [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. In the navigation pane, choose **Replication instances**.
1. Choose the replication instance you want to modify. The following table describes the modifications you can make.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## Best practices when modifying a replication instance
When modifying a replication instance, following these best practices helps ensure a successful update with minimal impact to your migration workflows. Take the following key steps before, during, and after modifications to maintain data integrity and operational efficiency throughout the process.
**Plan modification timing:**
+ You can either apply changes immediately or schedule them for the next maintenance window.
+ Schedule during low-traffic periods to minimize impact.
**Pre-modification steps:**
+ Stop all active replication tasks.
+ Verify all tasks have successfully stopped.
+ Document current configuration task settings.
**During modification:**
+ Monitor the modification progress.
+ Wait for "Available" status before proceeding.
**Post-modification steps:**
+ Resume all previously stopped tasks.
+ Confirm tasks are running correctly.
# 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 planned failover from one AWS Availability Zone to another when you reboot. When you force a planned failover of your AWS DMS instance, AWS DMS closes out active connections on the current instance prior to automatically switching to a standby instance in another Availability Zone. Rebooting with a planned failover helps you simulate a planned failover event of an AWS DMS instance, such as when scaling the replication instance class.
**Note**
After a reboot forces a failover from one Availability Zone to another, the Availability Zone change might not be reflected for several minutes. This lag appears in the AWS Management Console, and in calls to the AWS CLI and AWS DMS API.
If migration tasks are running on the replication instance when a reboot occurs, no data loss occurs but the task stops, and the task status changes to an error state.
If the tables in the migration task are in the middle of a bulk load (full load phase) and haven't yet started, they go into an error state. But tables that are complete at that time, remain in a complete state. When a reboot happens during the full load phase, we recommended that you perform either one of the steps below.
+ Remove the tables that are in a complete state from the task, and restart the task with the remaining tables.
+ Create a new task with tables in an error state, and with tables that are pending.
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 open the AWS DMS console at [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. In the navigation pane, choose **Replication instances**.
1. Choose the replication instance you want to reboot.
1. Choose **Reboot**. The **Reboot replication instance** dialog box opens.
1. Select the check box for **Reboot with planned failover?** if you have configured your replication instance for Multi-AZ deployment and you want to fail over to another AWS Availability Zone.
1. Choose **Reboot**.
## Rebooting a replication instance using the CLI
To reboot a replication instance, use the AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html) 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 arn of my rep instance
```
**Example simple reboot with failover**
The following AWS CLI example reboots a replication instance with failover.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## Rebooting a replication instance using the API
To reboot a replication instance, use the AWS DMS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) action with the following parameters:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example simple reboot**
The following code example reboots a replication instance.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &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.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &ForcePlannedFailover=true
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &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.
If your replication instance meets all the criteria for deletion, and it stays in the `DELETING` status for an extended period of time, contact support to troubleshoot the issue.
## 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 open the AWS DMS console at [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. In the navigation pane, choose **Replication instances**.
1. Choose the replication instance you want to delete.
1. Choose **Delete**.
1. In the dialog box, choose **Delete**.
## Deleting a replication instance using the CLI
To delete a replication instance, use the AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html) 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 arn of my rep instance
```
## Deleting a replication instance using the API
To delete a replication instance, use the AWS DMS API [https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html) action with the following parameters:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example delete**
The following code example deletes a replication instance.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=DeleteReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Working with the 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.
## 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 stops the task for a moment and then resumes it after 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 as part of a **migrate existing data** or **migrate existing data and replicate ongoing changes** task, DMS stops and then restarts the migration for all tables that are in full load phase while the patch is applied. DMS also stops and resumes all tables that are in CDC phase while the patch is applied.
## 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 console
You can change the maintenance window time frame using the AWS Management Console.
**To change the preferred maintenance window using the console**
1. Sign in to the AWS Management Console and open the AWS DMS console at [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. In the navigation pane, choose **Replication instances**.
1. Choose the replication instance you want to modify and choose **Modify**.
1. Expand the **Maintenance** tab and choose a date and time for your maintenance window.
1. Choose **Apply changes immediately**.
1. Choose **Modify**.
### Changing the maintenance window setting using the CLI
To adjust the preferred maintenance window, use the AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 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 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 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.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=ModifyReplicationInstance
3. &DBInstanceIdentifier=myrepinstance
4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```