Azure Data Factory cannot be made fully private in the same way as an Azure Databricks workspace, but Private Link can be used to ensure that communication between customer networks and Data Factory goes over private endpoints.
Key points from the context:
- Private connectivity model for ADF
- Azure Data Factory supports Azure Private Link via private endpoints for:
- The Data Factory portal (
adf.azure.com).
- Factory endpoints (
*.{region}.datafactory.azure.net) used by self-hosted IR.
- Service Bus (
*.servicebus.windows.net) and download.microsoft.com for SHIR operations.
- Private endpoints use private IPs in a VNet, and DNS is updated so that, from inside the VNet, the Data Factory FQDNs resolve to the private endpoint IPs instead of public IPs.
- When resolved from outside the VNet, the same FQDNs still resolve to the public endpoints.
- Behavior with and without VPN
- With Private Link configured and DNS integrated, traffic from within the VNet (or on-prem via VPN/ExpressRoute) to ADF endpoints goes over the private endpoint.
- Disabling public network access in ADF applies to the self-hosted IR, not to Azure IR and SSIS IR.
- The known limitation: when both sides use Private Link/private endpoints for the same PaaS resource, access patterns can be affected, but this does not turn ADF into a “private-only workspace” in the same sense as Databricks.
- To force users to go through private connectivity, network and DNS must be designed so that:
- From corporate networks, ADF FQDNs resolve only to private IPs (via custom DNS/delegation).
- Direct Internet egress to ADF public endpoints is blocked (e.g., via firewall/proxy), so access without VPN fails.
- DNS behavior and verification
- For a factory
DataFactoryA:
- Outside the VNet:
-
DataFactoryA.{region}.datafactory.azure.net → CNAME to public endpoint → A record to public IP.
- Inside the VNet with private endpoint:
-
DataFactoryA.{region}.datafactory.azure.net → CNAME to DataFactoryA.{region}.privatelink.datafactory.azure.net → A record to private endpoint IP.
- If using custom DNS, it must either:
- Delegate the
privatelink subdomain to the Azure private DNS zone, or
- Host A records mapping
DataFactoryA.{region}.datafactory.azure.net directly to the private endpoint IP.
- Why SHIR test connection works without VPN
- The self-hosted IR requires access to:
-
*.{region}.datafactory.azure.net (ADF control plane).
-
*.servicebus.windows.net.
-
download.microsoft.com.
- If the SHIR machine is off-VNet/VPN and can reach the public Internet, it will resolve these FQDNs to public endpoints and succeed, even if private endpoints also exist elsewhere.
- This is expected: Private Link does not automatically block public access from other networks; it only provides a private path for networks where the private endpoint and DNS are configured.
- How to confirm private connectivity of ADF
Use a similar approach as for Databricks and the guidance in the ADF Private Link docs:
- Verify DNS resolution from inside the VNet/on-prem (over VPN/ExpressRoute):
- From a VM in the VNet hosting the private endpoint (or on-prem via VPN/ExpressRoute), run
nslookup for:
-
adf.azure.com (portal, if portal private endpoint is configured).
-
DataFactoryA.{region}.datafactory.azure.net (replace with actual factory name/region).
- Confirm they resolve to:
-
*.privatelink.adf.azure.com / *.privatelink.datafactory.azure.net CNAMEs.
- A records with private IPs of the private endpoints.
- Verify portal and authoring over private endpoint:
- From a VM in the VNet (or on-prem via VPN/ExpressRoute):
- Browse to the Data Factory portal (via Azure portal → Data Factory → Author & Monitor).
- Successful authoring/monitoring while DNS resolves to private IPs confirms private connectivity.
- Verify SHIR control-plane traffic over Private Link:
- Install SHIR on a VM in the VNet with the private endpoints.
- Ensure DNS for
*.{region}.datafactory.azure.net and *.servicebus.windows.net resolves to the corresponding privatelink zones (per the private endpoint configuration).
- Run “Test connection” on linked services that use this SHIR; success indicates SHIR is communicating via Private Link.
- Verify that public path is not used from controlled networks:
- From the same VNet/on-prem network, check that
nslookup does not return public IPs for the ADF endpoints.
- Use network firewall rules to block direct Internet access to ADF public endpoints from corporate networks; attempts to reach ADF without VPN should then fail.
In summary, ADF itself does not become a “private-only workspace” object, but Private Link plus DNS and network egress controls can enforce that, from corporate environments, ADF is reachable only via private connectivity and fails when accessed without VPN.
References: