Deep Dive into AWS Database Migration Service (AWS DMS)

Summary:

• AWS DMS enables seamless database migrations with minimal downtime through full load and Change Data Capture (CDC) capabilities, supporting both homogeneous and heterogeneous migration paths.
• Version 3.6.1 introduces PostgreSQL 17 support, IAM database authentication, and enhanced data resync features that address critical gaps in enterprise migration workflows for 2025 and beyond.
• DMS Serverless eliminates capacity planning overhead while homogeneous migrations leverage native database utilities for optimal performance, though each approach carries distinct cost and complexity trade-offs.
• Understanding replication instance sizing, LOB handling strategies, and validation mechanisms separates successful large-scale migrations from costly failures.

Every engineering team eventually faces the migration question. How do you move terabytes of production data to a new database engine without bringing your business to a halt? AWS Database Migration Service (AWS DMS) has become the default answer for thousands of organizations, yet most teams barely scratch the surface of its capabilities.

The gap between running a basic migration task and orchestrating a zero-downtime, multi-terabyte migration with continuous replication represents years of hard-won operational knowledge. This guide bridges that gap by examining AWS DMS through the lens of real architectural decisions, cost trade-offs, and the edge cases that derail migrations at 2 AM on a Sunday.

The following diagram illustrates the complete AWS DMS architecture, showing how data flows from source databases through replication instances to various target endpoints.

Architecture and components of AWS DMS

AWS DMS operates on a deceptively simple premise. Read data from a source, transform it if necessary, and write it to a target. The elegance lies in how the service abstracts the complexity of maintaining transactional consistency across disparate database engines. At its core, the architecture comprises three primary components that work in concert to execute migrations reliably.

The replication instance serves as the compute engine that hosts the migration tasks. This EC2-based resource runs the AWS DMS replication engine, which manages connections to both source and target endpoints. Instance sizing directly impacts throughput, with larger instances providing more memory for caching and more CPU cycles for transformation operations. For migrations involving complex transformations or high transaction volumes, undersizing the replication instance remains the most common performance bottleneck.

Source and target endpoints define the connection parameters for your databases. Each endpoint encapsulates connection strings, authentication credentials, and engine-specific settings. AWS DMS supports an extensive catalog of sources including Oracle, SQL Server, PostgreSQL, MySQL, MongoDB, and Amazon S3. Target options extend this list to include Amazon Redshift, Amazon OpenSearch Service, and Kinesis Data Streams, enabling migrations that simultaneously modernize data architectures.

Replication tasks define what data moves and how. Tasks specify table mappings, transformation rules, and migration type (full load, CDC, or both). A single replication instance can host multiple tasks, though resource contention becomes a factor when running parallel migrations. Understanding how tasks consume instance resources helps architects plan migration waves that maximize throughput without overwhelming the replication engine.

With the architectural foundation established, the next consideration involves choosing the appropriate migration type for your specific scenario.

Migration types

The distinction between homogeneous and heterogeneous migrations fundamentally shapes your migration strategy, tooling choices, and risk profile. AWS DMS handles both scenarios, but the operational characteristics differ substantially.

Homogeneous migrations

Homogeneous migrations move data between identical or compatible database engines, such as Oracle to Oracle or PostgreSQL to PostgreSQL. AWS introduced dedicated homogeneous migration support that leverages native database utilities rather than the traditional DMS replication engine. This approach uses tools like pg_dump and pg_restore for PostgreSQL migrations, delivering performance that often exceeds the generic replication approach by 2-3x for full load operations.

The homogeneous migration path supports version upgrades within the same engine family. Migrating from PostgreSQL 14 to PostgreSQL 17 becomes a single operation rather than requiring intermediate steps. Key operational characteristics include:

• No CDC support: Homogeneous migrations perform full load only, requiring application downtime during the final cutover.
• Schema must exist: Unlike heterogeneous migrations, the target schema must be pre-created before migration begins.
• Limited transformation: Data moves as-is without the transformation rules available in traditional DMS tasks.
• Native CDC support: Homogeneous migrations support both full load and Change Data Capture (CDC) by leveraging native database replication (like PostgreSQL logical replication), enabling near-zero downtime cutovers.
• Target preparation: While native tools migrate the basic tables, you often need to manually pre-create or migrate secondary objects like secondary indexes, foreign keys, and stored procedures using native database tools before the cutover.
• Limited transformation: Data moves as-is without the robust, on-the-fly transformation rules available in traditional heterogeneous DMS tasks.

Heterogeneous migrations

Heterogeneous migrations cross engine boundaries, converting Oracle to PostgreSQL or SQL Server to MySQL. These migrations require schema conversion, data type mapping, and often significant application code changes. AWS DMS Schema Conversion (formerly AWS SCT) automates much of this work, analyzing source schemas and generating target-compatible DDL.

The following table compares migration approaches to help architects select the optimal path for their requirements.

Zero-ETL integrations represent a third path, providing managed replication between specific AWS services like Aurora and Redshift without explicit DMS configuration. While powerful for analytics use cases, Zero-ETL lacks the flexibility of DMS for general-purpose migrations. Understanding these trade-offs prepares teams to evaluate the specific features AWS DMS offers in its current release.

Key features and updates for 2025-2026

AWS DMS version 3.6.1 introduces capabilities that address long-standing customer requests while expanding the service’s applicability to modern database deployments. These updates reflect AWS’s response to competitive pressure and evolving enterprise requirements.

PostgreSQL 17 support arrives as both a source and target endpoint, enabling organizations to migrate to the latest PostgreSQL release with its improved query performance and enhanced JSON capabilities. This support extends to Aurora PostgreSQL-Compatible Edition, allowing migrations that leverage Aurora’s distributed storage architecture. The AWS DMS release notes detail specific PostgreSQL 17 features supported in CDC mode.

IAM database authentication eliminates the need to store database credentials in DMS endpoint configurations. For PostgreSQL and MySQL endpoints, DMS can now authenticate using IAM roles, integrating with existing identity management workflows and reducing credential rotation overhead. This feature proves particularly valuable in regulated environments where credential management policies prohibit long-lived database passwords.

Data resync capabilities allow targeted re-migration of specific tables or partitions without restarting entire tasks. When validation identifies discrepancies, operators can now resync affected objects while CDC continues capturing ongoing changes. This granular control reduces recovery time from data inconsistencies that previously required full task restarts.

Read replica source support for CDC operations reduces load on production primary databases. DMS can now capture changes from PostgreSQL and MySQL read replicas, isolating migration workload from transaction processing. This capability enables migrations from high-throughput OLTP systems without impacting application performance.

These feature enhancements complement the serverless deployment model that has transformed how teams approach DMS capacity planning.

DMS Serverless deep dive

DMS Serverless fundamentally changes the operational model for database migrations by eliminating capacity planning decisions. Rather than selecting instance types and sizes, teams specify capacity ranges and let AWS handle resource allocation dynamically.

How DMS Serverless works

Serverless replications automatically scale compute resources based on workload characteristics. During initial full load phases when throughput demands peak, the service provisions additional capacity. As migrations transition to CDC mode with lower steady-state requirements, capacity scales down accordingly. This elasticity proves particularly valuable for migrations with unpredictable source transaction volumes.

Configuration requires specifying minimum and maximum DMS Capacity Units (DCUs). Each DCU represents exactly 2 GB of memory, with AWS recommending minimum values based on source database size:

1. Databases under 100 GB: Start with 2-4 DCU minimum
2. Databases 100 GB to 1 TB: Configure 4-8 DCU minimum
3. Databases exceeding 1 TB: Begin with 8-16 DCU minimum and scale maximum to 64+ DCU

The following diagram illustrates how DMS Serverless dynamically allocates resources across migration phases.

Performance optimization and cost modeling

Migration performance depends on a complex interplay of factors spanning network configuration, instance sizing, and source database characteristics. Cost optimization requires understanding both the obvious charges and the hidden expenses that accumulate during extended migrations.

Performance tuning strategies

Replication instance sizing represents the primary performance lever. Memory constraints manifest as increased disk I/O when the replication engine spills cached data to storage. CPU saturation appears during complex transformations or when processing high-volume CDC streams. Monitoring CloudWatch metrics for CPUUtilization, FreeableMemory, and SwapUsage reveals bottlenecks before they impact migration timelines.

Large Object (LOB) handling significantly impacts throughput. DMS offers three LOB modes:

• Full LOB mode: Migrates complete LOB data regardless of size, but processes rows sequentially rather than in parallel batches.
• Limited LOB mode: Truncates LOBs exceeding a specified size threshold, enabling parallel processing but risking data loss.
• Inline LOB mode: Processes small LOBs inline with row data while handling larger LOBs separately, balancing throughput with completeness.

Cost analysis for serverless versus provisioned

Pricing models differ substantially between deployment options. Provisioned replication instances charge hourly rates based on instance type, ranging from $0.018/hour for dms.t3.micro to $3.580/hour for dms.r6i.24xlarge. DMS Serverless charges $0.0625 per DCU-hour, with costs scaling dynamically based on actual utilization.

For a typical 500 GB migration completing in 8 hours:

Hidden costs accumulate in several areas. Cross-region data transfer charges $0.02 per GB, adding $10 per 500 GB migrated. Extended CDC operations for ongoing replication incur continuous compute charges. Failed migrations that require restart double or triple projected costs. The AWS DMS pricing page provides current rates, though modeling total migration cost requires accounting for these secondary factors.

With performance and cost considerations addressed, examining real-world use cases reveals how these factors combine in practice.

Use cases and edge cases

AWS DMS addresses migration scenarios ranging from straightforward lift-and-shift operations to complex multi-database consolidations. Understanding both common patterns and edge cases helps teams anticipate challenges before they impact production timelines.

Common migration patterns

Oracle to Aurora PostgreSQL represents the most frequent heterogeneous migration path. Organizations pursue this migration to reduce licensing costs while gaining Aurora’s managed scalability. Schema conversion typically achieves 80-90% automation, with stored procedures and Oracle-specific SQL constructs requiring manual remediation. The AWS DMS Schema Conversion documentation provides guidance on handling common conversion failures.

On-premises SQL Server to RDS SQL Server follows the homogeneous path, often as a first step toward cloud adoption. These migrations benefit from native backup/restore capabilities for initial data load, with DMS CDC handling ongoing replication during the transition period.

Database to S3 data lake ingestion uses DMS as a CDC pipeline rather than a migration tool. Capturing changes from operational databases and streaming them to S3 in Parquet format enables analytics workloads without impacting source systems.

Edge cases and failure modes

Certain scenarios consistently challenge DMS migrations:

• Tables without primary keys: CDC requires a mechanism to identify changed rows. Tables lacking primary keys force DMS into full-table scans for each change, degrading performance by orders of magnitude.
• Sequences and identity columns: Sequence values do not automatically synchronize. Post-migration scripts must reset sequences to values exceeding migrated data to prevent primary key conflicts.
• Triggers and computed columns: Target-side triggers fire during migration, potentially causing duplicate processing or constraint violations. Disabling triggers during migration and re-enabling post-cutover requires careful orchestration.

These edge cases underscore the importance of thorough pre-migration assessment and testing. Establishing best practices before migration begins prevents many common failures.

Best practices for successful migrations

Successful DMS migrations follow patterns that experienced practitioners have refined through hundreds of production deployments. These practices span planning, execution, and validation phases.

Pre-migration assessment

Comprehensive source analysis prevents surprises during migration execution. Key assessment activities include:

1. Inventory all database objects including tables, views, stored procedures, triggers, and sequences
2. Identify tables without primary keys and plan remediation strategies
3. Profile LOB columns to determine appropriate handling modes
4. Measure source transaction rates to size replication instances appropriately
5. Document application connection strings and credentials requiring updates post-migration

Execution and monitoring

Migration execution benefits from incremental approaches that validate progress continuously. Start with non-critical tables to verify configuration before migrating business-critical data. Enable DMS data validation to compare source and target row counts and checksums automatically. Monitor CDCLatencySource and CDCLatencyTarget CloudWatch metrics to ensure replication keeps pace with source changes.

Cutover and validation

The cutover window represents the highest-risk phase of any migration. Minimize this window by ensuring CDC has fully caught up before initiating application switchover. Validate data integrity using application-level queries that exercise business logic, not just row counts. Maintain rollback capability by keeping source databases operational until validation completes.

Understanding limitations helps teams plan around constraints that best practices cannot fully mitigate.

Limitations and constraints

AWS DMS, despite its capabilities, operates within boundaries that impact certain migration scenarios. Acknowledging these limitations during planning prevents mid-migration discoveries that derail timelines.

Schema migration limitations affect heterogeneous migrations most significantly. DMS migrates data but does not automatically create secondary indexes, foreign key constraints, or triggers on target databases. Teams must script these objects separately and apply them post-migration, often requiring careful sequencing to avoid constraint violations during data load.

Data type conversion constraints emerge when source types lack direct target equivalents. Oracle’s NUMBER type with unspecified precision maps ambiguously to PostgreSQL numeric types. SQL Server’s DATETIME2 with nanosecond precision loses fidelity when targeting MySQL’s microsecond-precision DATETIME. The AWS DMS documentation provides data type mapping tables, but edge cases require testing with production data samples.

Performance ceilings exist regardless of instance sizing. Single-task throughput rarely exceeds 100,000 rows per second for heterogeneous migrations. Achieving higher aggregate throughput requires parallelizing across multiple tasks, each handling distinct table sets. This parallelization introduces coordination complexity and increases resource requirements.

CDC limitations vary by source engine. Some databases require supplemental logging configuration that impacts source performance. Others limit CDC to specific table types or require particular version levels. PostgreSQL logical replication, for example, requires PostgreSQL 10 or later with wal_level set to logical.

Conclusion

AWS DMS has matured into a comprehensive migration platform that handles scenarios from simple same-engine moves to complex cross-platform transformations. The 2025-2026 feature additions, particularly PostgreSQL 17 support, IAM authentication, and enhanced data resync capabilities, address gaps that previously required custom tooling or manual intervention.

Success with DMS requires understanding the architectural trade-offs between homogeneous and heterogeneous approaches. Right-sizing resources for your specific workload characteristics matters. Implementing validation practices that catch discrepancies before they impact production is essential.

The serverless deployment model eliminates much of the capacity planning burden that historically complicated migration projects, though cost modeling must account for the premium charged for this flexibility. As organizations continue modernizing database infrastructure, DMS will likely expand its Zero-ETL integrations and native utility support, further blurring the line between migration tooling and ongoing replication infrastructure.

For teams planning migrations today, investing time in thorough pre-migration assessment and establishing robust validation pipelines yields returns that far exceed the upfront effort.