Skip to content
Cloud Efficiency Hub

Idle Azure-SSIS Integration Runtime Left Running

The short version

An Azure-SSIS integration runtime (IR) is a dedicated cluster of VM nodes that Azure Data Factory or Synapse pipelines use to run lifted-and-shifted SQL Server Integration Services packages.

PointFive Research

Cloud cost research at PointFive

Category
Compute
Reference
CER-0450
Type
Idle or Unused Resource

Explanation

Why the waste happens and who it affects.

Once started, it bills for every node for as long as it stays started, whether or not any package is executing. Many SSIS workloads run in short nightly or hourly windows, yet the IR is started once during migration and left running around the clock.

Unlike the rest of Data Factory, which is billed per activity run and per unit of data movement or data flow compute, the SSIS IR behaves like always-on infrastructure. Microsoft's guidance is explicit: running an Azure-SSIS IR has a cost, so it should run only when SSIS packages need to run, and Data Factory provides a pipeline template that starts the IR just before a package and stops it right after so it doesn't run idly. The waste is easy to miss because, even with per-pipeline billing enabled, SSIS node charges file under a factory-level fall-back line item rather than under the pipelines that use them.

Billing model

The pricing dimensions that drive this cost.

SSIS IR node
Billed per node in per-second increments while the IR is started, based on VM size and SSIS edition
Standard and Enterprise editions
Priced separately per node; Enterprise edition is needed only for Enterprise-only SSIS features
Azure Hybrid Benefit
Reduced node pricing for customers with SQL Server licenses covered by active Software Assurance
Stopped IR
Stopping the IR releases all of its nodes and stops billing; the IR must also be stopped before it can be reconfigured or deleted

How to detect

4 checks to find it in your estate.

  • List Azure-SSIS integration runtimes and their state (Started or Stopped) across factories and Synapse workspaces, for example with Get-AzDataFactoryV2IntegrationRuntime or the integration runtimes REST API
  • Compare the hours each IR spends in the Started state with the time Execute SSIS Package activities actually run, using pipeline and activity run history in the Monitor tab
  • Check Cost analysis for the SSIS node meters under Azure Data Factory v2; charges that accrue 24x7 for an IR whose packages run only in short windows indicate idle runtime
  • Review node count, node size and edition against package concurrency and SSIS features used, since oversized or Enterprise nodes multiply idle cost

How to fix

5 ways to remove the waste.

  • Chain Execute SSIS Package activities between web activities that start and stop the IR, or use the 'Schedule ADF pipeline to start and stop Azure-SSIS IR just in time before and after running SSIS package' template
  • For fixed ETL windows, schedule separate start and stop pipelines with triggers, or use an Azure Automation runbook with Start-AzDataFactoryV2IntegrationRuntime and Stop-AzDataFactoryV2IntegrationRuntime
  • Use Until activities that check the IR state so start and stop steps retry on transient errors and complete only when the IR is actually Started or Stopped, and allow for the IR's startup time in the schedule
  • Rightsize node size and count to the packages' concurrency, compare Standard and Enterprise edition node prices and use Standard unless Enterprise features are required, and apply Azure Hybrid Benefit where eligible SQL Server licenses exist
  • Delete SSIS IRs left over from completed migrations

Documentation

Vendor references for pricing and configuration.