In Azure Data Factory, when do you need a self-hosted integration runtime instead of the Azure one?

## What an integration runtime is The integration runtime (IR) is the compute that ADF actually uses. The factory itself is a control plane: it stores definitions and schedules runs. Every byte a `Copy` activity moves, every Mapping Data Flow, and every dispatch of an activity to an external compute passes through an IR. A dataset never names an IR; a **linked service** does, through its `connectVia` property. If you omit `connectVia`, the factory's default AutoResolve Azure IR is used. ## Azure integration runtime The Azure IR is fully managed and serverless — nothing to patch, nothing to size in advance. It does three jobs: - **Data movement** for the `Copy` activity between publicly reachable cloud stores. - **Data flow execution**, spinning up the managed Spark cluster behind a Mapping Data Flow according to the compute size and time-to-live configured on the IR. - **Activity dispatch** to external computes such as Databricks, HDInsight or a stored procedure on a SQL database. Its main configuration is the region. "AutoResolve" lets ADF pick a region close to the sink, which is convenient, but a compliance requirement to keep data in a named geography is a reason to pin an explicit region instead. For copy throughput on the Azure IR you tune Data Integration Units and parallel copies on the `Copy` activity, not the IR itself. ## Self-hosted integration runtime The self-hosted IR (often abbreviated SHIR) is an agent you install on a Windows machine — a VM in a virtual network, or a physical server on-premises. Its defining property is the direction of connectivity: it dials **out** to ADF, so a corporate firewall does not need inbound rules. That makes it the answer whenever the data lives somewhere Azure cannot reach: an on-premises SQL Server or Oracle instance, a file share, a private network segment, or a cloud store restricted to specific networks. A self-hosted IR also does more than movement. It dispatches activities that must run against on-premises compute, and it is required for a copy where *either* side is unreachable from the public network — the same node handles both ends of that copy, so it needs enough CPU, memory and network to sustain the transfer. Operationally, three points matter. It can be **scaled out to several nodes**, giving both throughput and high availability if one node goes down. It can be **shared** with other data factories, so a single hardened node serves multiple teams. And it is *your* machine: patching, disk, upgrades and the certificate/credential store are your responsibility, which is precisely why teams reach for a managed alternative when one exists. ## Azure-SSIS integration runtime The Azure-SSIS IR is a managed cluster of nodes that runs SQL Server Integration Services packages, so an existing SSIS estate can be lifted into ADF and invoked by the Execute SSIS Package activity. You choose node size and node count, and you can join it to a virtual network to reach private data sources. It exists for migration rather than for new development; nobody builds new SSIS packages to run on ADF today. ## Managed virtual network and private endpoints The modern middle ground is an Azure IR with a **managed virtual network** enabled and **managed private endpoints** to the target resources. This reaches Azure PaaS services locked to private networking — a storage account or SQL database with public access disabled — without any machine you have to own. It does not help with genuinely on-premises sources, which still need a self-hosted IR, but it removes the most common reason teams used to install one. Interviewers like this distinction because it separates candidates who learned ADF years ago from those working with it now. ## Choosing, in one pass 1. Are both ends publicly reachable cloud services? Azure IR, pin the region if compliance requires it. 2. Is the target an Azure resource locked behind private networking? Azure IR with managed VNet and managed private endpoints. 3. Is anything genuinely on-premises or on a private non-Azure network? Self-hosted IR, sized for the transfer and ideally multi-node. 4. Are you running existing SSIS packages? Azure-SSIS IR. ## Pitfalls worth naming - Believing a self-hosted IR needs inbound firewall openings; it does not, and saying so signals unfamiliarity. - Running production transfers on a single SHIR node, then discovering the whole factory's on-prem connectivity is one unpatched VM. - Tuning Data Integration Units for a self-hosted copy — DIUs apply to the Azure IR; self-hosted throughput comes from node resources and concurrent job settings. - Forgetting that a copy with one private end pins the *whole* copy to the self-hosted node, which then becomes the bottleneck. - Assuming the Azure-SSIS IR is needed for ordinary pipelines; it is only for SSIS packages.