Azure Data Factory cost: activity runs, data movement, and data flows
Data Factory bills orchestration per activity run, data movement per DIU-hour, and mapping data flows per vCore-hour, plus pipeline monitoring. Chatty pipelines and always-on data flow clusters are the usual overspend. Here is the breakdown.
Quick answer
Data Factory bills orchestration per activity run (a small per-run fee), data movement per DIU-hour (Data Integration Units used by copy activities), and mapping data flows per vCore-hour of the Spark cluster they run on. Chatty pipelines with many tiny activities and oversized or always-on data flow clusters are the common overspend.
Azure Data Factory orchestrates and moves data, and its cost has three moving parts that catch teams out separately. The orchestration fee is tiny per activity but adds up with granular pipelines; data movement and data flows are the compute-heavy lines.
Orchestration: per activity run
Every activity execution carries a small per-run charge. A pipeline built from many tiny activities, or one that loops over thousands of items, racks up activity-run cost even though each run is cheap. Consolidating logic into fewer activities and avoiding per-item loops where a batch operation would do keeps this line down.
Data movement and data flows
| Component | Bills for |
|---|---|
| Orchestration | Per activity run |
| Copy (data movement) | Per DIU-hour used |
| Mapping data flows | Per vCore-hour of the Spark cluster |
Copy activities use Data Integration Units, billed per DIU-hour, so large or slow copies cost more. Mapping data flows run on a Spark cluster billed per vCore-hour, including the cluster startup and time-to-live window, so an oversized cluster or a long TTL keeping it warm between runs is a common waste.
Controlling Data Factory cost
Consolidate granular activities and avoid per-item loops, right-size DIUs for copy activities, and tune data flow cluster size and time-to-live so clusters do not sit warm and idle. Schedule pipelines efficiently rather than polling frequently, and prefer incremental loads over full reprocessing, the same do-less-work principle as Glue cost optimization.
FAQ
How is Azure Data Factory priced?
By orchestration (a small fee per activity run), data movement (per Data Integration Unit hour used by copy activities), and mapping data flows (per vCore-hour of the Spark cluster they run on), plus pipeline monitoring. The compute lines are usually the largest.
Why is my Data Factory activity-run cost high?
Usually granular pipelines: many tiny activities or loops over thousands of items each incur a per-run charge. Consolidating logic into fewer activities and avoiding per-item loops where a batch operation would do reduces this line.
What are DIUs in Data Factory?
Data Integration Units, the compute unit for copy (data movement) activities, billed per DIU-hour. Larger or slower copies use more DIU-hours. Right-sizing DIUs for the copy workload controls the data-movement cost.
Why do mapping data flows cost so much?
They run on a Spark cluster billed per vCore-hour, including startup and a time-to-live window that keeps the cluster warm between runs. An oversized cluster or a long TTL sitting idle is a common overspend; tune both to the workload.
How do I reduce Data Factory cost?
Consolidate granular activities, avoid per-item loops, right-size copy DIUs, tune data flow cluster size and time-to-live so clusters do not idle warm, schedule efficiently instead of frequent polling, and use incremental loads over full reprocessing.
Does C3X estimate Data Factory cost?
Data Factory cost is driven by activity runs, DIU-hours, and data flow vCore-hours, which are usage inputs. C3X prices the surrounding infrastructure, and you model pipeline activity to estimate the Data Factory charges.
What to do next
Estimate the infrastructure around your pipelines before you build them. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.