Private network links to Microsoft SQL Server

✦TL;DR

Connect Atlan to a SQL Server that has no public access, over AWS PrivateLink or Azure Private Link - one common five-phase pattern covering EC2, RDS, Azure VM, and Azure SQL Database / Managed Instance.

||

|Connect

Connect Atlan to a SQL Server that has no public access, over AWS PrivateLink or Azure Private Link. One common pattern covers all four variants - SQL Server on EC2, on RDS, on an Azure VM, and Azure SQL Database / Managed Instance. This page is the overview: the shared phases, the intake checklist, and the approval handshake. The cloud-specific guides linked below carry the detailed console steps.

New to private links?

Read How SQL Server connectivity works first. The plug (endpoint), the socket (service), the approval handshake, and the "which string goes where" table are all introduced there.

Which variant am I?

Your SQL Server runs on	What you build on your side	Detailed guide
Amazon EC2	Internal Network Load Balancer + endpoint service	EC2 guide
Amazon RDS	Internal NLB (targeting the RDS IP or, better, an RDS Proxy) + endpoint service	RDS guide
Azure Virtual Machine	Standard internal load balancer + Private Link service	Azure VM guide
Azure SQL Database / SQL Managed Instance	Nothing - the service natively supports private endpoints; you collect identifiers and approve	Azure SQL Database guide

Five phases at glance

Phase	What happens	Owner	Typical time
1. Prepare the socket	Build the load balancer + service (VM/EC2/RDS) or just collect identifiers (Azure SQL)	Your cloud/network team	1-3 hours (or 10 min for Azure SQL)
2. Share the intake packet	Send Atlan everything it needs, in one ticket	Atlan User	15 minutes
3. Atlan builds its endpoint	Endpoint created in your tenant's network; goes to pending	Atlan support	1-2 business days
4. Approve and open firewalls	Approve the pending connection; add NSG/SG rules for Atlan's private CIDR	Your cloud/network team	30 minutes
5. Connect and verify	Point the crawler at the endpoint DNS name and test	Atlan User	30 minutes

Phase 1 - Prepare socket

Owner: Your cloud/network team

Follow the detailed guide for your variant (table above). In summary:

• AWS (EC2 or RDS): create a target group (protocol TCP, your SQL port), register the instance (or the RDS IP), create an internal Network Load Balancer, and wait until the target shows Healthy - an unhealthy target is the top cause of "endpoint approved but connection times out". Then create a VPC endpoint service on the NLB and add Atlan's AWS account ID (from support) as an allowed principal.
• Azure VM: create a Standard internal load balancer (TCP health probe on 1433, backend pool = the VM), verify the probe shows Healthy, create a Private Link service on the frontend, and copy the PLS alias.
• Azure SQL Database / Managed Instance: nothing to build. Collect the server or Managed Instance Resource ID (Overview → JSON view), the fully qualified server name, and for failover groups the listener FQDN.

RDS target IPs change

Registering the RDS instance's current IP pins the NLB to an address that can change on failover or maintenance, silently breaking the link later. Prefer an RDS Proxy as the target, or put a process in place to re-register the IP. See the RDS guide.

Phase 2 - Share intake packet

Owner: Atlan User

Multi-day back-and-forth on private link tickets almost always comes from missing intake information. Send all of this in your first message:

• Your Atlan tenant URL
• The service identifier: endpoint service name (AWS), PLS alias or Resource ID (Azure VM), or server/MI Resource ID (Azure SQL)
• The server hostname (FQDN) the crawler should ultimately use - including failover-group listener names if any
• The port, if it isn't 1433
• The Azure region / AWS region and availability zones of the service - Atlan's endpoint must be compatible; for AWS, either match AZs or enable cross-zone load balancing on your NLB
• The authentication method you'll use (basic / service principal / NTLM)
• Who on your side will approve the pending connection (name the role, not a person)

Phase 3 - Atlan builds its endpoint

Owner: Atlan support

Atlan creates a private endpoint in your tenant's network targeting your socket - typically within 1-2 business days. The endpoint connection moves through this lifecycle:

1. Created - Atlan builds the endpoint (this phase).
2. Pending - waiting for your approval. Connections time out in this state.
3. Approved - you approved; traffic flows within minutes.
4. Usable - proceed to Phase 5.

Support replies with the endpoint DNS name for Phase 5, and (if a firewall stays active on your side) Atlan's private source CIDR for Phase 4.

Phase 4 - Approve and open remaining firewalls

Owner: Your cloud/network team

1. Approve the pending connection. AWS: VPC console → Endpoint services → your service → Endpoint connections → Accept. Azure: Private Link Center → your PLS (or the Azure SQL server → Private endpoint connections) → Approve. Nothing approves itself - someone must click.
2. Open the path behind the socket. The private link delivers traffic to your subnet - your NSG / security group / Windows Firewall still applies. Add an inbound rule allowing TCP 1433 from Atlan's private source CIDR (from your ticket - the public NAT IPs are irrelevant here). On AWS, note that "Enforce inbound rules on PrivateLink traffic" is on by default for NLB security groups - the inbound rule must cover Atlan's CIDR.
3. (Recommended) Close the public path once the private one is verified: tighten rules permitting TCP 1433 from 0.0.0.0/0.

Phase 5 - Connect and verify

Owner: Atlan User

1. In the crawler setup, enter the endpoint DNS name from Phase 3 in the Host field - not the PLS alias / service name, and not the server's public hostname (unless support confirms they've mapped your real hostname to the endpoint in DNS - ask, don't assume).
2. Enter the port, database, and credentials, then click Test Authentication.

Success checklist

• Connection state shows Approved on your side
• Load balancer target/probe shows Healthy (VM/EC2/RDS variants)
• Test Authentication passes in Atlan
• Preflight checks pass and a small crawl completes

Any step failing - see Troubleshooting SQL Server connectivity, which walks the private-link checks in root-cause order.