## Choose how Atlan connects to SQL Server

URL: https://docs.atlan.com/apps/connectors/database/microsoft-sql-server/how-tos/choose-how-atlan-connects-to-microsoft-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](https://docs.atlan.com/support/submit-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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/connect-directly-with-ip-allowlisting/llms.txt) | [Private network links](https://docs.atlan.com/llms/connectors/microsoft-sql-server/private-network-links-to-microsoft-sql-server/llms.txt) | [Special cases - self-deployed runtime](https://docs.atlan.com/llms/connectors/microsoft-sql-server/special-cases/llms.txt) |

:::info Offline extraction is discontinued

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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/crawl-microsoft-sql-server/llms.txt), 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/set-up-a-private-network-link-to-microsoft-sql-server-on-amazon-ec2/llms.txt) / [RDS guide](https://docs.atlan.com/llms/connectors/microsoft-sql-server/set-up-a-private-network-link-to-microsoft-sql-server-on-amazon-rds/llms.txt) |
| Azure Virtual Machine | Azure Private Link - you build a load balancer + Private Link service | [Azure VM guide](https://docs.atlan.com/llms/connectors/microsoft-sql-server/set-up-a-private-network-link-to-sql-server-on-azure-virtual-machine/llms.txt) |
| 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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/set-up-a-private-network-link-to-azure-sql-database/llms.txt) |
| Google Cloud (Cloud SQL for SQL Server) | No documented Private Service Connect path for SQL Server today - use the self-deployed agent | [Special cases](https://docs.atlan.com/llms/connectors/microsoft-sql-server/special-cases/llms.txt) |

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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/private-network-links-to-microsoft-sql-server/llms.txt) 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.

:::tip The "private hostname" tell

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](https://docs.atlan.com/llms/connectors/microsoft-sql-server/how-sql-server-connectivity-works/llms.txt) - the 5-minute explainer, no cloud knowledge assumed. Read this if "endpoint", "NAT IP", or "listener" are new terms.
- [Atlan Network Details](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt) - where Atlan's connections come from and how to get your tenant-specific values.
- [Direct connection guide](https://docs.atlan.com/llms/connectors/microsoft-sql-server/connect-directly-with-ip-allowlisting/llms.txt) - four phases, each labeled with who performs it.
- [Private network links](https://docs.atlan.com/llms/connectors/microsoft-sql-server/private-network-links-to-microsoft-sql-server/llms.txt) - one common pattern across AWS EC2/RDS, Azure VM, and Azure SQL Database / Managed Instance.
- [Firewalls and allowlists](https://docs.atlan.com/llms/connectors/microsoft-sql-server/firewalls-and-allowlists/llms.txt) - every firewall layer, which Atlan value belongs in each, and the mistakes that generate the most support tickets.
- [Special cases](https://docs.atlan.com/llms/connectors/microsoft-sql-server/special-cases/llms.txt) - on-premises servers, NTLM and Entra ID quirks, Managed Instance failover groups, and multi-environment estates.

---