Cannot create private endpoint outbound rule to third-party Private Link Service (Snowflake) in Azure ML managed VNet

Question

Cannot create private endpoint outbound rule to third-party Private Link Service (Snowflake) in Azure ML managed VNet

Derek Freed 0

We have an Azure ML workspace with managed VNet isolation mode AllowOnlyApprovedOutbound. We need to create an outbound private endpoint rule to Snowflake's Azure Private Link Service so our compute cluster can reach Snowflake privately.

When using az ml workspace outbound-rule set with --type private_endpoint and a third-party PLS alias as the --service-resource-id, we get: ValidationError: Invalid Target Resource

We've tried multiple --subresource-target values (account, snowflake, empty) — all fail with the same error.

Questions:

Does AML managed VNet support private endpoint outbound rules to third-party Azure Private Link Services (not just Azure PaaS resources)?

If yes, what format should the service-resource-id and subresource-target be for a PLS?

If not currently supported, is there a workaround or roadmap item?

Snowflake KB reference: https://community.snowflake.com/s/article/How-to-set-up-a-managed-private-endpoint-from-Azure-Data-Factory-or-Synapse-to-Snowflake

Region: East US

Karnam Venkata Rajeswari 1,145 Reputation points Microsoft External Staff Moderator

2026-03-23T09:26:04.6433333+00:00

Hello Derek Freed,

Checking in to see if you had any chance to review the response.

Thank you!
Karnam Venkata Rajeswari 1,145 Reputation points Microsoft External Staff Moderator

2026-03-25T06:01:39.8366667+00:00

Hello Derek Freed,

Just checking in to see if you have got a chance to see my response to your question in resolving the issue.

Thank you!
Derek Freed 0 Reputation points

2026-03-25T16:49:25.6333333+00:00
Thanks for the response, Karnam. The two workarounds you mentioned are helpful context, but I wanted to share a few additional approaches we've identified for others who hit this same limitation:

1. Application Gateway bridge (Microsoft-documented pattern)

Microsoft documents an approach for this scenario at Access on-premises resources from managed network. The pattern is:

Deploy an Application Gateway (Standard_v2) in a hub/spoke VNet with a Private Link frontend

Create a managed PE outbound rule in AML targeting the App Gateway (which is a supported resource type)

App Gateway forwards traffic to a regular Snowflake PE in the spoke VNet via VNet peering

This keeps the managed VNet intact and all traffic stays on the Azure backbone — no public internet, no Azure Firewall FQDN cost. It does add App Gateway cost and configuration complexity.

2. External compute for data sourcing (architectural workaround)

Instead of connecting AML compute to Snowflake directly, run the data loading/write-back steps on compute in the spoke VNet (e.g., an ADO pipeline agent, ACI with VNet injection, or a Container Apps Job). Create a regular Snowflake PE in the spoke. Data flows: spoke compute pulls from Snowflake → writes to ADLS → AML compute reads/writes ADLS → spoke compute pushes results back to Snowflake.

This is the lowest-cost option (just PE charges), preserves the managed VNet and all AML features, but decouples data ingestion from the AML pipeline.

Regarding the FQDN outbound rule suggestion — for our use case this doesn't meet our security requirements since FQDN rules route through Azure Firewall to the public endpoint, and we need all data to stay on the Azure backbone via Private Link.
Karnam Venkata Rajeswari 1,145 Reputation points Microsoft External Staff Moderator

2026-03-26T08:25:01.8433333+00:00

Hello Derek Freed

Glad to hear the response was helpful. Thank you for sharing the workarounds.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted? This helps others in the community with the same question find the solution more easily.

Thank you!

1 answer

Your answer

Karnam Venkata Rajeswari 1,145 Reputation points Microsoft External Staff Moderator

2026-03-23T09:26:04.6433333+00:00

Hello Derek Freed,

Checking in to see if you had any chance to review the response.

Thank you!
Karnam Venkata Rajeswari 1,145 Reputation points Microsoft External Staff Moderator

2026-03-25T06:01:39.8366667+00:00

Hello Derek Freed,

Just checking in to see if you have got a chance to see my response to your question in resolving the issue.

Thank you!
Derek Freed 0 Reputation points

2026-03-25T16:49:25.6333333+00:00

Thanks for the response, Karnam. The two workarounds you mentioned are helpful context, but I wanted to share a few additional approaches we've identified for others who hit this same limitation:

1. Application Gateway bridge (Microsoft-documented pattern)

Microsoft documents an approach for this scenario at Access on-premises resources from managed network. The pattern is:

Deploy an Application Gateway (Standard_v2) in a hub/spoke VNet with a Private Link frontend

Create a managed PE outbound rule in AML targeting the App Gateway (which is a supported resource type)

App Gateway forwards traffic to a regular Snowflake PE in the spoke VNet via VNet peering

This keeps the managed VNet intact and all traffic stays on the Azure backbone — no public internet, no Azure Firewall FQDN cost. It does add App Gateway cost and configuration complexity.

2. External compute for data sourcing (architectural workaround)

Instead of connecting AML compute to Snowflake directly, run the data loading/write-back steps on compute in the spoke VNet (e.g., an ADO pipeline agent, ACI with VNet injection, or a Container Apps Job). Create a regular Snowflake PE in the spoke. Data flows: spoke compute pulls from Snowflake → writes to ADLS → AML compute reads/writes ADLS → spoke compute pushes results back to Snowflake.

This is the lowest-cost option (just PE charges), preserves the managed VNet and all AML features, but decouples data ingestion from the AML pipeline.

Regarding the FQDN outbound rule suggestion — for our use case this doesn't meet our security requirements since FQDN rules route through Azure Firewall to the public endpoint, and we need all data to stay on the Azure backbone via Private Link.
Karnam Venkata Rajeswari 1,145 Reputation points Microsoft External Staff Moderator

2026-03-26T08:25:01.8433333+00:00

Hello Derek Freed

Glad to hear the response was helpful. Thank you for sharing the workarounds.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted? This helps others in the community with the same question find the solution more easily.

Thank you!

Answer 1

Hello Derek Freed,

Welcome to Microsoft Q&A and Thank you for reaching out.

The failure occurs because managed VNet outbound “private_endpoint” rules validate the destination as an Azure resource with a supported ARM resource ID and an expected private-link subresource (groupId). Third‑party Private Link Service aliases (for example, Snowflake) are not described in the supported destination patterns, so the request is commonly rejected during validation as Invalid Target Resource.

Azure Machine Learning managed virtual network outbound rules support private endpoint connections only to supported Azure services that expose a valid Azure Resource Manager (ARM) resource ID.

Managed VNet outbound private endpoint rules require a destination defined using a full ARM resource ID. The service‑resource‑id must point to a supported Azure resource under a Microsoft.* provider, and the subresource‑target must match a documented private link subresource (groupId) exposed by that Azure service.

The expected format for supported private endpoint outbound rules is

managed_network:
  isolation_mode: allow_only_approved_outbound
  outbound_rules:
    - name: storage-private-endpoint
      type: private_endpoint
      destination:
        service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
        subresource_target: blob

Please consider the following work arounds

FQDN outbound rule - Add an outbound rule of type fqdn for the required Snowflake endpoint/domain. Please note that FQDN outbound rules are implemented using Azure Firewall and can add billing charges.
Use a customer-managed virtual network (non-managed VNet approach) - If third‑party Private Link integration is mandatory, deploy and secure the workspace using virtual network–based networking (instead of managed VNet isolation) and implement Private Link connectivity patterns within that VNet.

References:

Managed virtual network isolation - Azure Machine Learning | Microsoft Learn

Secure an Azure Machine Learning workspace with virtual networks - Azure Machine Learning | Microsoft Learn

az ml workspace outbound-rule | Microsoft Learn

Thank you!

Share via

Cannot create private endpoint outbound rule to third-party Private Link Service (Snowflake) in Azure ML managed VNet

1 answer

Your answer