# Azure Data Factory

> Azure Data Factory bills three separate meters: per activity run, per data-movement hour, and per integration-runtime hour. Cost therefore tracks pipeline behavior rather than any single resource. ZopNight discovers factories with pipeline and runtime context, attributes orchestration spend, and surfaces SSIS integration runtimes as separately schedulable resources.

Source: https://zop.dev/integrations/azure/data-factory
Updated: 2026-08-19

---

Azure Data Factory orchestrates data-integration pipelines, billed per activity run, data-movement hour, and integration-runtime hour. Always-on SSIS runtimes and chatty trigger schedules dominate its costs.

## A bill assembled from pipeline behavior

Data Factory has no instance to point at when the bill arrives. Orchestration charges per activity run, data movement charges per DIU-hour while copies execute, and integration runtimes charge per hour of compute. The factory resource itself is nearly free; everything depends on how often triggers fire and what the activities do. The steepest meter is the SSIS integration runtime, which is provisioned VM capacity billing every hour it is started, whether or not a package runs. That includes nights, weekends, and holidays. A tumbling-window trigger firing every 5 minutes against an external table can likewise turn a trivial pipeline into thousands of billed activity runs a day.

## Factory context in discovery, runtimes broken out

ZopNight discovers each factory through Azure Resource Graph with pipeline and runtime context, and Cost Management billing attributes orchestration spend. ML auto-tagging covers this type. The factory itself is discovery and cost visibility only, since orchestration cost is a function of trigger design rather than power state. Its SSIS integration runtimes are surfaced as separately schedulable resources, each with its own stop and start. That split matters: the schedulable money hides inside a resource most inventories treat as an implementation detail of the factory.

## The spend patterns behind expensive factories

Watch for an SSIS runtime started during a lift-and-shift migration and never stopped since; trigger frequencies chosen for development convenience (every few minutes) that shipped to production unchanged; and debug or retry loops re-running failed activities in bulk, each retry a fresh billed run.

## Following pipeline spend in the studio

Azure portal → Data factories → select a factory, then Launch studio. Monitor → Pipeline runs shows run volume by trigger, and Manage → Integration runtimes shows each runtime with its status. A running SSIS runtime with no recent package executions is the first thing to check.