How can I speed up my DMS migration ?

Question :  We're trying to run a DMS migration task which is taking over 3.5 hrs - and would like to decresase the runtime. Are there some infrastructure or process changes changes we can make to improve the run time?

 Answer: Optimizing DMS performance 

Correctly sized replication server. Most of the processing occurs in the Replication Server memory - with larger transactions spilling onto disk - which significantly slow down performance. 

If you are using T2 class servers , think about using a C4 class - if you are processing a heterogenous conversion - e.g SQL Server to PostgreSQL there is a fair  amount of CPU processing occuring during the conversion process.   R4 offer even greater memory per vCPU

For very high memory intenisive migrations with high levels of workloads look at R5 instances    or C5 class

Using AWS CLI 

--get Replication Instance Class
aws dms describe-replication-instances --query "ReplicationInstances[?ReplicationInstanceIdentifier=='myReplicationInstance'].ReplicationInstanceClass" --output table

Storage   - Generally the 100 GB default does the job , keep an eye on the ReadIOPS and WriteIOPS metrics. 

--get Replication Storage
aws dms describe-replication-instances --query "ReplicationInstances[?ReplicationInstanceIdentifier=='myReplicationInstance'].AllocatedStorage" --output table

Multi AZ or Single AZ - This will depend on requirements. generally for smaller jobs I use Single AZ but the benefits of Multi AZ relate to failures during a FULL LOAD and managing tje process to avoid starting from the start

--get MultiAZ status
aws dms describe-replication-instances --query "ReplicationInstances[?ReplicationInstanceIdentifier=='myReplicationInstance'].MultiAZ" --output table

Loading multiple tables in parallel   - 8 tables simultaneously is the default setting - it is possible to extract better performance by increasing the number , if using the large class of server. 

Indexes, Triggers, Reference Integrity Constraints

For a full load task - the normal recommendation is to not include Primary Key indexes, secondary indexes, triggers and and referential constraints. That is because  1) it is not possible to guarentee the order of the tables   2) These add extra processing .

It is possible to generate the code using the Schema Conversion Tool and apply after the Full Load. This needs some co-ordination and  unit  & smoke testing 

Backups & Transaction Logging - I would recommend you complet ethe migration outside of the backup window. 

Single or multiple tasks - This requires some analysis - but it may be more efficient to breake down the monolithic miration task into more efficient tasks completion usnits 

Monitoring the migration task You can also enable AWS DMS Context Logging  , which can give you  insights into where issues may be arising causing failures or delays