Issue with AWS DMS Full Load + CDC Task Not Reflecting Newly Created Tables in Target DB

Ensure that your table mapping rules include the newly created tables. If your task is configured with specific table mappings, new tables won't be automatically included unless the mappings are updated.

Update your table mapping rules to include the new tables. You can use wildcard patterns to include all tables dynamically.

example

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "%",
        "table-name": "%"
      },
      "rule-action": "include"
    }
  ]
}

if above condition is already in use. check if the the ddl statement being used is supported by DMS. also by default ddls are not reported by pg in wal logs To capture DDL events, AWS DMS creates various artifacts in the PostgreSQL database when a migration task starts.

check if you have below objects in source db under public schema

trigger awsdms_intercept_ddl;
function awsdms_intercept_ddl
table awsdms_ddl_audit

another reason for not capturing ddls as mentioned in limitations of psql as source is In most cases, AWS DMS supports change processing of CREATE, ALTER, and DROP DDL statements for tables. AWS DMS doesn't support this change processing if the tables are held in an inner function or procedure body block or in other nested constructs.

For example, the following change isn't captured.

CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
create table attu.distributors1(did serial PRIMARY KEY,name
varchar(40) NOT NULL);
END;
$$;

Also If your source database is also a target for another third–party replication system, DDL changes might not migrate during CDC. Because that situation can prevent the awsdms_intercept_ddl event trigger from firing. To work around the situation, modify that trigger on your source database as follows:

alter event trigger awsdms_intercept_ddl enable always;