Configure Azure Data Factory private endpoints and runtime networking

1. Inventory the cloud and all four network paths

Start with the approved subscription, Data Factory V2 resource, deployment region, source and destination stores, Key Vault, logs, and integration runtime (IR). Record each connector version, authentication method, processing location, and any staging account or external compute. Include these dependencies in the system boundary and customer responsibility review.

A factory’s region describes the orchestration resource. The IR executes movement or transformation, and linked services select its actual path. A regional factory name does not establish where every external activity runs. Verify service, feature, and geography against the current provider package; Azure Government does not make every connector or preview acceptable.

2. Select a runtime whose network model fits

For supported Azure services, an Azure IR in an ADF managed virtual network can use managed private endpoints. Microsoft hosts this network in its subscription and requires it in the factory’s region. Custom DNS is not supported there. Verify the chosen Government region and connector feature before using this pattern; the generic documentation is not a Government feature-parity guarantee.

For an on-premises SQL Server, a private VM database, custom DNS dependencies, or customer-controlled egress rules, use a self-hosted IR on a hardened Windows host in your approved network. Both ends of a Copy activity must be reachable from the runtime selected for that movement. Mapping Data Flows run on Azure-managed compute; installing a self-hosted IR does not move their Spark execution onto that host.

3. Configure factory Private Link and cloud-specific DNS

Select the cloud using approved operator or workload authentication. Discover Private Link metadata before creating connections; use the returned group IDs with their exact casing and required zone names. The following commands read configuration and do not create resources:

az cloud set --name AzureUSGovernment
az account set --subscription "$APPROVED_SUBSCRIPTION_ID"
az network private-link-resource list --id "$FACTORY_RESOURCE_ID"
az resource show --ids "$FACTORY_RESOURCE_ID" --api-version 2018-06-01   --query '{location:location,publicNetworkAccess:properties.publicNetworkAccess}'

Create the required private endpoints in the approved customer VNet, approve their connections, and link the private DNS zones to client networks. Forward on-premises queries through an approved resolver design. Keep the original service hostname in clients; DNS resolves it onto the private address. A private IP copied into a connection string breaks hostname validation and service routing.

Microsoft specifies that factory public-network access restrictions apply to self-hosted IR connectivity, not Azure IR or Azure-SSIS IR. A portal private endpoint also does not remove all public portal access. Treat these as scoped controls and enforce authoring permissions separately.

4. Secure runtime-to-store connectivity separately

For a managed-VNet Azure IR, create managed private endpoints to the specific SQL, storage, and Key Vault resources. Connections begin Pending and require the target resource owner’s approval. Explicitly reference that IR through connectVia in each applicable linked service; omitting the reference can select the default Azure IR.

For a self-hosted IR, create the store endpoints in the customer VNet and verify DNS from every IR node. For ADLS Gen2, provision both DFS and Blob endpoints: some lake operations use or redirect to the other endpoint. Deny or tightly restrict public access on each store after the private path works. A private endpoint alone leaves the public endpoint available.

Key Vault linked-service “Test connection” in the managed-VNet flow only checks the URL format. Verify secret retrieval with the actual consuming linked service and activity. Review trusted-service bypasses as explicit exceptions, with identity and scope evidence.

5. Test permitted and denied paths from the actual runtime

1. Use synthetic records to test source reads and sink writes through the selected IR. Record its name, region, endpoint approvals, and store settings.
2. On self-hosted nodes, resolve factory, SQL, DFS, Blob, and Key Vault hosts to approved private IPs; test TLS and an authenticated activity, not only TCP reachability.
3. Using a valid scoped identity from an unapproved network, confirm the store’s public path is denied. An authentication error alone does not demonstrate network isolation.
4. From the approved runtime, deny an identity without data-plane permissions and attempt an unapproved destination where the architecture supports that test.
5. Test authoring, scheduled execution, interactive schema browsing, and update delivery separately; they can have different dependencies.

Keep sanitized DNS, endpoint-state, identity, and activity evidence. Continue with managed identity and ADLS ingestion or the hybrid runtime implementation guide.

Sources and technical review

Technical review: October 7, 2026. Recheck cloud, regional, connector, and authorization scope before implementation.

• Integration runtime capabilities and location
• Data Factory Private Link and public-access limitations
• Managed virtual network, endpoint approvals, and egress limitations
• Private endpoint DNS, including Government zones
• Storage private endpoints and DFS/Blob requirements

Public offering and service-scope checks are documented in the Data Factory hub. The protected provider authorization package and live Azure behavior have not been reviewed or tested by these guides.