SSIS Integration Runtime
Does ZopNight manage SSIS Integration Runtime?
SSIS integration runtimes bill per node-hour while running inside their parent Data Factory, so a runtime left up between nightly ETL windows wastes most of its spend. ZopNight starts the runtime ahead of the window and stops it after. Startup takes several minutes, so schedules lead the ETL start accordingly.
Rules that fire on SSIS Integration Runtime
No active rule family targets SSIS Integration Runtime 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 | stopped and started via the integration-runtime stop/start operations, halting node billing while stopped. |
SSIS integration runtimes are dedicated VM clusters inside Data Factory that execute SQL Server Integration Services packages, billed per node-hour while running. Runtimes left running between nightly ETL windows waste most of their spend.
Node-hours inside a Data Factory
An SSIS IR is a cluster of VMs that Data Factory manages on your behalf, and the meter is node-hours: node size times node count times hours running. The runtime does not care whether a package is executing: a started IR bills its full cluster while waiting for work. Since SSIS workloads are overwhelmingly batch-shaped, often a single nightly window of an hour or two, an always-on runtime spends the vast majority of its node-hours executing nothing.
Bracketing the ETL window
Stopped and started via the integration-runtime stop/start operations, halting node billing while stopped. This is the highest-leverage action for the type, and it maps naturally onto a schedule. Runtime start takes several minutes, so schedules should lead the ETL window accordingly: start the IR before the first package is due, stop it once the window closes. A runtime needed from a set hour nightly simply gets a start scheduled a comfortable margin earlier, and the packages find it warm.
Runtime discovery under the parent factory
Discovered via Azure Resource Graph under its parent Data Factory. Cost Management billing attributes node-hour spend, and schedules start the runtime for ETL windows and stop it after. ML auto-tagging covers this type, helping route each runtime into an environment-appropriate schedule without manual classification.
Waste that hides between package runs
Typical leaks: runtimes started manually for a migration or debugging session and left running for weeks; node counts sized for a historical full-load that incremental loads no longer need; and duplicate IRs across dev, test, and production factories, each idling around its own brief window.
Locating the runtime in Data Factory Studio
Azure portal → Data factories → open the factory → launch Data Factory Studio → Manage → Integration runtimes: the SSIS entries show status Running or Stopped, along with the interactive stop and start controls that mirror the scheduled operations.