Connect Azure Databricks and Azure SQL DB using Private Endpoints across two different Azure tenants.

Mallikarjun appani 6 Reputation points
2026-05-20T12:30:04.32+00:00

We have a requirement to connect Azure Databricks and Azure SQL DB using Private Endpoints across two different Azure tenants.

Scenario:

  • Databricks workspace is in Tenant A
  • Source Azure SQL DB is in Tenant A
  • Target Azure SQL DB is in Tenant B
  • Both SQL databases must be accessed only through Private Endpoints (public access disabled)
  • Data movement will happen through Azure Databricks using incremental/full load pipelines

We understand Private Endpoints can work across tenants using Private Link, but we need guidance on the approval process from the remote tenant side.

Our main questions are:

  1. How should the Private Endpoint connection request be raised from Tenant A to resources in Tenant B?
  2. What exact permissions are required in the target tenant to approve the Private Endpoint?
  3. Who should approve the request in the target tenant (Subscription Owner / Network Team / SQL Admin)?
  4. Are there any DNS or VNet peering considerations for cross-tenant Private Endpoint connectivity between Databricks and Azure SQL DB?
  5. Has anyone implemented Databricks-to-Azure SQL DB cross-tenant communication fully over Private Link/private endpoints?

Any architecture guidance or best practices would be very helpful.

Azure Private Link
Azure Private Link

An Azure service that provides private connectivity from a virtual network to Azure platform as a service, customer-owned, or Microsoft partner services.

0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Alex Burlachenko 25,285 Reputation points MVP Volunteer Moderator
    2026-05-21T08:16:14.8266667+00:00

    hi Mallikarjun appani & thanks for join me here at Q&A portal,

    short answ is create PE in Tenant A by Tenant B SQL resource ID, Tenant B approves it, Tenant A owns DNS/private IP path, and Databricks connects to normal SQL FQDN which resolves privately. And yeah this is supported, but dont think of it as “Databricks peering to Tenant B”. The private endpoint lives in Tenant A VNet where Databricks can reach it, and it points to the Azure SQL server resource in Tenant B by full resource ID. After PE creation, Tenant B sees a Pending private endpoint connection on the SQL server and must approve it. Azure docs describe this manual approve/reject flow for Private Link connections.

    For the request from Tenant A, create Private Endpoint > connect to Azure resource by resource ID or alias > paste the SQL server resource ID from Tenant B > subresource should be sqlServer. If both tenants are not in the same directory, u normally wont browse the resource, u use the full resource ID.

    Approval happens in Tenant B on the Azure SQL logical server SQL server > Networking / Private endpoint connections > select pending connection > Approve. The approver needs permission on the SQL server to manage private endpoint connections, usually Owner or Contributor or a custom role with Microsoft.Sql/servers/privateEndpointConnectionsApproval/action / relevant private endpoint connection write actions. In practice this is usually done by the SQL platform owner or subscription/network owner in Tenant B, not the Databricks team.

    DNS is the part people mess up. In Tenant A, Databricks must resolve <target-sql-server>.database.windows.net to the private endpoint IP. Use private DNS zone privatelink.database.windows.net, link it to the Databricks VNet, and create the A record for the SQL server. Azure SQL private endpoint docs call out private DNS as required for clients to transparently route to the private endpoint.

    VNet peering between Tenant A and Tenant B is not required just coz SQL is in Tenant B. The private endpoint NIC is in Tenant A, so Databricks talks to a private IP in its own reachable network. U only need peering if Databricks compute is in another VNet and must reach the PE VNet.

    For Databricks see whether u use classic VNet-injected workspace or serverless. Classic compute must have route/DNS to the PE subnet. Serverless needs Databricks private connectivity setup separately.

    rgds,

    Alex

    &

    If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

    Was this answer helpful?

    1 person found this answer helpful.
  2. Ravi Varma Mudduluru 12,625 Reputation points Microsoft External Staff Moderator
    2026-05-21T12:34:20.2666667+00:00

    Hello @Mallikarjun appani

    Thank you for reaching out to Microsoft Q&A

    Yes, it's fully supported with Azure Private Link. You don't need VNet peering between tenants; the connection flows securely over the Microsoft backbone.

    Recommended Solution:

    High-level flow:

    1. In Tenant A (where your Databricks workspace lives), create a Private Endpoint that points to the Azure SQL logical server in Tenant B using its full resource ID.
    2. In Tenant B, approve the connection request.
    3. In Tenant A, configure the Private DNS zone so Databricks can resolve the SQL FQDN privately.
    4. Ensure your Databricks workspace is VNet-injected (or uses Network Connectivity Config for serverless) so the clusters can reach the Private Endpoint.

    Step-by-step Guidance

    From Tenant A:

    • Get the full Resource ID of the SQL server in Tenant B (/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Sql/servers/{server-name}).
    • Go to Private Link Center → Private endpoints → + Create.
    • Select your VNet/subnet (dedicated PE subnet recommended).
    • Choose Connect to an Azure resource by resource ID, paste the ID, and set the sub-resource to sqlServer.
    • Create the endpoint (it will stay in "Pending" state).

    In Tenant B (approval):

    • The owner of the SQL server will see the request under SQL Server → Security → Networking → Private access (or Private endpoint connections blade).
    • Approve it (you can add a comment for audit purposes).

    DNS Configuration (very important):

    • In Tenant A, create/link the Private DNS zone privatelink.database.windows.net to the VNet used by Databricks.
    • Connect using the standard SQL FQDN (<server>.database.windows.net) — it will resolve to the private IP automatically.

    Permissions needed in Tenant B:

    • Contributor (or Owner) on the SQL Server resource group is usually sufficient. SQL Admins or the platform/network team typically handle approvals.

    No cross-tenant VNet peering is required. Once set up, set Deny public network access = Yes on the SQL server in Tenant B.

    Official Documentation

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.