Integration runtime

Understand the concept

In plain English

Integration runtime controls which compute, region, and network path data integration workloads use when moving data or executing pipeline activities. Teams see it in data factory integration runtime blade, synapse pipelines. It is not a pipeline, dataset, linked service, Databricks cluster, VM scale set, or Azure Container Apps environment; confusing them can create blocked on-premises connectivity, slow copy jobs. Use the term when reviewing access, monitoring, cost, recovery, or performance. It keeps architects, operators, security reviewers, and support teams focused on the same setting, resource, or behavior.

Why it matters

Integration runtime matters because it turns an architecture choice into day-to-day workload behavior. If the team misunderstands it, the failure usually appears as blocked on-premises connectivity, slow copy jobs, failed credential sync before anyone notices the documentation gap. The term also affects security, reliability, operations, cost, and performance because one setting can influence access, recovery, automation, user experience, and budget. Naming it precisely helps engineers compare portal settings, CLI output, infrastructure-as-code, monitoring data, and incident notes without guessing. It also gives reviewers a practical checklist: where is it configured, who owns it, what depends on it, what evidence proves it works, and how rollback happens.

Technical context

Technically, Integration runtime sits in Data Factory integration runtime blade, Synapse pipelines, copy activities, linked services. Key fields include runtime type, region, managed virtual network, node count. Operators verify it with integration runtime status, node health, activity run details, copy throughput. In production reviews, connect the term to resource scope, identity, network path, diagnostics, cost ownership, and rollback. Confirm subscription, resource group, service tier, dependent workload, and current Azure evidence before changing it. Capture the current resource ID, region, and dependency path before approving changes.

Exam context

Compare with

Where it is used

Where you see it

1. In the Azure portal, Integration runtime appears near data factory integration runtime blade, synapse pipelines, where owners review configuration, health, access, and dependent workload impact before safe production changes.
2. In CLI or REST output, Integration runtime shows up through integration runtime status, node health and related fields that confirm live Azure state during audits, releases, and incidents.
3. In incident reviews, Integration runtime is discussed when users report blocked on-premises connectivity, and engineers compare logs, metrics, ownership, dependencies, recent changes, support impact, and deployment evidence together.

Common situations

• Choose the compute and network path for Data Factory copy or pipeline activity.
• Connect on-premises data sources through self-hosted integration runtime nodes.
• Review runtime region, node health, linked services, and private connectivity before changes.
• Troubleshoot slow copy jobs, offline nodes, credential problems, and blocked network paths.
• Standardize runtime ownership, upgrades, monitoring, and scale planning across factories.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

CLI checks are useful for Integration runtime because they capture live Azure state, reduce guesswork, and separate safe inspection from approved changes.

az datafactory integration-runtime list --factory-name <factory-name> --resource-group <resource-group>

az datafactory integration-runtime show --factory-name <factory-name> --resource-group <resource-group> --name <runtime-name>

az datafactory integration-runtime get-status --factory-name <factory-name> --resource-group <resource-group> --name <runtime-name>

az datafactory integration-runtime start --factory-name <factory-name> --resource-group <resource-group> --name <runtime-name>

az datafactory integration-runtime stop --factory-name <factory-name> --resource-group <resource-group> --name <runtime-name>

Architecture context

Technically, Integration runtime sits in Data Factory integration runtime blade, Synapse pipelines, copy activities, linked services. Key fields include runtime type, region, managed virtual network, node count. Operators verify it with integration runtime status, node health, activity run details, copy throughput. In production reviews, connect the term to resource scope, identity, network path, diagnostics, cost ownership, and rollback. Confirm subscription, resource group, service tier, dependent workload, and current Azure evidence before changing it.

Security

Security for Integration runtime starts with managed identities, linked-service credentials, Key Vault references, self-hosted node hardening, outbound firewall rules. Review who can read, create, update, delete, restore, deploy, or invoke the related resource, and verify that privileged changes create audit evidence. Prefer Microsoft Entra ID, managed identities, private endpoints, key rotation, customer-managed keys, and policy controls where the service supports them. Keep secrets, credentials, personal data, and regulated content out of scripts and examples unless the data-handling design explicitly allows it. During approval, check tenant boundaries, network exposure, diagnostic logs, and break-glass procedures so a configuration mistake does not become an incident.

Cost

Cost for Integration runtime is driven by Azure IR activity usage, data flow clusters, SSIS IR runtime hours, self-hosted VM costs, idle time. The common mistake is treating the term as free because it is a setting, schema choice, job, or child resource instead of a cost influence. Check whether charges come from storage, requests, tokens, replicas, retention, backups, training, data transfer, diagnostics, or engineer time spent recovering from bad configuration. Use tags, budgets, Azure Cost Management, and owner reviews to connect usage to a workload. When reducing cost, confirm the change will not remove recovery evidence, security controls, or needed performance headroom.

Reliability

Reliability for Integration runtime depends on self-hosted node high availability, queue duration, regional routing, managed VNet health, credential synchronization. A resource can exist and still fail the business workflow when permissions, network paths, limits, schema settings, or downstream services are wrong. Define the health signal before production use, then test the expected failure mode with a controlled change. Monitor platform metrics, application traces, deployment history, and user symptoms in the same time window during incidents. Recovery plans should include owner contact, safe rollback, validation queries, and customer-impact checks, not just proof that the Azure resource exists. Confirm this behavior is tested before the workload depends on it.

Performance

Performance for Integration runtime depends on copy throughput, source and sink limits, parallelism, data flow cluster size, region choice. Measure the real workload instead of assuming the default configuration is enough. Look at latency, throughput, concurrency, request size, metadata operations, query complexity, token counts, or recovery duration depending on the service. Compare production metrics with load tests and with the limits of the selected tier or model. Tuning should be incremental and reversible, because a change that improves one path can hurt another. Always verify user-facing behavior after configuration, schema, deployment, or data-layout changes. Capture before-and-after metrics so tuning is based on evidence rather than assumptions.

Operations

Operations for Integration runtime require runtime inventory, node upgrade checks, pipeline activity monitoring, key rotation, linked service reviews. Treat the term as something support teams must inspect quickly, not only as a design-time concept. Keep a runbook with portal locations, CLI commands, expected output, known dependencies, approval rules, and rollback steps. Review it during releases, migrations, incidents, access changes, and cost investigations. Good operations practice also means tagging owners, enabling diagnostics, storing evidence from read-only checks, and documenting exceptions. When the term changes, update handoff notes so future operators know what normal looks like. Keep the same evidence available to the next on-call engineer.

Common mistakes

• Treating Integration runtime as a harmless label instead of checking the live resource, scope, owner, and dependencies.
• Running a mutating command in the wrong subscription, resource group, account, service, index, share, or deployment.
• Assuming a successful deployment proves the feature works without checking logs, metrics, access, and rollback evidence.
• Ignoring cost, retention, quotas, network exposure, or data classification until an incident forces emergency cleanup.