Zero-Downtime Database Migrations on AWS: Combining Aurora Serverless v2 and DMS

Database migrations are often viewed as high-risk engineering operations that require scheduled maintenance windows and application downtime. However, for modern applications with global users, taking your application offline is no longer an option.

By combining Amazon Aurora Serverless v2 with AWS Database Migration Service (DMS), you can migrate live relational databases (MySQL, PostgreSQL, Oracle, or SQL Server) to AWS with near-zero downtime while automatically handling dynamic traffic spikes.

Aurora Serverless v2 scales compute and memory capacity in fractions of a second—from 0.5 ACUs to 128 ACUs (Aurora Capacity Units)—without interrupting database transactions. During large data ingestion phases in a migration, Aurora automatically scales up to handle write throughput, then scales back down when traffic stabilizes.

[ Source DB (On-Prem / EC2) ]
│
├───────> (1. Full Load Snapshot) ────────┐
│ ▼
[ Transaction Log ] ──> (2. Continuous CDC) ──> [ AWS DMS ] ──> [ Aurora Serverless v2 ]
│
▼
[ App Traffic Cutover ]
Full Load Phase: AWS DMS creates a snapshot of the source database schema and existing data, inserting it into Aurora Serverless v2.

CDC Phase (Replication): DMS continuously reads the binary/transaction logs from the source database, applying ongoing row changes in real-time to the target.

PostgreSQL: Set wal_level = logical in postgresql.conf.

MySQL: Enable binlog_format = ROW in my.cnf.

Step 2: Provision the Aurora Serverless v2 Cluster
Define your minimum and maximum ACU limits (e.g., Min: 0.5 ACU, Max: 16 ACU) to allow elastic scaling during the bulk data load.

Step 3: Launch AWS DMS Replication Instance & Tasks
Create source and target DMS Endpoints.

Create a Replication Task with the migration type set to:

Migrate existing data and replicate ongoing changes (Full Load + CDC).

Start the task and monitor the AWS Management Console to verify CDC replication latency reaches < 1 second.

Step 4: Execute the Zero-Downtime Cutover
Pause write traffic on the application for a few seconds.

Confirm the DMS target database replication status is fully in-sync (zero latency lag).

Update your application's connection string (e.g., via AWS Systems Manager Parameter Store or Secrets Manager) to point to the Aurora Primary Writer Endpoint.

Resume write traffic on the new database.

Monitor DMS Memory Usage: Ensure your DMS replication instance has sufficient RAM (such as dms.c5.xlarge) to prevent swap file bottlenecks during large transactions.

Conclusion
Zero-downtime migrations do not require complex custom scripts. Leveraging AWS DMS CDC alongside Aurora Serverless v2's autoscaling capability gives you an elastic, reliable migration pipeline that keeps your business running smoothly without missing a transaction.