Your Azure SQL database has public network access disabled. Private endpoint is configured, DNS resolves correctly inside the VNet. Everything is locked down the way your security team wants it. Now you need ADF to move data out of it.
The default Azure Integration Runtime can't reach it. It runs in Microsoft's shared infrastructure, not inside your VNet. So what do you do?
The traditional answer was Self-Hosted Integration Runtime: deploy a VM inside the VNet, install the SHIR agent, manage the VM forever. It works, but you're back to managing infrastructure -- patching, scaling, monitoring uptime on a Windows Server that exists solely to be a network hop.
There is a better way. ADF's Managed Virtual Network changes this equation entirely.
What Managed Virtual Network Actually Is
When you enable Managed Virtual Network on an Azure Integration Runtime, ADF provisions a managed VNet inside Microsoft's infrastructure -- one that belongs to your ADF instance, not to Microsoft's shared pool. Inside that managed VNet, you create Managed Private Endpoints that connect to your private Azure resources.
The data path: ADF pipeline runs to Azure IR (inside your managed VNet) to Managed Private Endpoint to Private Endpoint in your VNet to your Azure SQL database. End-to-end private. No public internet. No VM to manage.
From your VNet's perspective, the connection looks like any other private endpoint connection. You approve it. It routes privately. ADF handles the managed VNet lifecycle.
Setting It Up
This is a one-time configuration per ADF instance. Here's the sequence:
Step 1: Enable Managed VNet on the Integration Runtime
In ADF Studio, go to Manage then Integration Runtimes. Edit your Azure IR (or create a new one). Enable "Virtual network configuration" and check "Managed virtual network." Save.
One catch: you cannot enable Managed VNet on an existing Azure IR that's already used by pipelines in production without some risk. Test this in dev/test first. The IR will need to be recreated if you change the VNet setting on an existing one.
Step 2: Create a Managed Private Endpoint
In ADF Studio, go to Manage then Managed Private Endpoints. Click New. Select the resource type (e.g., Azure SQL Database). Specify the subscription, resource group, and target resource. ADF will create a private endpoint connection request on that resource.
Step 3: Approve the Private Endpoint Connection
Go to your Azure SQL resource in the Azure portal. Under Security then Private endpoint connections, you'll see a pending connection request from ADF. Approve it.
Approval propagation takes 2-5 minutes. After that, the managed private endpoint shows as Approved in ADF Studio.
Step 4: Update Your Linked Service
Your Azure SQL Linked Service needs to use the Managed VNet IR, not the default Azure IR. Edit the linked service, set the Connect via integration runtime to your Managed VNet-enabled IR, and test the connection. It should succeed without needing public network access.
The Tradeoff You Need to Know About
Managed VNet IRs have a longer startup time than standard Azure IRs. Standard Azure IR cold start: 1-2 minutes. Managed VNet IR cold start: 3-5 minutes, sometimes longer if Azure is provisioning resources.
For batch pipelines that run once a day and transfer 100GB of data, this startup overhead is irrelevant. For pipelines that need to start in under 60 seconds for operational reasons, it matters.
The mitigation is time-to-live (TTL) on the IR. Set a TTL of 10-60 minutes depending on your pipeline frequency. The IR stays warm between runs, eliminating cold start costs. You pay for the TTL duration even without active pipeline runs -- factor that into your cost model.
For most enterprise batch workloads with private network requirements, Managed VNet is the right answer. You get enterprise-grade network security without managing a fleet of SHIR VMs. Trust me on this one -- I've managed those VMs. This is better.
When SHIR Is Still the Right Call
Managed VNet covers Azure-to-Azure private connectivity. If your source is on-premises (SQL Server behind a corporate firewall, a physical network that doesn't have an Azure private endpoint), Self-Hosted IR is still required. The SHIR agent needs to run somewhere with network access to that on-premises resource.
For hybrid workloads -- some cloud-private, some on-premises -- you'll likely run both: a Managed VNet Azure IR for the cloud-private sources, a SHIR for the on-premises sources. That's a reasonable architecture. Just don't use SHIR where Managed VNet will do the job.
If you're setting up private network access for an ADF project and have questions about which approach fits your architecture, I'm here to help.