Choose how Atlan connects to SQL Server
Compare the three ways Atlan can reach your Microsoft SQL Server - direct with IP allowlisting, a private network link, or the self-deployed runtime - and pick the right one before you touch any firewall.
There are three ways for Atlan to reach your Microsoft SQL Server - whether it runs on-premises, on a cloud VM, on Amazon RDS, or as Azure SQL Database / Managed Instance. This page helps you pick the right one in about two minutes, before you touch any firewall.
Before you start: Two facts you need
Every path below depends on knowing these two things. Gather them first - they determine which options are even available to you.
| Fact | How to find it |
|---|---|
| Where your SQL Server runs and how it's reachable (on-premises datacenter, Azure VM, Azure SQL Database, Azure SQL Managed Instance, Amazon RDS/EC2 - and whether its hostname resolves on the public internet) | Ask your database administrator (DBA). A quick test: if the server's hostname ends in something like .local or only resolves inside your office network, it is not reachable from the internet - direct connectivity won't work. |
| Which cloud and region your Atlan tenant runs on | Ask your Atlan admin, or raise a support request from within Atlan: "Which cloud and region is my tenant hosted in, and what are its outbound IP addresses?" Every tenant has different addresses - values that worked for another tenant (even your own sandbox) will not carry over. |
Compare three methods
| Direct + IP allowlisting | Private network link | Self-deployed runtime (agent) | |
|---|---|---|---|
| Traffic path | Public internet, TLS-encrypted, from your Atlan tenant's fixed outbound IPs to your server's port 1433 | Never leaves the cloud provider's private network (AWS PrivateLink or Azure Private Link) | Extraction runs on infrastructure inside your own network; only outbound HTTPS (port 443) to Atlan |
| Works when your SQL Server is | Reachable from the internet (public hostname, firewall you can open) | In AWS (EC2, RDS) or Azure (VM, SQL Database, Managed Instance) with no public access | Anywhere - including on-premises datacenters and partner networks |
| Who is involved | You + your DBA / network team | You + your cloud/network team + Atlan support (endpoint build + approval handshake) | Your infrastructure/Kubernetes team + Atlan support |
| Start here | Direct connection guide | Private network links | Special cases - self-deployed runtime |
Older SQL Server docs and workflows referenced an "offline extraction" method (you export metadata and upload it to object storage). Per Crawl Microsoft SQL Server, that method has been discontinued. The supported extraction methods today are Direct and Agent (self-deployed runtime).
Private connectivity by cloud
"PrivateLink" is an AWS product name - each cloud brands its private path differently, and Atlan's support for SQL Server differs per cloud:
| Your SQL Server runs on | Private option | Guide |
|---|---|---|
| Amazon EC2 or RDS | AWS PrivateLink - you build an NLB + endpoint service | EC2 guide / RDS guide |
| Azure Virtual Machine | Azure Private Link - you build a load balancer + Private Link service | Azure VM guide |
| Azure SQL Database / SQL Managed Instance | Azure Private Link, built into the PaaS service - no load balancer; you collect identifiers and approve | Azure SQL Database guide |
| Google Cloud (Cloud SQL for SQL Server) | No documented Private Service Connect path for SQL Server today - use the self-deployed agent | Special cases |
A private link requires your Atlan tenant and the database in the same cloud - cross-cloud setups (for example, an Azure-hosted tenant and an RDS database) fall back to the self-deployed agent. Start with Private network links for the pattern all variants share.
Which method to pick
- Pick direct + IP allowlisting if your SQL Server has a publicly resolvable hostname and your security policy allows TLS traffic from known IPs. It's the fastest path - one support ticket for your tenant's outbound IPs, one firewall rule on your side.
- Pick a private network link if your SQL Server lives in AWS or Azure with public access disabled (very common for Azure SQL Database with "Selected networks", or RDS in a private subnet). Budget for the approval handshake and involve your cloud team early.
- Pick the self-deployed runtime if the server is only reachable from inside your network - on-prem datacenters, partner networks, private DNS zones - and building a cloud private link isn't possible.
The single most common failed first attempt is pointing the crawler at a hostname that only resolves inside your network (e.g. sqlprod01.corp.example-corp.local). Atlan's crawler runs in Atlan's cloud, not yours - it cannot resolve or reach private names. If your hostname is private, go straight to a private link or the self-deployed runtime; no credential or firewall change will make direct connectivity work.
See also
- How SQL Server connectivity works - the 5-minute explainer, no cloud knowledge assumed. Read this if "endpoint", "NAT IP", or "listener" are new terms.
- Atlan Network Details - where Atlan's connections come from and how to get your tenant-specific values.
- Direct connection guide - four phases, each labeled with who performs it.
- Private network links - one common pattern across AWS EC2/RDS, Azure VM, and Azure SQL Database / Managed Instance.
- Firewalls and allowlists - every firewall layer, which Atlan value belongs in each, and the mistakes that generate the most support tickets.
- Special cases - on-premises servers, NTLM and Entra ID quirks, Managed Instance failover groups, and multi-environment estates.