AWS Database Migration Service (DMS) — Homogeneous & Heterogeneous Migration with CDC

This lesson moves fast through a lot of database vocabulary, and most of it is assumed rather than explained. Before the DMS material proper, here are the five ideas the rest of the page quietly depends on. None of them are complicated on their own; the difficulty is that the exam expects you to hold all of them at once while reading a scenario.

Database engines are separate products, not interchangeable parts

When people say "a database," they usually mean two different things at once: the data itself, and the software that stores and serves that data. The software is the engine, and the major ones — Oracle, Microsoft SQL Server, PostgreSQL, MySQL, and MariaDB — are genuinely different products built by different companies over decades. They all speak a common language called SQL for basic queries, which is why they look similar from a distance, but each one has its own dialect, its own way of writing stored procedures, its own data types, and its own internal file formats. You cannot take a database file from Oracle and hand it to PostgreSQL and expect it to open, any more than you can run a Windows program on a Mac without some kind of translation layer. This is the single most important fact behind today's lesson: whether the source and target run the same engine or different engines changes the entire migration plan, because a same-engine move is just copying data while a cross-engine move means rewriting the schema and the code that sits on top of it.

RDS and Aurora are AWS running the database for you

Historically, running a database meant buying a server, installing the engine on it, patching the operating system, tuning the configuration, setting up backups, and handling failover yourself. Amazon RDS is AWS's answer to that: you pick an engine — RDS supports several, including SQL Server, Oracle, PostgreSQL, and MySQL — and AWS provisions the server, installs and patches the engine, takes automated backups, and can stand up a standby copy in a second data center automatically. You still connect to it and query it exactly as you would any database; you just do not administer the machine underneath. Amazon Aurora is a related but distinct service: it is a database engine that AWS built itself, designed to be compatible with either MySQL or PostgreSQL, so applications written for those engines can often talk to Aurora without changes. That is why this lesson keeps writing things like "Aurora PostgreSQL" and "RDS SQL Server" — the first word is the AWS service, the second is the engine dialect it speaks. When a migration scenario names a target like that, it is telling you which engine family you are landing in, which is exactly the information you need to decide whether schema conversion is required.

Databases keep a log of every change, and that log is how replication works

Every serious database engine writes down what it is doing before it does it. Before a row is updated, the engine records the intent to update it in a sequential file called a transaction log — Oracle calls it a redo log, MySQL calls it a binary log, SQL Server calls it a transaction log, but the idea is the same everywhere. This log exists primarily so the database can recover from a crash: if the power fails halfway through a write, the engine replays the log on restart and ends up in a consistent state. The useful side effect, and the one this entire lesson rests on, is that the log is a complete, ordered record of every change that has ever been made to the data. If you can read that log, you can reconstruct the current state of the database without ever querying the tables themselves. That is precisely what change data capture does: instead of repeatedly asking "what does this table look like now," DMS reads the log and says "here are the twelve changes that happened in the last second, apply them to the target." It is faster, it does not disturb the source, and it is why a migration can keep a target synchronized with a live production database indefinitely.

Primary keys, indexes, sequences, and triggers

Four pieces of ordinary relational database furniture come up repeatedly in the failure-mode and gotcha sections, so they are worth pinning down. A primary key is the column (or set of columns) that uniquely identifies each row in a table — an employee ID, an order number, a customer email. The database enforces that no two rows share one, and it builds an internal lookup structure around it so that finding a specific row is fast. An index is the same idea applied to other columns: a sorted lookup structure that lets the database find rows by, say, last name without reading the entire table. A sequence (or an auto-increment column, which is the same concept under a different name) is a counter the database maintains to hand out the next available ID number automatically when you insert a row. And a trigger is a small piece of logic the database runs automatically in response to an event — "whenever a row is inserted into the orders table, also write a row into the audit table." The reason all four matter today is that DMS moves rows, and none of these four things are rows. A missing primary key makes replication dramatically slower because the tool has to search for the row it wants to change. A sequence counter does not travel with the data, so the target's counter has to be manually advanced after migration or new inserts will collide with migrated ones. And triggers fire during migration just as they would during normal operation, which can produce duplicate side effects unless they are disabled first.

VPCs and Availability Zones

A VPC, or Virtual Private Cloud, is a private network you define inside AWS. It is the AWS equivalent of the network in an office building: you decide what address range it uses, you carve it into subnets, and you control what can talk to what. Nothing in AWS runs outside a VPC — every database, server, and load balancer lives inside one. An Availability Zone, or AZ, is a physically separate data center within an AWS region, with its own power, cooling, and network connections. A region like us-east-1 contains several AZs, and they are close enough together that traffic between them is fast, but far enough apart that a fire or flood in one does not take out the others. The practical consequence, and the reason this comes up in today's lab and in one of the quiz questions, is that moving data between two AZs is not free and is not instantaneous. It costs a small amount of money in data transfer charges and adds a small amount of latency to every operation. When you place a migration tool, you want it sitting next to the thing it writes to most heavily, because that is where the bulk of the traffic goes.

With that grounding, here is why DMS exists and what problem it actually solves.

DMS is built from three primitives, and almost every configuration question reduces to understanding how they interact. The first is the replication instance: an AWS-managed compute resource, running the DMS engine, that performs the actual work of reading from the source and writing to the target. It is not a control-plane abstraction — it is a real instance with real CPU, memory, and network limits, and those limits are what determine how fast your migration can go. Memory matters more than most people expect, because the instance buffers rows and cached change records in flight; when memory pressure forces it to spill to disk, throughput collapses in a way that looks like a mysterious slowdown rather than an obvious resource exhaustion.

The second primitive is the endpoint, which is nothing more than a stored connection definition for a source or a target. DMS supports a broad catalog on both sides: Oracle, SQL Server, PostgreSQL, MySQL and MariaDB, MongoDB, and SAP ASE as sources, with RDS, Aurora, Redshift, OpenSearch Service, Kinesis Data Streams, S3, and DynamoDB among the targets. The important architectural point is that endpoints are directional and independent — a source endpoint is read from, a target endpoint is written to, and the same physical database can appear as both in different tasks. This is what makes patterns like ongoing replication into a data lake possible without any notion of a "cutover" at all.

The third primitive is the task, which is where the actual decisions live. A task binds a source endpoint to a target endpoint and then specifies three things: table mappings that select which schemas and tables participate, transformation rules that can rename or filter data in flight, and the migration type that determines whether the task takes a snapshot, streams changes, or does both. Tasks are also the unit of parallelism — a single task has a practical throughput ceiling, so high-volume migrations are split across multiple tasks, often one per large table or per partition, rather than scaled up on a single enormous replication instance.

Underneath all three, DMS reads from the source using whatever mechanism that engine exposes for change tracking — transaction logs, redo logs, binary logs, or change tables — and applies changes to the target as ordinary SQL. That detail matters because it explains most of the service's limitations: if the source engine cannot cheaply identify which row changed, DMS cannot either, and the cost of that identification shows up directly in replication latency.

The most instructive DMS failures are the ones that do not announce themselves. A migration task that is running but falling further behind looks identical in the console to one that is keeping up, unless you are watching the right metric. The two that matter most are CDCLatencySource and CDCLatencyTarget, which split replication lag into its two halves: source-side latency measures how long it takes DMS to read changes out of the source transaction log, and target-side latency measures how long it takes to apply them. When a migration is falling behind, the first diagnostic move is always to check which of those two is growing, because the remediation is completely different depending on the answer.

Rising source-side latency usually means DMS cannot read the change stream fast enough. The classic cause is a table without a primary key or unique index, which forces DMS to identify changed rows by scanning rather than by direct lookup; the cost of that identification grows with table size, so the symptom is a migration that starts fine and degrades as the dataset grows. Rising target-side latency points at the apply side instead, and the usual culprits are an undersized target instance, missing indexes on the target that make each apply expensive, or triggers on the target firing for every replicated row. Both of these are diagnosable from the metrics alone, which is why the exam likes them: the scenario gives you a symptom and expects you to name the metric that would distinguish the two causes.

A third class of failure is silent data loss rather than lag. Limited LOB mode with a threshold set below the actual maximum object size will truncate data without failing the task, and a partitioned table that is not explicitly configured in the table mappings can be partially or entirely skipped. These are the failures that surface after cutover, when the source has already been decommissioned and the discrepancy is discovered by an application rather than by monitoring. The defense is validation, which is covered in the next section, and the reason it is worth calling out here is that these failures are invisible to every metric DMS publishes — the task reports success while having moved the wrong data.

The migration toolchain contains four services that are easy to conflate because they all move something from on-premises to AWS, and the exam exploits that overlap deliberately. The clean way to keep them apart is to ask what unit of work each one operates on: DMS operates on database rows, SCT operates on schema and code, MGN operates on whole servers, and DataSync operates on files and objects. Once you have identified the unit, the correct tool follows almost mechanically, and the distractors stop being tempting.

The pairing that matters most is DMS with SCT, because they are complementary rather than alternatives. A heterogeneous migration needs both, in sequence: SCT converts the schema and reports what it could not convert, a developer remediates the remainder, the converted schema is applied to the target, and then DMS moves the data with CDC to keep downtime minimal. Scenarios that describe an engine change and then offer DMS alone as an answer are testing whether you noticed that the schema conversion step is missing.

The exam's favorite disguise is a scenario that buries the engine pairing in a paragraph of unrelated detail and then offers MGN or DataSync as plausible answers. If the question is about a database and the engines differ, the answer is SCT plus DMS. If the question is about a database and the engines match, the answer is DMS alone with a pre-created schema. If the question is about a server or a file share, neither DMS nor SCT belongs in the answer at all.