AWS Database Migration Architecture — Overview
Database migration is one of the most common workload migration patterns on AWS. The architecture combines AWS Database Migration Service (DMS) for data replication, AWS Schema Conversion Tool (SCT) for schema transformation, and various strategies depending on source/target compatibility and downtime tolerance. This is a core topic for SAP-C02 (migration scenarios) and DOP-C02 (automation).
MySQL / PostgreSQL
MongoDB / SAP
On-prem or other cloud
Assessment Report
Code Migration
(heterogeneous only)
Full Load (initial)
+ CDC (ongoing changes)
Validation & Monitoring
DynamoDB / Redshift
S3 (Data Lake)
OpenSearch / Neptune
Same engine (MySQL→Aurora MySQL)
No SCT needed, DMS only
Different engine (Oracle→Aurora PostgreSQL)
SCT + DMS required
Snowball Edge + DMS CDC
or Direct Connect bulk transfer
AWS Database Migration Service (DMS)
DMS replicates data from source to target with minimal downtime. It runs on a managed replication instance in your VPC.
How DMS Works
- Full Load: Migrates all existing data from source tables to target tables
- Change Data Capture (CDC): Continuously replicates ongoing changes (inserts, updates, deletes) after full load completes
- Full Load + CDC: Combines both — migrates existing data, then keeps target in sync until cutover
DMS Components
| Component | Role | Key Decisions |
|---|---|---|
| Replication Instance | Managed EC2 that runs migration tasks | Size based on data volume + number of tables. Multi-AZ for HA. |
| Source Endpoint | Connection to source database | Requires read access + CDC permissions (binary log for MySQL, LogMiner for Oracle) |
| Target Endpoint | Connection to target database/service | Requires write access. Target can be RDS, Aurora, DynamoDB, S3, Redshift, etc. |
| Migration Task | Defines what to migrate and how | Table mappings, transformation rules, LOB settings, validation |
| Table Mappings | Select/filter/transform tables and columns | Include/exclude rules, column renaming, schema renaming |
Supported Sources and Targets
| Sources | Targets |
|---|---|
| Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP ASE, IBM Db2, Azure SQL, Amazon RDS (all engines), Amazon Aurora, Amazon S3 | Amazon RDS (all engines), Amazon Aurora, Amazon Redshift, Amazon DynamoDB, Amazon S3, Amazon OpenSearch, Amazon Neptune, Amazon Kinesis, Apache Kafka, Amazon DocumentDB |
AWS Schema Conversion Tool (SCT)
SCT converts database schemas and code from one engine to another (heterogeneous migrations only):
- Schema conversion: Tables, indexes, views, constraints → target engine syntax
- Code conversion: Stored procedures, functions, triggers → target equivalent
- Assessment Report: Identifies what can be auto-converted vs what needs manual effort (red/yellow/green)
- Data Extraction Agents: For large-scale migrations, SCT agents extract data in parallel to S3, then load into target
Not needed for homogeneous migrations (e.g., MySQL → Aurora MySQL) since the schema is compatible.
Migration Strategies (The 7 Rs)
| Strategy | What It Means | Database Example |
|---|---|---|
| Rehost (Lift & Shift) | Move as-is to AWS with no changes | Oracle on-prem → Oracle on EC2 |
| Replatform | Move with minor optimizations | MySQL on-prem → RDS MySQL (managed, same engine) |
| Refactor | Change engine/architecture for cloud-native benefits | Oracle → Aurora PostgreSQL (heterogeneous, use SCT+DMS) |
| Repurchase | Move to a different product entirely | On-prem CRM database → Salesforce (SaaS) |
| Retire | Decommission — no longer needed | Legacy reporting DB replaced by Athena on S3 |
| Retain | Keep on-premises (not ready/suitable for cloud) | Mainframe DB with too many dependencies |
| Relocate | Move infrastructure (VMware) without changes | VMware VMs → VMware Cloud on AWS |
Zero-Downtime Migration Pattern
- Provision target — Create Aurora/RDS in target region/account
- SCT (if heterogeneous) — Convert and apply schema to target
- DMS Full Load + CDC — Start migration task: initial load + ongoing replication
- Validation — Enable DMS data validation to compare source vs target row counts and checksums
- Application testing — Point test/staging app at target DB, validate functionality
- Cutover — Stop writes to source → Wait for CDC to catch up (seconds) → Redirect application to target
- Decommission — Monitor target, then retire source after confidence period
Downtime: Only during step 6 (seconds to minutes — time for last CDC events to apply + DNS/connection string update).
Large-Scale Migration (TB to PB)
- Problem: Migrating 50TB+ over network takes weeks even on Direct Connect
- Solution: AWS Snowball Edge for initial bulk transfer + DMS CDC for changes during transit
- Pattern: Start CDC from Day 1 → Ship Snowball (days) → Load Snowball data to target → Apply accumulated CDC → Cutover
- Alternative: SCT Data Extraction Agents — parallel extraction to S3 via Direct Connect, then load to target
Target Database Selection
| Workload | Target | Why |
|---|---|---|
| OLTP (same engine, managed) | Amazon RDS | Same engine, minimal changes, managed infrastructure |
| OLTP (high performance, scaling) | Amazon Aurora | 5x MySQL / 3x PostgreSQL perf, auto-scaling storage, Global Database |
| Key-value / high scale NoSQL | DynamoDB | Single-digit ms latency, unlimited scale, serverless |
| Analytics / Data Warehouse | Amazon Redshift | Columnar, MPP, petabyte-scale analytical queries |
| Data Lake / Archive | Amazon S3 | Cheapest storage, query with Athena, feed ML pipelines |
| Search / Log Analytics | OpenSearch | Full-text search, log analytics, dashboards |
Exam Tips by Certification
| Exam | Focus Areas |
|---|---|
| SAP-C02 | 7Rs strategy selection, DMS+CDC for zero-downtime, SCT for heterogeneous, Snowball+DMS for large scale, target DB selection based on workload, multi-account migration patterns |
| DOP-C02 | Automating migration with DMS tasks, CDC monitoring, validation configuration, migration testing in CI/CD, rollback planning |
AWS Certification Exam Practice Questions
Question 1:
A company needs to migrate a 10TB Oracle database to Aurora PostgreSQL with less than 1 hour of downtime. The application must continue running during migration. Which approach achieves this?
- Use AWS SCT to convert schema, then pg_dump/pg_restore for data
- Use AWS SCT for schema + DMS with Full Load and CDC, then cutover after CDC catches up
- Create an Oracle RDS instance first, then use Aurora read replica promotion
- Use AWS Snowball Edge to transfer the data, then apply schema with SCT
Show Answer
Answer: B — For heterogeneous migration (Oracle → Aurora PostgreSQL) with minimal downtime: SCT converts the schema, DMS performs Full Load of existing data while application continues running, then CDC captures all changes made during migration. At cutover, stop application writes, wait for CDC to apply final changes (seconds), redirect to Aurora. Downtime is only the cutover window (minutes).
Question 2:
A company has a 50TB data warehouse they want to migrate to AWS. Network bandwidth to AWS is 1 Gbps (would take ~5 days for full transfer). They need the target ready within 2 weeks and cannot tolerate data loss. What is the MOST efficient approach?
- DMS Full Load over Direct Connect for 5 days, then CDC
- AWS Snowball Edge for bulk data + DMS CDC running in parallel from Day 1
- S3 Transfer Acceleration for faster upload
- Multiple DMS replication instances in parallel
Show Answer
Answer: B — Start DMS CDC immediately to capture all ongoing changes. Simultaneously, load the bulk 50TB onto Snowball Edge (1-2 days to load). Ship Snowball to AWS (~5 days transit). Import Snowball data to S3/target. Apply accumulated CDC changes from the past week. This approach handles both the bandwidth constraint and zero data loss requirement. DMS alone over 1 Gbps would work but Snowball is more efficient for 50TB.
Question 3:
A company is migrating from Oracle to Aurora PostgreSQL. The SCT assessment report shows 60% of stored procedures can be auto-converted, but 40% require manual intervention. The migration has a 3-month deadline. What should they prioritize?
- Rewrite all stored procedures in the application layer and remove database logic
- Convert the 60% automatically with SCT, manually convert the critical 40%, begin DMS replication in parallel
- Stay on Oracle and rehost to Oracle on EC2 instead
- Use AWS Lambda to emulate Oracle stored procedures
Show Answer
Answer: B — The practical approach: auto-convert what SCT can handle (60%), then dedicate developer effort to the remaining 40% (prioritize by business criticality). Start DMS replication in parallel so data is ready when code conversion completes. This maximizes the 3-month timeline by parallelizing schema/code work with data replication.
Question 4:
After starting a DMS migration task, a company notices some tables have row count mismatches between source and target. What DMS feature helps identify and resolve this?
- CloudWatch metrics for table statistics
- DMS data validation (automatic source-target comparison)
- DMS premigration assessment
- AWS Config compliance rules
Show Answer
Answer: B — DMS data validation compares row counts, data content, and checksums between source and target during and after migration. It identifies mismatched records and reports them in a validation table. You can then investigate and remediate specific rows. Pre-migration assessment checks connectivity and permissions before starting, not data accuracy.
Question 5:
A company wants to migrate their on-premises MySQL database to RDS MySQL. The source and target use the same engine version. What is the SIMPLEST migration approach?
- SCT for schema conversion + DMS for data migration
- DMS only (Full Load + CDC) — no SCT needed for homogeneous migration
- mysqldump export → S3 → RDS import
- Create RDS read replica from on-premises using binary log replication
Show Answer
Answer: B — Homogeneous migrations (same engine) don’t require SCT because the schema is already compatible. DMS handles both schema creation on target and data replication. Full Load + CDC provides minimal-downtime migration. mysqldump works but requires downtime during export/import. RDS external replication also works but DMS is the managed, recommended approach.
Related Architecture Patterns
Related Posts
- AWS RDS Replication – Multi-AZ & Read Replicas
- Aurora vs RDS vs DynamoDB – Selection Guide
- AWS Data Lake & Analytics Architecture
- AWS Disaster Recovery Architecture
- Hybrid Cloud Networking – Direct Connect & Transit Gateway
References
- AWS Database Migration Service User Guide
- Migrate Oracle to Aurora – AWS Database Blog
- Migrating Large Databases to AWS – Prescriptive Guidance
- Best Practices for Migrating to Amazon Aurora – AWS Blog
- Database Migration Strategy – AWS Prescriptive Guidance
Frequently Asked Questions
What is the difference between DMS and SCT?
DMS migrates the data (rows) from source to target with optional ongoing replication (CDC). SCT converts the schema and code (stored procedures, functions, triggers) from one database engine to another. For homogeneous migrations (same engine), only DMS is needed. For heterogeneous migrations (different engines), both SCT and DMS are required.
Can DMS migrate to a different AWS region?
Yes. DMS supports cross-region migration. The replication instance can be in either the source or target region. For on-premises to AWS, place the replication instance in the target region. For cross-region AWS migrations, place it in the target region for better performance (closer to where data is written).
How do I achieve zero-downtime migration?
Use DMS Full Load + CDC: the full load migrates existing data while the application continues running. CDC captures all changes made during migration. At cutover, briefly stop application writes (seconds), wait for CDC to apply final changes, then redirect the application to the new target. Total downtime: seconds to minutes.