Set up private link to SQL Server on Azure Virtual Machine
Your Azure administrator needs to complete several steps—you may not have the required permissions yourself.
Azure Private Link creates a secure, private connection between services running in Azure. This document describes the steps to set this up between SQL Server on an Azure Virtual Machine (IaaS) and Atlan across two Azure subscriptions.
Unlike Azure SQL Database (PaaS), SQL Server on a VM doesn't have a built-in Private Link resource. Private connectivity must be constructed manually using an Azure Standard Internal Load Balancer and a Private Link Service (PLS) in your subscription, with a Private Endpoint created in Atlan's subscription targeting that PLS.
The Private Link Service, Internal Load Balancer, and the VM must all reside in the same Azure region. The Private Endpoint in Atlan's subscription must also be in the same region as the PLS.
Prerequisites
Your side (Producer—Subscription A)
You must already have the following:
- An active Windows or Linux VM running SQL Server in a supported Azure region.
- SQL Server listening on a fixed port (default: 1433). Dynamic ports must be disabled.
- A Standard SKU Internal Load Balancer deployed in the same VNet as the SQL Server VM. Basic SKU load balancers don't support Private Link Service.
- A health probe targeting port 1433 configured on the load balancer.
- The SQL Server VM NIC or IP added to the backend pool of the Internal Load Balancer.
- A Private Link Service (PLS) attached to the Internal Load Balancer frontend, with network policies for private endpoints disabled on the target subnet.
- The full PLS Resource ID or alias to share with the Atlan Support team (found under Private Link Center → Private link services → [Your PLS] → Properties → Resource ID).
- Contributor or Owner role permissions on the relevant resource group.
Atlan provides its private VNet CIDR range during setup coordination. You must add an inbound NSG rule allowing TCP 1433 from that CIDR so traffic from the Private Endpoint can reach the SQL Server VM through the Internal Load Balancer.
Atlan's side (consumer—Subscription B)
Atlan needs the following from you before proceeding:
- The PLS alias or full Resource ID.
- Optionally, the SQL Server hostname for DNS configuration.
Configure internal load balancer
Deploy a Standard Internal Load Balancer in the same VNet as the SQL Server VM and configure it to forward traffic to the VM on port 1433.
Create or verify standard internal load balancer
- In the Azure Portal, navigate to Load Balancers → Create.
- Set SKU to Standard and Type to Internal.
- Assign the load balancer to the same VNet and subnet as the SQL Server VM.
- Configure a Frontend IP configuration using a static private IP within the subnet.
Configure backend pool
- Under the load balancer, navigate to backend pools → Add.
- Add the SQL Server VM's NIC or IP address to the backend pool.
Configure health probe
- Navigate to Health probes → Add.
- Set Protocol to TCP and Port to 1433.
- Set Interval to 5 seconds and Unhealthy threshold to 2.
Configure load balancing rule
- Navigate to Load balancing rules → Add.
- Set Frontend IP to the load balancer frontend IP configured earlier.
- Set Protocol to TCP, Frontend port to 1433, and back-end port to 1433.
- Select the backend pool and health probe created earlier.
- Make sure Floating IP (direct server return) is set to Disabled.
After completing this section, verify the load balancer health probe status shows the backend VM as Healthy before proceeding.
Create Private Link service
Create a Private Link Service (PLS) attached to the Internal Load Balancer. This is the resource Atlan targets when creating the Private Endpoint.
- In the Azure Portal, navigate to Private Link Center → Private link services → Create.
- Select the Subscription and Resource Group where the Internal Load Balancer resides.
- Under Load balancer, select the Standard Internal Load Balancer configured earlier.
- Under Load balancer frontend IP configuration, select the frontend IP.
- Optionally, add Atlan's Subscription ID to the auto approval list to skip manual approval later.
- Click Review + Create and confirm.
Retrieve and share PLS alias
- After PLS creation, navigate to Private Link Center → Private link services → [Your PLS].
- Copy the Alias value. It follows this format:
<pls-name>.<guid>.<region>.azure.privatelinkservice
- Contact Atlan support and share the alias securely.
Alternatively, share the full PLS Resource ID found under Properties. The alias is preferred as it doesn't expose subscription details.
Once Atlan receives the alias, the team creates a Private Endpoint in the Atlan subscription targeting your PLS. The connection remains in a Pending state until you approve it in the next step.
Approve private endpoint connection
After Atlan creates the Private Endpoint, a pending connection request appears in your Azure portal under the Private Link Service. You must explicitly approve this request.
- In the Azure Portal, navigate to Private Link Center → Private link services → [Your PLS].
- Select Private endpoint connections from the left menu.
- Locate the pending connection request from Atlan (identifiable by the endpoint name or requesting subscription ID).
- Select the request and click Approve.
- Optionally, enter an approval message and click Yes to confirm.
- Confirm the connection status updates to Approved.
After approval, Azure propagates the status to Atlan's Private Endpoint within a few minutes. The endpoint NIC receives a private IP from Atlan's subnet and becomes active.
Restrict public access (recommended)
To make sure all SQL Server access flows exclusively through the private endpoint, restrict public-facing access at the NSG and Windows Firewall level:
- Remove or tighten any inbound NSG rules permitting TCP 1433 from public internet sources (
0.0.0.0/0). - On the VM's Windows Firewall, restrict SQL Server inbound rules to the Private Link Service NAT IP range only.
- Confirm no public IP is directly associated with the SQL Server VM NIC.
Restricting public access at the NSG and firewall level ensures all SQL Server traffic is routed exclusively through the approved Private Endpoint. This is the recommended security posture for production environments.
Troubleshooting
| Issue | Likely cause | Resolution |
|---|---|---|
| Private Endpoint stuck in Pending state | You haven't approved the PLS connection request | Navigate to Private Link Center → Private link services → [Your PLS] → Private endpoint connections and approve the request |
| LB health probe shows backend as unhealthy | SQL Server not listening on port 1433, or Windows Firewall blocking the probe | Verify SQL Server is running and listening on a fixed port 1433. Check Windows Firewall rules on the VM |
| DNS resolves to a public IP instead of a private IP | Custom DNS zone not linked to Atlan's VNet, or A record missing or incorrect | Atlan must verify the Private DNS Zone is linked to its VNet and the A record points to the Private Endpoint's private IP |
| Connection timeout on port 1433 | NSG blocking traffic between the Private Endpoint subnet and the load balancer, or LB rule misconfigured; or Atlan's private CIDR not added to the inbound NSG | Check NSG inbound rules on the LB subnet and VM subnet for port 1433. Verify LB rule, backend pool, and health probe are all correctly configured |
| Connection approved but application can't connect | Application connection string uses a public hostname or IP bypassing DNS, or SQL Server login or firewall rule missing | Make sure the app uses the SQL Server hostname (not a public IP). Confirm SQL Server logins and firewall permit connections from the Private Endpoint IP range |
😅 The connection is now established. You can now use Azure Private Link to crawl Microsoft SQL Server in Atlan! 🎉