{"id":78263,"date":"2026-03-10T11:19:49","date_gmt":"2026-03-10T05:49:49","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=78263"},"modified":"2026-03-16T15:42:49","modified_gmt":"2026-03-16T10:12:49","slug":"cross-account-rds-migration-using-aws-dms-snapshot-cdc-strategy","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/cross-account-rds-migration-using-aws-dms-snapshot-cdc-strategy\/","title":{"rendered":"Cross-Account RDS Migration Using AWS DMS (Snapshot + CDC Strategy)"},"content":{"rendered":"

Migrating databases<\/strong> between AWS accounts<\/strong> is often necessary for environment isolation, organizational changes, or setting up security boundaries<\/strong>. Basic migrations can be performed using dumps or replication. However, production environments<\/strong> need minimal downtime, consistency guarantees, and controlled cutover procedures.<\/strong><\/p>\n

A strong method for migrating databases between accounts is to combine snapshot-based data transfer with Change Data Capture (CDC) using AWS Database Migration Service<\/strong>. This article outlines a technical setup and provides a step-by-step guide for moving a MySQL database from one AWS account to another Amazon RDS instance. This will use snapshot restore and CDC replication.<\/p>\n

\"DMS

DMS architecture<\/p><\/div>\n

The migration workflow includes these main components: Source database (Account A), Target RDS instance (Account B), Snapshot restore for the initial dataset, and CDC replication through DMS for ongoing changes.<\/strong><\/p>\n

Target Account\u2019s RDS<\/strong>
\nAmazon RDS provides a managed relational database where the migrated dataset will reside.<\/p>\n

Migration Engine<\/strong>
\nDatabase Migration Service<\/p>\n

AWS DMS performs the continuous replication of changes from the source database to the target RDS instance<\/strong> by reading transaction logs and applying changes in near real time.<\/p>\n

Strategy for Migration
\n<\/strong>Running a full-load migration through DMS is inefficient for large databases and may result in lengthy migration windows. Rather, a hybrid approach is better:
\nTransfer of baseline datasets using a snapshot(Sharing your snapshot with the target account)
\nContinuous replication through CDC
\nThis method allows for almost no downtime cutover while cutting down on migration time.<\/p>\n

 <\/p>\n

Phase 1: Transfer of Cross-Account Snapshots
\n<\/strong>An RDS snapshot is used to transfer the original dataset.<\/p>\n

Step 1:- Make a snapshot in the source account.
\n<\/strong>Make a manual snapshot of the source RDS instance in Account A(Source).
\nDatabases \u2192 Actions \u2192 RDS Console \u2192 Take Snapshot<\/p>\n

Step 2:- Give the target account access to the snapshot
\n<\/strong>Snapshots need to be explicitly shared between AWS accounts.<\/p>\n

Choose the Snapshot.
\nIn actions, click on share snapshot.
\nSnapshot \u2192 Actions \u2192 Share Snapshot \u2192 Add Target Account ID \u2192 Share<\/p>\n

KMS key needs to be shared with the target account if encryption is enabled on Source RDS.<\/p>\n

\"Share

Share Snaphot<\/p><\/div>\n

\"KMS

KMS Permission<\/p><\/div>\n

 <\/p>\n

Copy the snapshot to the target account in step three.
\nCopy the shared snapshot in Account B.<\/p>\n

RDS \u2192 Snapshots \u2192 Shared with me \u2192 Snapshot copy(use KMS of Target account, by this, the destination account owns a new snapshot)<\/p>\n

Phase 2 \u2014 Preparing Source Database for CDC<\/strong>
\nTo enable continuous replication, the source database must expose transaction logs.
\nFor MySQL-based engines, enable binary logging.
\nExample parameter configuration:<\/p>\n

    \n
  • log_bin = ON<\/li>\n
  • binlog_format = ROW<\/li>\n
  • binlog_row_image = FULL<\/li>\n
  • binlog retention hours = 24-168hrs, This can be set with
    \nCALL mysql.rds_set_configuration(‘binlog retention hours’, 168);Verify configuration:<\/li>\n
  • SHOW VARIABLES LIKE ‘log_bin’;<\/li>\n
  • SHOW VARIABLES LIKE ‘binlog_format’;
    \nTake Current Binlog file position with below query this will be used on CDC task creation<\/li>\n
  • SHOW MASTER STATUS;\n
      \n
    • Output Ex:-\n

      \"BinLog

      BinLog Position<\/p><\/div><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

      ROW binlog format<\/strong> ensures row-level changes are captured properly.
      \nWhen we use the snapshot + CDC approach, the CDC task should start from the exact binlog position corresponding to the snapshot creation time.<\/strong>
      \nIf the CDC task starts from a later binlog position, transactions that occurred between the snapshot and CDC start will be lost.<\/p>\n

      Phase 3: Account-to-Account Networking
      \n<\/strong>Cross-account networking needs to be set up because DMS needs to access both RDS.
      \nDirect network connectivity between VPCs in two accounts can be achieved by VPC peering or Transit Gateway.<\/p>\n

      Phase 4: Establishing the DMS Replication Configuration
      \n<\/strong>Actual data replication is carried out by a replication instance.<\/p>\n

      Configuration parameters:<\/p>\n

        \n
      • Instance of class dms.r5.XX for Mid size database migrations and higher for huge databases<\/li>\n
      • 100\u2013200 GB of storage, can be increased later on in case of requirement.<\/li>\n
      • Multi-AZ for Production workloads<\/li>\n
      • Access for the public is disabled.<\/li>\n<\/ul>\n

        Considerations for placement:<\/strong><\/p>\n

          \n
        • Deploy in VPC that can reach both source and target RDS<\/li>\n
        • Set up security groups to permit database ports for DMS Instance.<\/li>\n<\/ul>\n

          Phase 5: Creating DMS Instance<\/strong>
          \nA Replication Instance<\/strong> is the core compute component that runs migration tasks in AWS Database Migration Service.
          \nIt connects to the source database, reads transaction logs, and applies changes to the target database such as Amazon Relational Database Service.<\/p>\n

          It works like migration engine that processes replication pipelines<\/strong>.<\/p>\n

          Open AWS DMS Console<\/strong>
          \nNavigate to: AWS Console \u2192 Database Migration Service\u2192 Replication Instances
          \nClick: Create replication instance<\/p>\n

          Configure Basic Instance Settings<\/strong>
          \nReplication Instance Identifier<\/strong> : Provide a unique identifier.
          \nExample: prod-mysql-migration-dms
          \nBest practice naming: <environment>-<source>-<target>-dms
          \nInstance Class<\/strong> :-Defines CPU and memory capacity.
          \nCommon production sizes<\/strong>: Example configuration: Instance Class: dms.r5.large(vCPU: 2, Memory: 16 GB)<\/p>\n

          Rule of thumb:<\/strong> Large tables + CDC + many tasks should have a bigger instance class.<\/p>\n

          Engine Version<\/strong>
          \nChoose the latest stable DMS engine version<\/strong>.<\/p>\n

          Benefits:<\/strong>
          \n<\/strong><\/p>\n

            \n
          • Bug fixes<\/li>\n
          • Improved CDC performance<\/li>\n
          • Better LOB handling<\/li>\n<\/ul>\n

            Allocated Storage
            \n<\/strong>Defines storage used for:<\/p>\n

              \n
            • task logs<\/li>\n
            • cached transactions<\/li>\n
            • sorting during migration<\/li>\n<\/ul>\n

              Typical values: Example: Allocate<\/p>\n

              \"DMS

              DMS Instance Classes<\/p><\/div>\n

              Network Configuration<\/strong>
              \nThe replication instance must run inside a VPC, Select Your VPC, Replication subnet group, VPC security groups, AWS KMS key then other details like Maintenance Window, Tags etc.
              \nThen Create your DMS Instance.<\/p>\n

              Source Endpoint (Account A)
              \n<\/strong>Required parameters:<\/p>\n

                \n
              • Server name<\/li>\n
              • Port<\/li>\n
              • Database Endpoint DNS<\/li>\n
              • Username<\/li>\n
              • Password<\/li>\n
              • Required privileges for the migration user:\n
                  \n
                • REPLICATION CLIENT<\/li>\n
                • REPLICATION SLAVE<\/li>\n
                • SELECT<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                  Connectivity should be verified using the Test Endpoint Connection<\/strong> feature.<\/p>\n

                  Target Endpoint (Account B)<\/strong>
                  \nRequired parameters:<\/p>\n

                    \n
                  • Server name<\/li>\n
                  • Port<\/li>\n
                  • Database Endpoint DNS<\/li>\n
                  • Username<\/li>\n
                  • Password<\/li>\n<\/ul>\n

                    The target database must allow connections from the replication instance security group.<\/p>\n

                    Phase 6 \u2014 Configuring CDC Migration Task<\/strong>
                    \nSince the snapshot already transferred the baseline dataset, the DMS task should run in CDC mode only<\/strong>.<\/p>\n

                    Task configuration:<\/strong><\/p>\n

                      \n
                    • Task identifier name : Provide a name for this task.<\/li>\n
                    • Descriptive Amazon Resource Name (ARN) – optional<\/li>\n
                    • Source database endpoint : Choose a source database endpoint<\/li>\n
                    • Target database endpoint : Choose a target database endpoint<\/li>\n
                    • Task mode\n
                        \n
                      • Provisioned : Select the amount of compute you want to dedicate to your migration or replication task<\/li>\n
                      • Serverless : DMS Will dynamically adjusts the level of compute needed for your migration or replication task(This will not need DMS instance which we have created Phase 5)<\/li>\n<\/ul>\n<\/li>\n
                      • Provisioned instance : Choose a provisioned instance<\/li>\n
                      • Task typeInfo\n
                          \n
                        • Replicate only :This will replicate data from source to target(CDC only)<\/li>\n<\/ul>\n<\/li>\n
                        • CDC configuration\n
                            \n
                          • Enable custom CDC start mode<\/li>\n
                          • CDC start point for source transactions<\/li>\n
                          • Native CDC start point<\/strong> : Put your Bin Log file position here in below format:-
                            \nmysql-bin-changelog.000024:373<\/strong><\/li>\n<\/ul>\n<\/li>\n
                          • CDC stop mode for source transactions : Disable custom CDC stop mode(It will allow you to stop CDC when you want to stop)<\/li>\n
                          • Setting Editing mode<\/li>\n
                          • Wizard<\/li>\n
                          • Target table preparation mode\n
                              \n
                            • Do nothing(This will only put the changes on the Datasets)<\/li>\n<\/ul>\n<\/li>\n
                            • Include LOB columns in replicationInfo\n
                                \n
                              • Limited LOB mode : Should be a numeric value of Max LOB size in your Dataset.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                                Log settings<\/strong><\/p>\n

                                  \n
                                • Task logs<\/strong>\n
                                    \n
                                  • Turn on CloudWatch logs, DMS task logging uses Amazon CloudWatch to log information during the migration process. You can change the component activities logged and the amount of information logged for each one.<\/li>\n<\/ul>\n<\/li>\n
                                  • Table mappings<\/strong>\n
                                      \n
                                    • Editing mode<\/strong> : Wizard(You can enter only a Dataset\/Database names here)Ex:-<\/li>\n
                                    • Schema name, Schema table name, Action(Include or Exclude)<\/li>\n<\/ul>\n<\/li>\n
                                    • Premigration assessment<\/strong>\n
                                        \n
                                      • A premigration assessment warns you about potential issues before migration begins, running efficiently, and has a minimal impact on your databases.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                                        Migration task startup configuration<\/strong><\/p>\n

                                          \n
                                        • Start migration task\n
                                            \n
                                          • Automatically on create<\/li>\n
                                          • Manually later(Recommended)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                                            Monitoring the Migration<\/strong>
                                            \nMonitoring replication health is critical for production migrations.<\/p>\n

                                            Key metrics: CDCLatencySource(Time between commit and capture), CDCLatencyTarget(Time to apply change to target), CDCIncomingChanges(Replication throughput).<\/p>\n

                                              \n
                                            • Monitoring tools include:\n
                                                \n
                                              • CloudWatch metrics<\/li>\n
                                              • DMS task logs<\/li>\n
                                              • Table statistics dashboard<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                                                Potential Issue you may face:-
                                                \n<\/strong>Foreign Key Conflicts :- During CDC replication, insert order may violate foreign key constraints which can cause errors.
                                                \nExample error: Cannot add or update a child row: a foreign key constraint fails
                                                \nCommon mitigation: SET FOREIGN_KEY_CHECKS=0;
                                                \nThis will disable constraints during migration and re-enable after replication completes.<\/p>\n

                                                  \n
                                                • Final Cutover Procedure<\/strong>
                                                  \nWhen CDC latency comes to minimal, perform the final cutover.
                                                  \nStandard procedure:<\/p>\n
                                                    \n
                                                  1. Pause application writes<\/li>\n
                                                  2. Allow CDC replication to reach zero lag<\/li>\n
                                                  3. Validate row counts and checksums<\/li>\n
                                                  4. Update application database endpoint<\/li>\n
                                                  5. Resume application traffic<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n

                                                    Typical downtime is less than a few minutes<\/strong>.<\/p>\n

                                                    Validation and Data Consistency<\/strong>
                                                    \nBefore switching production traffic, verify dataset integrity.
                                                    \nCommon checks should match with source RDS include:
                                                    \nRow counts :<\/strong> SELECT COUNT(*) FROM table_name;
                                                    \nChecksum validation :<\/strong> CHECKSUM TABLE table_name;
                                                    \nSchema comparison tools can also ensure structural consistency.<\/p>\n","protected":false},"excerpt":{"rendered":"

                                                    Migrating databases between AWS accounts is often necessary for environment isolation, organizational changes, or setting up security boundaries. Basic migrations can be performed using dumps or replication. However, production environments need minimal downtime, consistency guarantees, and controlled cutover procedures. A strong method for migrating databases between accounts is to combine snapshot-based data transfer with Change […]<\/p>\n","protected":false},"author":2167,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":17},"categories":[5877],"tags":[8449,4843,8448,3940,1703,8447],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78263"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2167"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=78263"}],"version-history":[{"count":2,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78263\/revisions"}],"predecessor-version":[{"id":78310,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78263\/revisions\/78310"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=78263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=78263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=78263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}