DMS Serverless - Internal server error and no further logs!

Hi Didier_AWS, Do you know how to stop it, because I am facing the same problem.

We are also testing DMS serverless and also getting the same message as the op, at the stage described in logs as ...

Fetching metadata from your source endpoint to calculate workload capacity.

{'replication_state':'failed', 'message': 'Failed to fetch metadata.', 'failure_message': 'Internal failure.'}

Has anyone following this thread discovered any new relevant info regarding this issue?

We are also seeing the same exact issue currently, there is not enough information in the logs to know what the problem is. It would be great if DMS could output the actual problem in the logs so that we can address it. We have an open case at the moment, if we find anything out I can post back here.

Hi, DMS serverless is brand new so some glitches may still be present. Did you try to open a Support case from within the console of your AWS account? AWS Service teams usually do not monitor sites like re:Post. So, they won't your issue for which you seem to have solid and tangible evidence.

[OP] After some weeks of waiting for the Support case to be handled by "the internal team", Amazon eventually recognized that they have a bug reading the metadata of the DB (while calculating the capacity units to use). The explanation: "Your DMS Serverless replication config "..." failed while provisioning, due to an issue with how your database is interacting with DMS performance optimization processes. We are making a fix for this issue which we expect to be available for you to use by Tuesday 07/16."

After they deployed this fix, I had no more errors, did multiple migrations, and calculating DCUs worked fine (seems it needed a lot of them, 256, maybe related). The poor logging during failure: I don't know if they improved it (from the most recent answer here, it seems that no).

I recently resolved several challenges while setting up AWS DMS Serverless replication, particularly when the source database and the DMS replication instance resided in different VPCs. Issues ranged from initial connectivity failures to less descriptive "internal error failed" messages. Based on my experience, here are key configurations and considerations that proved critical:

**Establish VPC Peering for Cross-VPC Communication: ** Context: AWS DMS Serverless replication instances do not possess public IP addresses. They operate within the subnets you specify in your VPC. Action: If your source or target database is in a different VPC from your DMS Serverless replication, you must establish a VPC Peering connection between the two VPCs. Crucial Step: After establishing the peering connection, update the route tables associated with the relevant subnets in both VPCs. Add routes that direct traffic destined for the peered VPC's CIDR block through the VPC peering connection. Without these routes, the VPCs won't know how to communicate with each other.

**Enable DNS Resolution for the VPC Peering Connection: **Context: If you use DNS hostnames (e.g., RDS endpoint names) to connect to your databases, these hostnames must resolve to private IP addresses across the peered VPCs. Action: In the VPC Peering connection settings, ensure you enable DNS resolution. Specifically, select: "Allow accepter VPC to resolve DNS of hosts in requester VPC to private IP addresses." "Allow requester VPC to resolve DNS of hosts in accepter VPC to private IP addresses." Impact: This allows resources in one VPC to resolve private DNS hostnames in the peered VPC, which is essential for DMS to find your database endpoints.

**Configure VPC Endpoints for AWS Secrets Manager (if used): ** Context: If your DMS replication is configured in private subnets (without a NAT Gateway for internet access) and you are using AWS Secrets Manager to store database credentials, DMS needs a private path to access Secrets Manager. Action: Create a VPC Interface Endpoint for Secrets Manager (service name: com.amazonaws.<region>.secretsmanager) within the VPC where your DMS Serverless replication is running. Benefit: This allows DMS to retrieve credentials securely over the AWS private network without requiring internet access, enhancing security and reliability.

**Set Appropriate DMS Capacity Units (DCUs): ** Context: Insufficiently provisioned DMS Capacity Units (DCUs) for your replication task can lead to obscure errors, making troubleshooting difficult. Symptom: An undersized configuration might result in errors like: Replication failed due to an internal failure. Replication failed in state 'REPLICATION_STARTING'. Setting state to FAILED Action: Carefully consider your data volume, transactional load, and the complexity of transformations when setting the Minimum and Maximum DCUs. Under-provisioning is a common source of unexpected task failures.