Private network connectivity to your data sources
A decision guide for connecting Atlan to your data sources privately, without crossing the public internet—which pattern fits your cloud and source.
Atlan can connect to your data sources without any traffic crossing the public internet. All private connectivity patterns require a Single Tenant SaaS deployment of Atlan (a dedicated VPC or VNet for your tenant)—contact your Atlan representative if you are unsure of your deployment type. This page covers which pattern applies to your cloud and source type, and where to go to set it up.
Choosing which pattern to use
1. Which cloud is your Atlan tenant hosted on? Private connectivity primitives don't cross cloud boundaries: an AWS-hosted tenant consumes AWS PrivateLink, an Azure-hosted tenant consumes Azure Private Link, a GCP-hosted tenant consumes Private Service Connect. If your tenant and your source are in different clouds, none of the standard patterns apply, see cross-cloud sources below.
2. Where does the source actually live? Four answers, four very different setups:
| The source is… | Examples | How Atlan connects |
|---|---|---|
| A resource in your VPC/VNet | RDS, Aurora, databases on VMs, self-hosted Trino/Kafka, SQL Server on a VM | The private connectivity patterns on this page, pick by cloud and scale below |
| A cloud provider's regional API | AWS Glue, Athena, S3, DynamoDB; BigQuery, GCS; QuickSight | Not through your network at all. Most AWS APIs use HTTPS + cross-account IAM role. Some AWS services have connector-specific PrivateLink setups where Atlan manages the endpoint on your behalf—see the connector's doc for details. Google APIs: optionally a private path via Google APIs PSC for GCP-hosted tenants |
| A vendor's SaaS | Snowflake, Databricks, Tableau Cloud, Looker, Fivetran, dbt Cloud | The endpoint lives in the vendor's network. Snowflake and Databricks publish their own private connectivity offerings per cloud, consumed by Atlan with the vendor's authorization flow; most other SaaS tools are HTTPS-only |
| On-premises | Oracle in your data center, on-prem Tableau Server, SAP HANA appliances | Your existing link into your cloud network first (Direct Connect / ExpressRoute / VPN), then the cloud's pattern fronts the on-prem address, on AWS, classic PrivateLink with the NLB targeting the on-prem IP |
AWS-hosted tenants
AWS is the only cloud with multiple patterns, because AWS ships multiple primitives. They form a progression by scale:
| Classic PrivateLink | PrivateLink via resource gateway | VPC Lattice | |
|---|---|---|---|
| You build | NLB + target groups + endpoint service | Resource gateway + per-database resource configuration | Gateway + configurations + one service network |
| You maintain | Target-group health as database IPs churn | Nothing, no targets to keep healthy | Nothing |
| Adding a database | New listener + target group + Atlan coordination | New RAM share + Atlan-side endpoint | Self-service on your side, no Atlan handoff |
| Reaches | Anything routable, including on-prem and cross-account hubs | AWS VPC resources only | AWS VPC resources only |
| Sweet spot | A few sources; on-prem; multi-account Redshift hubs | A few AWS-native databases with minimal infrastructure | Tens to hundreds of databases across VPCs and accounts |
Rules of thumb from real deployments:
- One or two RDS databases → resource gateway. Least infrastructure, nothing to maintain.
- A fleet of databases across VPCs or accounts → VPC Lattice. One share, then adding databases never involves Atlan again.
- On-prem, a proxy in the path, or a multi-account hub → classic PrivateLink. It's the only pattern that can target anything routable.
- RDS IAM authentication → Lattice preserves real database hostnames natively; classic PrivateLink needs a private-hosted-zone workaround. Factor this in early.
- Whatever you pick, don't publish the same database over two private paths, DNS precedence makes one path silently win and turns troubleshooting into archaeology.
Azure-hosted tenants
One pattern, Azure Private Link, with two producer flavors: PaaS services (Azure SQL, Synapse, Databricks) take a private endpoint directly with nothing to build, while IaaS sources (databases on VMs, SAP HANA) need a Standard SKU internal load balancer + Private Link Service on your side. Endpoints are strictly per-resource and per-workspace, so a large estate must be planned as an inventory with Atlan support rather than ticket-by-ticket.
GCP-hosted tenants
One product, Private Service Connect, in two patterns: Google APIs PSC for BigQuery and GCS (Atlan builds everything; your side is IAM and VPC Service Controls), and published-service PSC for databases in your VPC (you publish a service attachment behind an internal TCP load balancer), the latter arranged case-by-case with Atlan support.
Cross-cloud sources and other special cases
Tenant in one cloud, source in another. The standard patterns stop at the cloud boundary. For Single Tenant SaaS deployments, Atlan offers a cross-cloud option: Atlan deploys an endpoint layer in the source's cloud and establishes a secure tunnel back to your tenant. Alternatives, in rough order of preference: a site-to-site VPN, a proxy in the tenant's cloud routed onward over your own interconnect, or public connectivity with IP allowlisting. All of these are support-led, talk to Atlan before building.
Cross-region within one cloud. Endpoints are created in your tenant's region. Reaching sources in other regions is handled case-by-case, see Cross-region private network connectivity.
Push-based integrations (dbt Core artifacts, OpenLineage/Airflow events) flow in the opposite direction, your systems call Atlan's API, so none of these patterns apply. Inbound private access to Atlan's API/UI is its own mirror-image setup; ask Atlan support.
When no private pattern fits, unsupported source type, cross-cloud without Single Tenant SaaS, or an org constraint, the fallbacks are IP allowlisting of Atlan's egress addresses, or Atlan's Self-Deployed Runtime, an agent that runs inside your network and connects outward, so no inbound path to your sources is needed at all.
Principles that apply to every pattern
These hold across every cloud and pattern on this page, and they resolve the majority of support tickets:
- Traffic is one-way. Atlan initiates connections to your sources; nothing in these setups connects into Atlan, and nothing enters your network beyond the specific path you approved.
- The network and authentication are separate layers. Establish and validate TCP reachability first, then authentication. On a brand-new setup, "authentication failed" from a connector is usually a timeout in costume; an explicit "access denied for user" means the network is fine.
- Approval opens the control plane, not the data plane. Accepting a connection (RAM share, endpoint approval, service attachment) never opens security groups, NSGs, or firewalls. Those are always a separate, explicit step on your side.
- Everything is per-environment. Your production and non-production Atlan tenants are separate consumers: separate shares, endpoints, approvals, and network ranges. Reusing values across environments fails silently.
- Ask for Atlan's identifiers, don't assume them. Account IDs, principals, and network ranges are tenant-specific and provided by Atlan support per setup.
See also
- AWS · AWS VPC Lattice: The at-scale pattern, one service-network share, self-service database onboarding, real hostnames preserved for RDS IAM auth.
- AWS · PrivateLink via VPC resource gateways: Share individual RDS databases with no NLB, endpoint service, or target-group maintenance.
- AWS · PrivateLink, classic (NLB + endpoint service): The broadest reach, on-prem sources, proxies, and multi-account hubs behind one NLB.
- Azure · Azure Private Link: Private endpoints into PaaS services directly, or IaaS sources behind a Standard ILB + Private Link Service.
- Google Cloud · Private Service Connect: Google APIs PSC for BigQuery/GCS, published-service PSC for databases in your VPC.
Connector-specific PrivateLink setups
Some AWS services expose a regional API endpoint that Atlan can reach over PrivateLink without any infrastructure on your side. In these patterns, Atlan creates and owns the interface VPC endpoint inside Atlan's own AWS account. Your side of the setup is an IAM policy condition that permits only calls originating from Atlan's endpoint ID.
How Atlan connects to Amazon QuickSight privately
Atlan creates an interface VPC endpoint for the QuickSight regional API service (com.amazonaws.<region>.quicksight) inside Atlan's AWS account. Atlan's connector calls the QuickSight API through this endpoint, which carries the request over AWS PrivateLink directly to the regional QuickSight service. Your IAM policy permits the call only because it recognizes Atlan's endpoint ID—the public internet is never part of this path.
To set this up, see Set up a private network link to Amazon QuickSight.