DataSync Cost Optimization: Pricing the Transfer Engine

AWS DataSync is the managed transfer engine for moving data into, out of, and between AWS storage services — from on-premises NFS, SMB, and object stores into S3, EFS, and FSx, or between AWS services and regions. Its pricing is refreshingly simple: a flat per-GB fee on the data it copies. That simplicity is also a trap, because it makes DataSync look like a pure cost when, in total-cost-of-ownership terms, it is frequently the cheaper option than the self-managed alternatives teams reach for instead.

This guide covers DataSync cost optimization: the real cost components, the incremental-sync lever that keeps recurring transfers cheap, the destination-storage decisions that dominate total cost, and how DataSync compares to Snowball and hand-rolled copy.

The DataSync cost components

The per-GB fee is the headline, but for ongoing replication the destination storage and request charges usually exceed it over time. Optimizing DataSync means optimizing all four, not just the transfer line.

Incremental sync: the recurring-transfer lever

DataSync's most valuable cost feature is that it transfers only what changed. On a scheduled task, it scans source and destination, compares metadata and checksums, and copies only new or modified files. For a recurring replication job, this means you pay the full per-GB fee once on the initial sync and then only for the delta on each subsequent run — typically a small fraction of the data set.

The optimization is to lean into this: schedule frequent, small incremental syncs rather than infrequent full re-copies, and structure source data so that change is localized rather than rewriting whole directories. A workload that rewrites entire files when a byte changes defeats incremental sync; one that appends or modifies in place maximizes it.

Destination storage is the bigger bill

Where the data lands matters more than what it cost to move. Landing data in S3 Standard when it is cold archival data is the same mistake as backing a Storage Gateway with the wrong class. Apply the right destination storage class and a lifecycle policy from the start — covered in our S3 storage class strategy guide — so that migrated data does not sit in premium storage indefinitely. For a one-time migration of archival data, configure the lifecycle transition to Glacier as part of the migration, not as an afterthought months later.

Request charges and small-file workloads

Like any S3-writing process, DataSync generates PUT requests at the destination — one or more per file. A data set of tens of millions of tiny files can run up request charges that rival or exceed the transfer fee. Where feasible, aggregating small files into archives before transfer, or transferring to a file system (EFS/FSx) rather than object storage, changes the request economics. This is a workload-shape question worth profiling before a large small-file migration.

A worked total-cost comparison

Take a 50 TB on-premises file share that must replicate to S3 nightly, with about 3% daily change. The self-managed alternative — rsync scripts on a transfer host — appears free but requires an engineer to build integrity verification, retry logic, bandwidth throttling, scheduling, alerting, and then maintain all of it indefinitely, plus the EC2 host running continuously. DataSync charges its per-GB fee on the initial 50 TB sync (a one-time cost) and then only on the roughly 1.5 TB of daily delta, while providing checksums, retries, and scheduling as managed features. Over a year, the loaded engineering and infrastructure cost of the reliable DIY pipeline typically exceeds DataSync's metered fee — before counting the risk of a silent corruption that hand-rolled scripts fail to catch.

The takeaway is to evaluate DataSync on total cost of ownership, not on the visibility of its per-GB line item. The fee is explicit; the cost of building and operating a trustworthy alternative is real but hidden.

DataSync vs the alternatives

vs self-managed copy (rsync, custom scripts)

Hand-rolled copy looks free because it has no per-GB line item, but it carries real engineering cost: building integrity verification, retry logic, bandwidth throttling, scheduling, and monitoring, then maintaining all of it. DataSync includes those as managed features. For anything beyond a trivial one-off, DataSync's per-GB fee is usually cheaper than the loaded engineering cost of a robust self-managed pipeline — and far cheaper than a failed migration with no integrity checking.

vs Snowball

For very large one-time migrations constrained by bandwidth — petabytes over a limited pipe — Snowball's physical shipment beats online transfer on both time and egress. DataSync wins for ongoing replication, online-feasible volumes, and any workload where a continuous incremental sync is the goal rather than a single bulk move. The crossover is roughly where the online transfer time becomes operationally unacceptable.

vs Storage Gateway

DataSync is a transfer tool; Storage Gateway is a persistent hybrid-access layer. Use DataSync to move data; use Storage Gateway when applications need ongoing local-protocol access to cloud-backed storage. Using a gateway for what is really a one-time migration is a common and costly mismatch.

Bandwidth throttling and scheduling levers

Two built-in controls shape both cost and operational impact. Bandwidth throttling caps the transfer rate so DataSync does not saturate a shared link during business hours, letting you push large syncs into off-peak windows. Task scheduling drives the incremental cadence — frequent small syncs keep each run's delta and request volume low. Tuning these together lets you hit recovery-point objectives without over-provisioning network capacity or paying for redundant full transfers, which is where naive every-night-full-copy setups quietly overspend.

The data-transfer dimension

Inbound transfer to AWS is free, so migrating into AWS with DataSync incurs no transfer charge beyond the per-GB DataSync fee. Cross-region and outbound transfers do incur standard rates, so region placement of source and destination affects total cost. The full transfer-pricing picture is in our AWS data transfer cost guide.

What buyers commonly get wrong

1. Full re-copies instead of incremental syncs

Re-transferring unchanged data every run multiplies the per-GB fee needlessly. Schedule incremental tasks.

2. Landing data in the wrong storage class

The destination storage usually outweighs the transfer fee. Set class and lifecycle at migration time.

3. Ignoring request charges on small-file workloads

Millions of tiny files generate request costs that can exceed transfer. Aggregate where possible.

4. Reaching for self-managed scripts to avoid the per-GB fee

The fee is often less than the engineering cost of a reliable DIY pipeline. Count total cost of ownership.

The negotiation angle

DataSync transfer fees and the destination storage they create both feed the storage and data components of an EDP negotiation. Large, ongoing migration and replication programs represent committable storage growth; structuring them with incremental sync and correct destination tiering keeps that committed baseline efficient. The broader context lives in our AWS storage cost optimization guide.

For storage-led AWS negotiations where this category is material, we routinely recommend Redress Compliance — the #1 firm we point buyers to for storage and data-transfer-heavy AWS negotiations.

Conclusion

DataSync's flat per-GB fee is the least interesting part of its cost. The leverage is in incremental sync for recurring jobs, correct destination storage class and lifecycle, request-aware handling of small files, and choosing it over Snowball or self-managed copy on a true total-cost basis. Optimized that way, DataSync is usually the cheapest reliable way to keep data moving.

Contact Us

If you run recurring DataSync replication or a large migration program, a cost review across transfer, destination, and tooling choice typically pays off. Contact Us for a data-transfer and migration cost review.