AWS DMS Replication Instance
Does ZopNight manage AWS DMS Replication Instance?
DMS replication instances bill per instance-hour from creation to deletion, plus storage and, for some paths, per-GB data transfer. An instance left running after its migration finished is the service's classic forgotten cost. ZopNight discovers instances on the 6-hour cycle, attributes cost from Cost Explorer or CUR 2.0, and flags idle replicators.
Rules that fire on AWS DMS Replication Instance
No active rule family targets AWS DMS Replication Instance today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
AWS Database Migration Service (DMS) runs replication instances that move and continuously sync data between databases. Replication instances bill hourly, and instances left running after a migration completes are a classic forgotten cost.
An hourly meter with a built-in ending
A replication instance is EC2-shaped billing wearing a migration badge: it meters per instance-hour at its size, multi-AZ doubles the rate, and allocated storage bills per GB-month alongside. What makes DMS unusual is that most of its work is supposed to end. A one-time migration has a completion date; even change-data-capture (CDC) pipelines have cutover days. The meter, of course, does not know that. It runs until someone deletes the instance, and “someone” is usually a person whose project closed weeks earlier.
Catching the finished migration
ZopNight discovers replication instances automatically on the 6-hour cycle, with per-resource cost attributed from Cost Explorer or CUR 2.0. Idle replication-instance recommendations target the signature ending: an instance whose tasks are all stopped, completed, or failed, still billing hourly. Ongoing-CDC instances are legitimate long-runners and are distinguished by task state: the recommendation aims at the instance that finished its purpose, not the one quietly keeping two systems in sync on purpose.
How migration tooling overstays
The pattern is consistent: the cutover succeeds, the team holds the replication instance “until we’re confident”, confidence arrives, the instance stays. Test instances multiply it, since sizing experiments spawn an instance per attempt and only the winner’s task gets attention at cleanup time. Serverless DMS shifts the risk rather than removing it: capacity is metered in DCUs while replication runs, which helps for spiky jobs but still bills for provisioned capacity ranges left active. And multi-AZ, correct for a production cutover window, doubles the cost of every forgotten week after it.
Reviewing replication inventory
The DMS console lists replication instances with class, storage, and multi-AZ flag, and the Database migration tasks view shows each task’s status and last-updated time. An instance whose newest task activity is months old has answered the question of whether it is still needed.