How to establish connection between azure AML workplace and azure Sql MI via private endpoint

Question

How to establish connection between azure AML workplace and azure Sql MI via private endpoint

Hanh Trinh 91

I'm looking for method to connect Azure MI from Azure AML via Private Endpoint.

Azure AML network setting: allowonly approved outbound

Azure MI: NSG allows to connect from Service tag: Azure machine learning to Sql

But the connection still fails.

Ajay Rathod 260 Reputation points Microsoft External Staff Moderator

2026-08-03T07:30:49.63+00:00
Hi @Hanh Trinh

Thanks for the detail on your setup — it makes this quick to diagnose. Your NSG rule looks correct, so this is a frustrating one. The problem is that you're hitting two separate walls at once, and neither is visible from the NSG blade.

Wall 1 — the AML managed VNet cannot create a private endpoint to a SQL Managed Instance. Private endpoint outbound rules in a managed VNet are only supported for a fixed list of services. That list includes Azure SQL Server (Microsoft.Sql/servers — the Azure SQL Database logical server); it does not include Microsoft.Sql/managedInstances. So there is no managed private endpoint to SQL MI to create, which is why the portal never offers one that works.

Wall 2 — AzureMachineLearning is a control-plane tag, not your data traffic. That tag is documented for compute instance/cluster create-update-delete, notebook IntelliSense (port 18881), and compute lifecycle (port 5831). Your job's TDS traffic to SQL does not arrive tagged as AzureMachineLearning, so the MI-side NSG rule never matches it.

Option A — Keep it private: move to a customer-managed VNet (recommended)

This is the only path that gives you true private endpoint connectivity to SQL MI.

1. Deploy AML compute into your own VNet/subnet instead of the managed VNet. This gives you control over peering, routes, and DNS zone links — all of which SQL MI private endpoints require.

Verify: az ml compute show -n <compute> -g <rg> -w <ws> --query "subnet" returns your subnet ID.

2. Create the private endpoint to the MI in that VNet — resource type Microsoft.Sql/managedInstances, target sub-resource managedInstance. Approve it on the MI side under Security → Private endpoint connections. ✔ Verify: the connection shows Approved, not Pending.

3. Configure DNS manually. Automatic DNS registration is not supported for MI private endpoints.

Get the private endpoint's private IP from its NIC.

Create a private DNS zone privatelink.<dns-zone>.database.windows.net and link it to the endpoint's VNet.

Add an A record: Name <instance-name> → the private endpoint IP.

If the private endpoint and the MI are in the same VNet, name the zone something else entirely (for example privatelink.site). Using the privatelink.<dns-zone>.database.windows.net name inside the MI's own VNet disrupts the instance's internal connectivity and causes management operations to fail.

✔Verify: from the compute, nslookup <instance-name>.<dns-zone>.database.windows.net returns the private endpoint IP.

4. Connect using the full instance FQDN, never the IP — MI requires the exact hostname in the connection string and rejects IP-based connections.

Same-VNet private endpoint only: the certificate won't match the endpoint name, so set Encrypt=Strict with HostNameInCertificate set to the instance's VNet-local endpoint domain name (recommended). Encrypt=Mandatory with HostNameInCertificate also works.

Verify: SELECT @@SERVERNAME; returns from a Python or sqlcmd cell on the compute.

Two MI private endpoint behaviours worth planning for: private endpoints to SQL MI support port 1433 only, and they always use the proxy connection type regardless of your connection type setting — worth benchmarking if your jobs pull large datasets.Thanks for the detail on your setup — it makes this quick to diagnose. Your NSG rule looks correct, so this is a frustrating one. The problem is that you're hitting two separate walls at once, and neither is visible from the NSG blade.

Wall 1 — the AML managed VNet cannot create a private endpoint to a SQL Managed Instance. Private endpoint outbound rules in a managed VNet are only supported for a fixed list of services. That list includes Azure SQL Server (Microsoft.Sql/servers — the Azure SQL Database logical server); it does not include Microsoft.Sql/managedInstances. So there is no managed private endpoint to SQL MI to create, which is why the portal never offers one that works.

Wall 2 — AzureMachineLearning is a control-plane tag, not your data traffic. That tag is documented for compute instance/cluster create-update-delete, notebook IntelliSense (port 18881), and compute lifecycle (port 5831). Your job's TDS traffic to SQL does not arrive tagged as AzureMachineLearning, so the MI-side NSG rule never matches it.

Option B — Stay on the managed VNet: service tag to the MI public endpoint

Only viable if you can accept a public endpoint. Port 1433 will not work here — the managed VNet can't be peered to your VNet, so the MI's VNet-local endpoint is unreachable no matter what rule you add. The only reachable target is the MI public endpoint, which listens on 3342.

1. Enable the MI public endpoint: MI → Networking → Public endpoint → Enable.

Verify: the MI Networking blade shows the public endpoint FQDN <instance-name>.public.<dns-zone>.database.windows.net.

2. Add the AML outbound rule: Networking → Add user-defined outbound rules → Destination type Service Tag, Service tag Sql (or Sql.<region>), Protocol TCP, Port ranges 3342. Service Tag and FQDN destination types are only offered in approved-outbound mode, so you will see them.

Verify: az ml workspace show -n <ws> -g <rg> --query "managed_network.outbound_rules" lists the rule.

3. Fix the MI-side NSG inbound rule: destination port 3342, and replace the AzureMachineLearning source. Note there is no customer-addressable egress IP range or service tag for an AML managed VNet, so you would have to open a broad source range — which is exactly why this is a stopgap.

Verify: Network Watcher → IP flow verify (destination = MI public endpoint, port 3342) returns Allow.

4. Connect on the public endpoint FQDN and port 3342, not 1433.

Please treat Option B as tactical unblocking, not an end state. The docs are explicit that "service tags as the ONLY security boundary isn't sufficient," and that once you add outbound rules to an approved-outbound workspace, Microsoft can't guarantee protection against data exfiltration. It is not a private link equivalent.

Documentation

Workspace managed virtual network isolation — supported private endpoint service list, service tag rule fields, required service tags, limitations

Azure Private Link for Azure SQL Managed Instance — Limitations, and Set up domain name resolution for private endpoint

Network security overview for Azure Machine Learning — customer-managed VNet option

Configure public endpoints in Azure SQL Managed Instance — enabling the public endpoint and port 3342 NSG rules

Thanks
Ajay Rathod 260 Reputation points Microsoft External Staff Moderator

2026-08-11T07:17:30.82+00:00

Let us know if this suggestion helped you.

1 answer

Your answer

Ajay Rathod 260 Reputation points Microsoft External Staff Moderator

2026-08-11T07:17:30.82+00:00

Let us know if this suggestion helped you.

Answer 1

With Allow only approved outbound, the AML managed network can create private endpoints only to supported targets. Microsoft's current list includes Azure SQL Server, not Azure SQL Managed Instance. A direct managed private endpoint to SQL MI is unsupported; the AzureMachineLearning service tag permits traffic but does not create private routing.

Use AML compute in a customer-managed VNet. Peer it with the SQL MI VNet, or create a SQL MI private endpoint in a VNet reachable from the compute. Configure DNS so the exact SQL MI hostname resolves to the private-endpoint address, use that hostname in the connection string, and permit TCP 1433. Test DNS and TCP connectivity from the compute node.

Managed virtual networking cannot be disabled on an existing workspace, so this design may require a new workspace. Do not use an FQDN outbound rule as a workaround; AML FQDN rules support only ports 80 and 443.

How to establish connection between azure AML workplace and azure Sql MI via private endpoint

Option A — Keep it private: move to a customer-managed VNet (recommended)

1 answer

Your answer