How can I troubleshoot AWS DMS endpoint connectivity failures?

Last updated: 2019-09-26

I can't connect to my AWS Database Migration Service (AWS DMS) endpoints. Why is my test connection failing, and how can I troubleshoot these connectivity issues?

Resolution

After you create your AWS DMS source and target endpoints, it's a best practice to test the connectivity from the AWS DMS replication instance to the endpoints before starting the AWS DMS migration task. Testing the connectivity helps make sure that the task doesn't fail because of connectivity issues with the endpoint.

For the AWS DMS replication instance to connect to the source and target endpoints, the security group that is used by the AWS DMS replication instance must include outbound rules for the endpoint's IP addresses for the specific port. If the outbound rules in the security group for the replication instance are correct, then check the inbound network or security configuration on the source or target database. For more information, see Adding, Removing, and Updating Rules.

If the error occurred because access to the database is denied, you can see errors similar to the following:

Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]FATAL: password authentication failed for user "dmsuser" ODBC general error.
Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2005 Message: [unixODBC][MySQL][ODBC 5.3(w) Driver]Unknown MySQL server host 'mysql1.chulbfpmdg0x.us-east-1.rds.amazonaws.com' (22) ODBC general error.

To resolve these errors, confirm that the following endpoint details are set correctly:

  • Username and Password
  • ServerName (DB instance endpoint name)
  • Port

If the error is caused by network configuration or timeouts, you can see errors similar to the following:  

Test Endpoint failed:
    Application-Status: 1020912, Application-Message: Failed to connect Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HYT00 NativeError: 0 Message: [unixODBC][Microsoft][ODBC Driver 13 for SQL Server]Login timeout
    expired ODBC general error.
Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001
    NativeError: 101 Message: [unixODBC]timeout expired ODBC general error.

To resolve these errors, check the resolution for the NativeError for your endpoint's database engine.

The source or target database is hosted on AWS

First, confirm that the database has a security group configuration that allows incoming traffic from the AWS DMS replication instance's IP address.

To verify the public and private IP address of the replication instance, follow these steps:

  1. Open the AWS DMS console and choose Replication instances from the navigation pane.
  2. Choose the name of your replication instance.
  3. From the Details section, you can check the Public IP address and Private IP address of your replication instance. Or you can run describe-replication-instances to check the IP addresses of your replication instance:

Private IP address

aws dms describe-replication-instances
    --filters Name=replication-instance-id,Values=<DMS replication instance name> "ReplicationInstances[*].ReplicationInstancePrivateIpAddress" --output=text

Public IP address

aws dms describe-replication-instances --filters Name=replication-instance-id,Values=<DMS replication instance name> "ReplicationInstances[*].ReplicationInstancePublicIpAddress" --output=text

Then, confirm that the network access control list (ACL) rules for the Amazon Virtual Private Cloud (Amazon VPC) don't restrict incoming traffic to the source or target databases and the replication instance, for example, an explicit deny rule. Finally, confirm that the route table for the subnet associated with the database has the required entries that allow either public or private network traffic.

The source or target database is hosted on-premises

Check with your network administrator to determine if your database is set up to allow incoming connections from the AWS DMS replication instance. Verify that the DNS configuration is set up correctly and that there isn't a firewall blocking communication to the source or target database.

If you can't identify the bottleneck in the network connectivity, create a new Amazon Elastic Compute Cloud (Amazon EC2) instance in the same VPC and with the same network configurations as the AWS DMS replication instance. From the new test EC2 instance, run the following commands to further troubleshoot the network connectivity:

telnet <IP address of host database server> <port number>
nslookup <Fully qualified domain name for the database server>
tracert <IP address of host database server>