AWS Database Migration Service

Concepts Covered

• AWS Database Migration Service
• Database migration versus file transfer
• Source and target endpoints
• Replication instances
• Migration tasks
• Full load and change data capture
• Homogeneous and heterogeneous database migration
• Schema conversion boundaries
• Security and encryption
• Cutover planning and exam traps

1. Plain-English Mental Model

AWS Database Migration Service, or AWS DMS, is database moving equipment.

The simple model is:

source database -> DMS replication layer -> target database or data store

You tell DMS where to read from, where to write to, and what kind of task to run. It can load existing data, keep copying ongoing changes, or do both. That ongoing change replication is the reason DMS appears in "minimal downtime" migration questions.

DMS is not a generic file transfer service. It understands supported database engines and data stores through connectors called endpoints. It is also not magic application modernization. If the source and target database engines differ, schema objects, stored procedures, data types, application SQL, and engine-specific behavior may need assessment and conversion work.

Think of DMS as the data movement layer for database migration, not as the whole migration project.

2. Why This Service Exists

Database migrations are painful because production databases keep changing.

If an application can be shut down for a weekend, a backup and restore may be enough. Many real systems cannot do that. Orders, user sessions, payments, events, inventory updates, and account changes keep arriving while the migration is being prepared.

The old approach is to schedule a long maintenance window, export the database, copy files, import into the target, fix errors, test quickly, and hope the application comes back cleanly. That breaks when the database is too large, the export takes too long, the network is slow, the source keeps changing, or the target engine is different.

DMS exists to reduce that pain. It can perform full loads and replicate ongoing changes so the target stays close to the source until cutover.

For SAA-C03, DMS sits in the Migration and Transfer family. It is the service to recognize when the exam says database migration, ongoing replication, heterogeneous database move, source and target endpoints, or minimal downtime database cutover.

3. The Naive Approach And Where It Breaks

The naive migration is:

stop app -> dump database -> copy dump -> restore target -> start app

This breaks when the downtime window is too small for the dataset. It also breaks when the restore fails late, when schema differences appear, or when the application has hardcoded engine-specific behavior.

Another naive approach is to treat the database like files and use a file copy tool. That ignores transactions, change ordering, data types, constraints, logs, and consistency.

A third mistake is assuming DMS converts every part of the database and application. DMS can help with data migration and AWS has schema conversion capabilities, but application code, complex stored procedures, incompatible features, permissions, and performance tuning still require engineering work.

The better mental model is:

prepare target schema -> full load -> CDC replication -> validation -> cutover

4. Core Primitives

A source endpoint describes the database or data store DMS reads from.

A target endpoint describes where DMS writes data.

A replication instance is the compute that runs the replication software in the classic DMS model. It needs CPU, memory, storage, network access, and security group rules sized for the migration workload. DMS also has serverless options, but the exam usually cares more about the migration concept than the deployment flavor.

A migration task defines what to move and how. Common modes include full load, change data capture, and full load plus ongoing replication.

Change data capture, or CDC, reads database change streams so updates after the initial load can be copied to the target.

Table mappings choose schemas and tables, include or exclude objects, and can apply transformations.

Schema conversion is separate from raw data movement. Homogeneous migrations, such as MySQL to MySQL, usually need less conversion. Heterogeneous migrations, such as Oracle to Aurora PostgreSQL, need careful schema and code assessment.

5. Architecture Use Cases

Use DMS to move an on-premises relational database to Amazon RDS or Amazon Aurora with reduced downtime:

on-premises database -> DMS -> Amazon RDS or Aurora

Use DMS for heterogeneous migrations where the organization wants to move away from a legacy or commercial database engine. Pair it with schema assessment and conversion work before the data task.

Use DMS to replicate data from operational databases into Amazon Redshift, Amazon S3, or another supported target for migration or downstream processing. Be careful: when the primary requirement is ETL transformation, AWS Glue may be the more natural service.

Use DMS for phased cutover. Load historical data first, keep CDC running, validate the target, pause writes or enter a short maintenance window, let replication catch up, then redirect the application.

7. Security Model

DMS security includes IAM permissions, endpoint credentials, VPC networking, security groups, encryption, and logging.

The replication layer must be able to reach the source and target endpoints. For private databases, that usually means VPC connectivity, routing, security groups, and possibly VPN or Direct Connect for on-premises sources.

Endpoint credentials should be scoped to the migration task. Avoid using broad administrator credentials when a migration-specific user can read required source data and write required target data.

DMS can use encryption in transit through SSL/TLS when configured and supported by endpoints. Data at rest for DMS resources can use AWS KMS.

CloudWatch logs and metrics help diagnose task failures, replication lag, table errors, and throughput limits. CloudTrail records control-plane activity.

8. Reliability And Resilience

DMS reliability depends on source availability, target availability, replication capacity, network stability, and task configuration.

For minimal downtime migrations, monitor replication lag. A target that is hours behind the source is not ready for cutover.

Validation matters. A task can complete while application-level assumptions are still wrong. Test row counts, key tables, constraints, application queries, indexes, and performance.

Use Multi-AZ or resilient configuration where the migration task itself must survive infrastructure failure. Also design the target database for production reliability. DMS moves data; it does not automatically make the target architecture resilient.

Have a rollback plan. Database cutovers are risky because writes may begin on the new system. Know whether rollback means redirecting back, replaying changes, or treating the cutover as one-way.

9. Performance And Scaling

DMS performance depends on replication compute, source database load, target write capacity, network bandwidth, table size, LOB handling, indexes, constraints, and CDC volume.

Large tables may require parallel load tuning. Heavy write workloads can generate replication lag if the target cannot keep up.

The source database is not free from impact. Full loads read data, CDC reads change logs, and network transfer uses bandwidth. Schedule and tune migrations so they do not overload production.

Target indexes and constraints can slow bulk loading, but removing them blindly can create validation and application risks. Migration projects often load data first, then build or validate indexes depending on engine and downtime constraints.

For exam purposes, "high-speed file or object transfer" is not DMS. That points to DataSync. "Lift and shift servers" is not DMS. That points to Application Migration Service.

10. Cost Model

DMS cost includes replication instance or serverless replication capacity, storage used by migration resources, data transfer, target service costs, logs, and any supporting connectivity.

The migration window affects cost. A one-day migration and a three-month CDC replication project have different economics.

Target cost also matters. Moving from self-managed databases to RDS or Aurora changes operational cost, licensing, backup cost, storage cost, and high availability cost.

Heterogeneous migrations may reduce licensing cost, but they usually increase assessment, testing, and conversion effort. The architecture decision should include engineering labor, application risk, and performance tuning, not only DMS runtime charges.

12. SAA-C03 Exam Signals

"Migrate an on-premises database to Amazon RDS with minimal downtime" points to AWS DMS.

"Keep source and target databases synchronized during migration" points to DMS with CDC.

"Homogeneous or heterogeneous database migration" points to DMS, with schema conversion considerations for heterogeneous moves.

"Move files from NFS or SMB to S3" points to DataSync, not DMS.

"Rehost physical or virtual servers to EC2" points to AWS Application Migration Service, not DMS.

"Transform data for analytics jobs" may point to AWS Glue rather than DMS.

"Migrate an entire database by restoring a snapshot" may be valid only when the downtime and engine compatibility requirements allow it.

13. Common Exam Traps

Do not choose DMS for general file transfer. DMS is database-focused.

Do not assume DMS rewrites application SQL or every stored procedure.

Do not ignore schema conversion in heterogeneous migrations.

Do not choose read replicas as a complete migration service. Replicas may help for certain engines, but DMS is the cross-engine migration answer.

Do not forget network access. DMS cannot replicate from a private on-premises source unless the replication layer can reach it.

Do not confuse CDC replication with backup. Replication can copy bad changes too. Backup and recovery planning still matter.

15. Related Topics

Review Amazon RDS and Amazon Aurora before using DMS as a target in exam scenarios.

Next, study AWS DataSync so you can separate database migration from file and object transfer.

Official AWS references:

• What is AWS Database Migration Service?
• AWS DMS sources
• AWS DMS targets