Stitching mydumper to Aurora's Binlog: A Cross-Cloud CDC Pipeline at 1.2B Rows

We needed to replicate AWS Aurora MySQL into another cloud, in production, without touching a primary that serves 20 million users. Our first attempt shipped every binlog row across the cloud boundary, including the tables we didn’t actually need. The egress bill made it untenable. The fix was smaller than expected: stitch a multi-hour mydumper snapshot to a live, filtered binlog stream, and a 1.2-billion-row dataset stays consistent without a single replay or gap.

What we’ll cover:

• The pseudo full-load pattern that doesn’t touch the production primary: AWS Aurora snapshot, parallel mydumper/myloader into CloudSQL for MySQL, with the binlog position captured at snapshot time so CDC resumes exactly where the dump left off. Data consistency is preserved, with zero load on the running primary instance.
• The binlog filter that paid the bill: filtering at the source to keep only the tables we actually needed cut cross-cloud egress from 400 GB to 40 GB and dropped the monthly bill by 80%+.
• Observability from the exception table you already have: AWS DMS records apply errors in a control table on the target. Instead of scraping logs or building dashboards, we poll that table and forward only the unresolved ones to our observability backend — error visibility built on what the migration tool already writes down.

If you run AWS Aurora MySQL in production and have thought about moving (or just replicating) across clouds, this is the production case study we wish we’d had.