Cargando...
Cargando...
Migrate databases to AWS with minimal downtime — homogeneous or heterogeneous, on-premises or cloud-to-cloud.
AWS Database Migration Service (DMS) enables fast, secure, and reliable migration of relational databases, data warehouses, NoSQL databases, and other data stores to AWS. It supports both homogeneous migrations (e.g., Oracle to Oracle) and heterogeneous migrations (e.g., Oracle to Aurora PostgreSQL), with continuous data replication to minimize downtime. DMS keeps the source database fully operational during migration, making it ideal for production workloads that cannot afford extended maintenance windows.
Continuously replicate and migrate database workloads to AWS with minimal disruption to production systems, supporting one-time full loads, ongoing CDC (Change Data Capture), or both simultaneously.
Use When
Avoid When
Full Load Migration
Migrates all existing data from source to target in bulk. Can run standalone or combined with CDC.
Change Data Capture (CDC)
Continuously replicates ongoing changes after full load using transaction logs. Enables near-zero downtime cutover.
Full Load + CDC (combined mode)
Most common production migration pattern: full load first, then CDC to keep target in sync until cutover.
Multi-AZ Replication Instance
Provisions a standby replica in a different AZ for automatic failover. Adds cost but recommended for production migrations.
DMS Serverless
Auto-scales capacity (DCUs) based on workload. No replication instance management. Ideal for variable or unpredictable workloads.
Encryption at Rest (replication instance storage)
Uses AWS KMS to encrypt replication instance storage. Enabled at instance creation — cannot be changed post-creation.
Encryption in Transit (SSL/TLS)
Supports SSL between DMS and source/target endpoints. Certificate management is the customer's responsibility for custom CAs.
AWS Secrets Manager integration
DMS can retrieve endpoint credentials from Secrets Manager instead of storing them in plaintext in the DMS endpoint configuration.
AWS KMS integration
KMS CMKs used for encrypting replication instance storage and DMS task logs. Supports both AWS-managed and customer-managed keys.
CloudWatch Metrics & Alarms
DMS publishes task-level metrics (CDCLatencySource, CDCLatencyTarget, FullLoadThroughputRowsSource) to CloudWatch for monitoring.
CloudTrail Logging
All DMS API calls (CreateReplicationTask, StartReplicationTask, etc.) are logged in CloudTrail for audit and governance.
Event Notifications (SNS)
DMS can send event notifications to SNS topics for task state changes, instance events, and endpoint test failures.
DMS Fleet Advisor
Discovers on-premises database inventory and recommends migration targets. Integrates with DMS Schema Conversion for assessment.
Table Mapping & Transformation Rules
JSON-based rules to filter tables, rename schemas/tables/columns, add columns, or convert data types during migration.
LOB (Large Object) Support
Three modes: Limited LOB (truncate to max size), Full LOB (complete, slower), Inline LOB (optimized for small LOBs).
Homogeneous Migration Support
MySQL to RDS MySQL, Oracle to RDS Oracle, etc. Schema conversion not required — DMS handles data movement directly.
Heterogeneous Migration Support
Requires AWS SCT for schema/code conversion. DMS handles the data movement after schema is converted.
VPC Endpoint Support (DMS Serverless)
DMS Serverless requires VPC endpoints for private connectivity to AWS services. Internet Gateway is NOT supported for DMS Serverless.
Data Validation
DMS can validate that data was migrated accurately by comparing source and target row counts and checksums. Adds overhead but critical for compliance migrations.
Premigration Assessment
Runs automated checks before migration to identify potential issues (unsupported data types, missing permissions, etc.).
Heterogeneous Database Migration
high freqAWS SCT converts the source schema (DDL, stored procedures, views, triggers) to the target engine's syntax. DMS then handles the actual data migration (full load + CDC). SCT is run first, DMS second. SCT is a client-side tool — it runs on your workstation or EC2 instance, not as a managed service.
Encryption of Replication Instance Storage and Task Logs
high freqKMS CMKs (customer-managed keys) encrypt data at rest on the DMS replication instance storage and DMS task logs. The key must be specified at replication instance creation — it cannot be changed after creation. For compliance-sensitive migrations, always use a customer-managed KMS key rather than the AWS-managed DMS key.
Secure Endpoint Credential Management
high freqInstead of embedding database usernames and passwords directly in DMS endpoint configurations (which stores them encrypted in DMS metadata), DMS can reference a Secrets Manager secret ARN. DMS retrieves credentials dynamically at runtime. This supports automatic secret rotation without updating DMS endpoint configurations manually.
Migration Audit and Compliance Logging
high freqAll DMS control-plane API calls (creating tasks, modifying endpoints, starting/stopping tasks) are captured in CloudTrail. For regulated industries (HIPAA, PCI-DSS), CloudTrail provides the audit trail of who initiated migrations, when, and with what parameters. CloudTrail does NOT log the actual data being migrated — only the API actions.
Private Network Migration (DMS Serverless)
high freqDMS Serverless has no public IP and must communicate with source and target endpoints through private network paths. VPC endpoints (Interface Endpoints via PrivateLink) are required for DMS Serverless to reach AWS services like Secrets Manager, KMS, S3, and CloudWatch without traversing the public internet. An Internet Gateway alone is NOT sufficient.
Real-Time CDC Streaming to Downstream Consumers
medium freqDMS can use Kinesis Data Streams as a target endpoint, streaming database change events (inserts, updates, deletes) in near-real-time. Downstream consumers (Lambda, Kinesis Data Analytics, Kinesis Firehose) process the change stream for use cases like real-time analytics, cache invalidation, or event-driven microservices.
S3 as Migration Staging and Data Lake Target
medium freqDMS can write migrated data to S3 in CSV or Parquet format. This is used as a staging area before loading into Redshift (via COPY command), as a data lake target, or for archival of database snapshots. S3 can also be a DMS SOURCE for loading flat-file data into relational databases.
Data Warehouse Migration
medium freqDMS migrates OLTP data or entire data warehouse schemas to Amazon Redshift. DMS uses S3 as an intermediate staging area when writing to Redshift (data is staged in S3, then bulk-loaded via COPY). AWS SCT handles the DDL conversion from source warehouse schemas (Teradata, Oracle DW, SQL Server) to Redshift-compatible SQL.
Event-Driven Migration Orchestration
medium freqLambda functions triggered by DMS SNS event notifications can automate migration workflows: automatically starting CDC after full load completes, sending Slack/PagerDuty alerts on task failure, triggering post-migration validation scripts, or updating DNS/connection strings after cutover.
DMS encrypts data at rest (replication instance storage) AND in transit (SSL/TLS to endpoints). Both must be explicitly configured — neither is on by default for all scenarios. Exam questions that say 'DMS only encrypts data in transit' are WRONG.
DMS Serverless does NOT have a public IP address. It operates entirely within your VPC. To connect DMS Serverless to AWS services (KMS, Secrets Manager, S3), you MUST use VPC Interface Endpoints (PrivateLink). An Internet Gateway cannot substitute — this is a top exam trap.
For heterogeneous migrations (different source and target database engines), the workflow is ALWAYS: (1) Use AWS SCT to convert schema/code objects, (2) Apply converted schema to target, (3) Use DMS to migrate data (full load + CDC). SCT handles schema; DMS handles data. Never use DMS alone for heterogeneous schema conversion.
DynamoDB can ONLY be a TARGET in DMS — it is NOT a supported source endpoint. If an exam question asks about migrating FROM DynamoDB to another database using DMS, that is incorrect. Use DynamoDB Streams + Lambda or AWS Glue for DynamoDB-as-source scenarios.
KMS encryption on a DMS replication instance is set at CREATION TIME and cannot be modified afterward. If you need to change the KMS key, you must create a new replication instance. This matters for compliance scenarios where you need to switch from an AWS-managed key to a customer-managed key.
DMS encrypts BOTH at rest (KMS on replication instance storage + logs) AND in transit (SSL/TLS). Neither is automatic for all scenarios — both must be explicitly configured. 'DMS only encrypts in transit' is always WRONG.
DMS Serverless has NO public IP — requires VPC Interface Endpoints (PrivateLink) for connectivity to AWS services. An Internet Gateway CANNOT substitute. Standard DMS instances CAN use public IPs. Know the difference.
Heterogeneous migrations REQUIRE AWS SCT for schema conversion FIRST, then DMS for data migration. DMS alone cannot convert Oracle PL/SQL to PostgreSQL. SCT is FREE. Order: SCT converts schema → DMS moves data.
CloudTrail logs DMS API ACTIONS (control plane), NOT the actual data being migrated (data plane). For data-level auditing of what records changed, use DMS task logs in CloudWatch or enable data validation. This distinction appears in security and compliance exam questions.
For CDC to work, the source database must have transaction logging enabled with sufficient retention: Oracle needs Supplemental Logging (ALL COLUMNS recommended), SQL Server needs MS-CDC or MS-Replication enabled, MySQL/Aurora MySQL needs binary logging (binlog_format=ROW). Missing these prerequisites causes CDC task failures.
Multi-AZ DMS replication instances provide HIGH AVAILABILITY (failover), NOT read scaling. The standby instance is passive and does not process tasks — it only takes over if the primary fails. Do not confuse with RDS Multi-AZ or Aurora read replicas.
AWS SCT is a FREE downloadable desktop/EC2 application — it is NOT a managed AWS service and has NO per-use charge. It generates a database migration assessment report showing the percentage of code that can be auto-converted vs. requires manual effort. This report is a key input for migration planning questions.
DMS can write CDC events to Amazon Kinesis Data Streams or Amazon MSK (Kafka) as targets. This enables real-time event streaming from relational databases without application changes — a key pattern for modernization questions on SAP-C02 and DEA-C01.
DMS Secrets Manager integration allows endpoint credentials to be stored and rotated in Secrets Manager without updating DMS endpoint configurations. The DMS IAM role must have secretsmanager:GetSecretValue permission. This is the recommended approach for production migrations where credentials rotate regularly.
When migrating to Amazon Redshift, DMS uses Amazon S3 as an intermediate staging area automatically. Data is written to S3 first, then bulk-loaded into Redshift using the COPY command. This is done internally by DMS — you do not need to manage this manually, but you DO need to ensure the DMS replication instance has IAM permissions to write to the staging S3 bucket.
Common Mistake
DMS only encrypts data in transit (SSL/TLS) — data at rest on the replication instance is not encrypted.
Correct
DMS supports BOTH encryption in transit (SSL/TLS between DMS and endpoints) AND encryption at rest (KMS encryption of replication instance storage and task logs). Both must be explicitly configured. Encryption at rest is set at replication instance creation using a KMS key and cannot be changed afterward.
This is the #1 DMS security misconception on exams. Questions about DMS encryption compliance will specifically test whether you know both layers exist. Remember: DMS has TWO encryption surfaces — the wire (SSL) and the disk (KMS). Compliance scenarios requiring encryption at rest must use a KMS-encrypted replication instance.
Common Mistake
DMS Serverless has a public IP address just like standard DMS replication instances, so you can use an Internet Gateway for connectivity.
Correct
DMS Serverless operates entirely within your VPC and has NO public IP address. It cannot use an Internet Gateway for outbound connectivity to AWS services. You MUST configure VPC Interface Endpoints (AWS PrivateLink) for DMS Serverless to reach services like Secrets Manager, KMS, S3, and CloudWatch Logs. Standard DMS replication instances CAN have public IPs when deployed in public subnets — DMS Serverless cannot.
This distinction is specifically called out in exam question banks. The trap is assuming DMS Serverless behaves like standard DMS for networking. Remember: Serverless = VPC-only, no public IP, VPC endpoints required. Standard = can be public or private subnet.
Common Mistake
AWS DMS handles both schema conversion AND data migration for heterogeneous migrations (e.g., Oracle to Aurora PostgreSQL).
Correct
DMS handles DATA migration only. For heterogeneous migrations, AWS Schema Conversion Tool (SCT) is required to convert the database schema, stored procedures, functions, triggers, and views from the source engine's syntax to the target engine's syntax. The correct order is: SCT converts schema → Apply converted schema to target → DMS migrates data (full load + CDC).
This misconception causes candidates to select DMS-only answers for heterogeneous migration scenarios. The key differentiator: if the question mentions different source and target database engines AND asks about schema/code conversion, SCT is required. DMS alone cannot convert Oracle PL/SQL to PostgreSQL PL/pgSQL.
Common Mistake
DMS task logs and metadata are NOT encrypted — only the data being migrated is encrypted.
Correct
DMS task logs (stored on the replication instance and optionally in CloudWatch Logs) ARE encrypted using KMS when the replication instance has encryption at rest enabled. The KMS key specified at replication instance creation encrypts ALL data on that instance's storage, including task logs, cached transactions, and intermediate data — not just the migrated data.
Exam questions specifically test whether candidates know that DMS KMS encryption covers logs and metadata, not just the migrated data payload. This matters for compliance frameworks that require encryption of all data at rest, including operational logs.
Common Mistake
You can use DMS to migrate FROM DynamoDB to a relational database.
Correct
DynamoDB is a SUPPORTED TARGET in DMS but is NOT a supported source endpoint. You cannot use DMS to read change data from DynamoDB. For DynamoDB-as-source scenarios, use DynamoDB Streams combined with AWS Lambda or AWS Glue to export and transform data.
This is a classic endpoint confusion trap. DMS supports many sources and targets, but they are NOT symmetric — not every target can be a source and vice versa. Always verify directionality: DynamoDB = target only, S3 = both source and target, Kinesis = target only.
Common Mistake
Server-side encryption (SSE) configured on the S3 target bucket is the same as DMS encryption — enabling SSE on S3 means DMS data is encrypted.
Correct
SSE on S3 encrypts data AFTER it arrives in S3 (at the S3 layer). DMS replication instance encryption at rest (KMS) encrypts data ON THE REPLICATION INSTANCE during processing. These are separate encryption layers at different points in the data flow. For end-to-end encryption, you need: SSL in transit (DMS ↔ endpoints) + KMS on replication instance (at rest during processing) + SSE on target S3 bucket (at rest in S3).
Confusing server-side encryption with client-side/in-transit encryption is a broad AWS exam trap, and DMS questions specifically test this for migration scenarios. Remember: encryption is layered — each hop in the data flow has its own encryption consideration.
DMS = Data Moves Securely: D=Data migration, M=Minimal downtime via CDC, S=Schema conversion needs SCT (not DMS alone)
For DMS encryption, remember 'WIRE + DISK': WIRE = SSL/TLS in transit, DISK = KMS at rest on replication instance. Both are needed for full compliance.
DMS Serverless = 'No IP, No IGW, Need VPC Endpoints' — Serverless has NO public IP, so Internet Gateway won't help; you NEED VPC Interface Endpoints.
DynamoDB direction: DMS can DELIVER TO DynamoDB (target only) but cannot DRAW FROM DynamoDB (not a source). D-D = Deliver to DynamoDB.
SCT before DMS: 'Schema Converts Then Data Moves' — SCT handles schema conversion FIRST, then DMS moves the data. Never skip SCT for heterogeneous migrations.
CDC prerequisites by engine: Oracle=Supplemental Logging, SQL Server=MS-CDC, MySQL=binlog ROW format. Remember 'O-S-M' = Oracle-SQLServer-MySQL, each needs its own log config.
CertAI Tutor · SAA-C03, SAP-C02, DEA-C01, DOP-C02, SCS-C02, CLF-C02 · 2026-02-22