AWS DMS Cost Optimization: How to Reduce Database Migration Costs

Database migrations rarely go exactly as planned. What starts as a straightforward lift-and-shift often becomes a multi-week parallel-running window with mounting costs. AWS Database Migration Service promises to simplify the process, but without careful planning, the bill can surprise you.

The challenge isn't just the sticker price—it's the hidden costs. An over-provisioned replication instance running 24/7 when you only need it for weekend cutovers. Storage accumulating for tasks you forgot to delete. Cross-region data transfer you didn't account for.

This guide cuts through the complexity. You'll learn how DMS pricing actually works, where costs hide, and how to optimize every component—from instance selection to CDC configuration—without sacrificing migration performance.

What is AWS DMS?

AWS Database Migration Service (DMS) is a managed migration and replication service for moving relational databases and other database platforms to, from, or within AWS. AWS DMS features include one-time migrations, ongoing replication, change data capture (CDC), database schema conversion, data validation, and monitoring — all of which can affect cost depending on how long they run and how they’re configured.

How AWS DMS Pricing Works

AWS DMS pricing has four main cost drivers: replication compute, storage, data transfer, and commitment-based discounts.

Replication Instances and DMS Serverless

AWS DMS offers two fundamentally different pricing models, and choosing the wrong one can double your costs.

Provisioned replication instances work like traditional EC2: you pick an instance class (T3, C5, R5), pay per hour, and manage capacity yourself. A dms.r5.large costs roughly $0.176/hour whether it's migrating 10 GB or sitting idle. If your migration takes three weeks, that's $127/month for compute alone.

AWS DMS Serverless auto-scales based on workload, billing by the DCU (DMS Capacity Unit) hour. One DCU equals 2 GB of RAM. It sounds flexible — and it is — but Serverless does not eliminate idle cost entirely. Your replication can scale down only to the minimum DCU capacity you configure, so a workload that runs intermittently may still accrue baseline charges between active migration periods.

A pitfall for Serverless is to pay for minimum capacity 24/7, even when nothing's running. For burst migrations that complete in days, provisioned instances often cost less. For long-running CDC replication with variable load, Serverless wins—but only if you tune the min/max DCU thresholds correctly.

Homogeneous migrations (same database engine, like MySQL to RDS MySQL) can use a pay-as-you-go service model with no replication instance charges. But most real-world migrations involve engine conversions, which require full DMS infrastructure.

Storage

Every replication instance includes base storage—50 GB for T-class instances, 100 GB for C and R classes. Beyond that, you pay for EBS volumes attached to the instance. Most production DMS migrations use 100 GB to 500 GB of replication storage, costing $11.50 to $57.50 per month at gp2 rates.

Here's what teams miss: storage accumulates. DMS caches transactional data logs, stores full-load snapshots, and keeps validation data. If you run multiple migrations concurrently, each task consumes storage independently. And if you forget to delete old tasks after cutover? You're paying for storage indefinitely.

Even stopped instances continue accruing storage costs. The compute charge drops to zero, but the EBS volume remains attached and billed. Delete the instance entirely to stop the meter.

Data Transfer

Data transfer in to AWS is free. Data moving between DMS and databases in the same Availability Zone is also free. That covers most migrations—DMS instance and RDS target in the same AZ, no charges.

Cross-region replication changes the equation. Migrating from us-east-1 to eu-west-1? Standard inter-region transfer rates apply. Same for cross-account migrations: free within the same region, charged for cross-region hops.

The real cost surprise comes from misconfigured network paths. If your DMS instance can't reach the target via private subnets and routes over the public internet, you'll pay egress rates. Design the VPC topology carefully—keep DMS, source, and target on the same network segment whenever possible.

Database Savings Plans

Database Savings Plans cover DMS replication instances along with RDS, Aurora, and other database services. Commit to a dollar amount per hour (say, $10/hour) for one year, and AWS applies discounts—up to 35% for sustained workloads.

The catch: Savings Plans make sense for ongoing replication, not one-time migrations. If you're running continuous CDC from on-premises to AWS, the commitment pays off. For a two-week cutover project, you're better off with on-demand pricing.

AWS DMS Cost Optimization Strategies

Here are the top six strategies to optimize your AWS DMS usage and costs.

1. Choose the Right AWS DMS Deployment Model

Most teams default to Serverless because it sounds simpler. But autoscaling comes with its own pitfalls.

Comparison: DMS Deployment Options

Use provisioned instances when you have a focused migration window and can rightsize capacity in advance. Spin up a dms.r5.large for a weekend cutover, delete it Sunday night. Total cost: ~$8 for 48 hours.

Use DMS Serverless for ongoing CDC replication that runs for months. The auto-scaling absorbs traffic spikes, but you're committed to minimum capacity around the clock. Set min DCU as low as your baseline load allows—don't default to the AWS recommendation of 2 DCU if 1 DCU handles 90% of your traffic.

Use homogeneous migrations whenever source and target engines match exactly. No schema translation means no replication instance overhead. You pay only for data transfer (which is free within AWS) and target database writes.

2. Right-Size Your Replication Instance

Over-provisioning is the easiest way to waste money. Teams pick dms.r5.2xlarge "to be safe," then discover their migration averages 20% CPU utilization.

Start small and scale up based on actual metrics. For most migrations under 1 TB, dms.t3.large or dms.c5.large suffice. Monitor CloudWatch metrics during the initial full load:

• CPUUtilization sustained >80%: Scale up one instance class
• FreeableMemory <2 GB: Move to a memory-optimized (R-class) instance
• SwapUsage >0: You're swapping to disk; add RAM immediately
• NetworkReceiveThroughput saturating the instance limit: Move to a class with higher network performance

Large objects (LOBs) consume memory unpredictably. DMS loads the full LOB into memory before writing to the target. If you're migrating tables with multi-megabyte BLOB or TEXT columns, you need headroom. Use the limited LOB mode and set max LOB size to control memory usage—at the cost of truncating oversized objects.

Transaction frequency matters more than data volume. A 100 GB database with 10,000 transactions/second stresses DMS far more than a 10 TB database with 100 transactions/second. High-frequency CDC workloads need compute-optimized (C-class) or memory-optimized (R-class) instances to handle log processing throughput.

3. Optimize Data Transfer Costs

Keep everything in the same region and Availability Zone. Simple rule: if your source is in us-east-1a and your target is RDS in us-east-1a, put your DMS instance in us-east-1a. Keeping the source and target in the same AWS region avoids transfer charges.

Cross-AZ transfers cost $0.01/GB in each direction. For a 5 TB migration, that's $50 outbound + $50 inbound = $100 in transfer fees you could avoid by collocating the DMS instance with the target.

Multi-AZ replication instances cost roughly double (two instances across AZs). Use Multi-AZ only for production CDC workloads where downtime isn't acceptable. For one-time migrations, single-AZ cuts your compute bill in half.

Cross-region migrations incur full inter-region data transfer charges—$0.02/GB (us-east-1 to us-west-2) or higher for international hops. Data compression can reduce migration data transfer costs by lowering the total GB moved across Regions or over the internet. If you must migrate cross-region, stage data in S3 in the source region, then use S3 replication to move it to the target region, then load from S3 into the target database. It's more complex, but it can save 50%+ on transfer fees for multi-TB migrations.

Region selection also affects migration cost, since AWS pricing varies by Region; when latency, compliance, and service availability allow, compare target Region pricing before committing to a migration plan. Selecting an optimal AWS region can reduce costs by up to 20%.

4. Reduce Storage Costs

Default storage allocations are conservative. AWS provisions 100 GB for most replication instances, but small migrations may only consume 10-20 GB. Right-size storage based on your data volume:

• <500 GB migration: 50 GB storage
• 500 GB – 2 TB: 100 GB storage
• 2 TB – 10 TB: 200-400 GB storage
• >10 TB: 500+ GB, monitor utilization

Delete completed tasks immediately after cutover. Each task holds replication logs, cached rows, and validation snapshots. Leaving tasks in "stopped" state consumes storage indefinitely.

Use gp3 instead of gp2 volumes if you're on a newer DMS version. gp3 offers 20% lower baseline cost ($0.08/GB-month vs $0.10/GB-month) with configurable IOPS independent of volume size. For DMS workloads that don't need sustained high throughput, gp3 at 3,000 baseline IOPS handles most migrations fine.

Snapshot and delete the entire replication instance after cutover. If you need to rerun the migration, recreate the instance from scratch. The cost of keeping an idle instance for "just in case" scenarios typically exceeds the setup time to rebuild it.

5. Minimize the Parallel Migration Window

Every day both systems run concurrently costs you twice—source database costs, target database costs, and DMS replication costs all running simultaneously.

Cut over in waves, not all-at-once. Migrate data in non-critical tables first, validate them, then cut over production tables in batches. This shortens the window where the entire application stack is replicated live.

Run validation tasks during the full load phase, not after. DMS can validate row counts and sample data while migrating, surfacing discrepancies early. Discovering validation failures two weeks into a parallel-running window forces you to extend the window and double your costs.

For CDC-enabled migrations, set a specific cutover target: "Replication lag <10 seconds for 4 consecutive hours." Once you hit that threshold, cut over immediately. Teams that leave CDC running "until we're comfortable" often end up with 30-day parallel windows when 7 days would have sufficed.

6. Optimize Ongoing Replication and CDC Costs

If you're running continuous data replication indefinitely, DMS becomes an always-on operational cost. Optimize it like production infrastructure.

Batch transactions on the source when possible. High-frequency updates to the same rows cause DMS to process thousands of redundant transactions. If your application updates a counter column 100 times per second, batch those updates into one transaction every 10 seconds. DMS processes 10 transactions instead of 1,000.

Partition large tables into multiple tasks. Instead of one task replicating a 10 TB table, split it into ten tasks handling 1 TB each, filtered by date ranges or ID ranges. DMS processes them in parallel, reducing total replication time and allowing you to use smaller instances.

Tune task settings for throughput:

• `ParallelLoadThreads`: 8-16 for large migrations
• `BatchApplyEnabled`: true (applies changes in batches instead of row-by-row)
• `CommitRate`: 10,000-50,000 rows per batch depending on target database write capacity

Monitor replication lag obsessively. If lag creeps above 300 seconds, your instance is undersized for the CDC load. Scale up before lag compounds into hours of backlog.

7. Monitor, Review, and Continuously Optimize

Set up CloudWatch alarms for every replication instance:

• CPUUtilization >80% for 15 minutes
• FreeableMemory <2 GB
• NetworkTransmitThroughput approaching instance limit
• Replication Lag >300 seconds

Most teams set these alarms at creation, then ignore them. Review weekly during active migrations. If CPU averages 40%, you're over-provisioned—scale down. If memory stays above 10 GB free on a 16 GB instance, you don't need R-class pricing.

Tag every DMS resource by project and owner. When the successful migration completes, you need to know which instances can be deleted. Untagged, orphaned DMS instances rack up hundreds of dollars per month because nobody remembers what they were for.

Use Cost Explorer to track DMS spend by service component: compute, storage, data transfer. If storage costs are 40% of your DMS bill, you're not cleaning up old migration tasks. If data transfer is 60%, you're crossing regions or AZs unnecessarily.

Run monthly cost reviews. You can't set it and forget it —especially for long-running CDC replication. Workloads change, transaction volumes shift, and yesterday's right-sized instance becomes tomorrow's waste.

How nOps Automates AWS Cost Optimization

nOps helps teams identify where migration and database costs are coming from, spot unexpected spend changes, and optimize AWS costs across the broader environment.

• Real-Time Cost Visibility & Allocation: Track, allocate and report on DMS along with your other AWS, Azure, GCP, SaaS, Kubernetes and AI costs in a single pane of glass.
• Anomaly Detection: Get alerted when DMS or related database spend increases unexpectedly, whether from extended replication windows, higher AWS DMS replication instance usage, increased storage, or cross-region data transfer.
• Automated Commitment Management: nOps automatically manages commitments to maximize your savings and flexibility. Savings are often 20% higher than competitors.

Curious how optimized you are on AWS? A 30-minute free savings analysis shows you your current Effective Savings Rate and where the opportunities are. Setup is 5 minutes with no agents or infra changes needed.

nOps manages $4 billion in cloud spend for its customers and is rated 5 stars on G2.

Frequently Asked Questions

Let's dive into a few FAQ on how to cost optimize database migrations with AWS DMS and how to achieve DMS cost efficiency.