Private connectivity with AWS PrivateLink resource gateways
Atlan supports private network connectivity to your AWS-hosted databases using AWS PrivateLink's VPC resource gateway pattern, a newer PrivateLink primitive (built on the same infrastructure as VPC Lattice) that lets you share individual resources, such as an RDS database, across accounts without building a Network Load Balancer or VPC endpoint service.
Traffic between Atlan and your database stays entirely on the AWS private network. Your database doesn't need to be publicly accessible, and your VPC is never peered or associated with Atlan's.
This connectivity option requires a Single Tenant SaaS deployment of Atlan (a dedicated Atlan VPC). Contact your Atlan representative if you are unsure of your deployment type.
Why this pattern exists
Classic AWS PrivateLink requires you to stand up a Network Load Balancer in front of each database (or a shared NLB with one listener port per database), publish it as a VPC endpoint service, and manage target-group health as database IPs change. That works well for a handful of sources, but it puts real operational load on your networking team: NLB target groups go stale when RDS fails over, listener ports must be tracked per database, and every new database is a coordinated change with Atlan.
The resource gateway pattern removes all of that. You create a resource gateway (a lightweight, managed entry point in the database's VPC) and a resource configuration per database, then share it with Atlan via AWS RAM. There is no load balancer, no endpoint service, no target group, and no health-check maintenance.
Building blocks
| Component | What it does |
|---|---|
| Resource gateway | A private entry point into the VPC where your database lives. It receives inbound connections from Atlan and forwards them to the database, performing source NAT. One per VPC, spanning at least two subnets. |
| Resource configuration | A pointer to a single resource behind the gateway, identified by ARN (RDS/Aurora), DNS name, or IP address, plus the allowed ports. One per database. |
| AWS RAM share | Shares the resource configuration (directly, or via a service network) with Atlan's AWS account. This grants access only to that specific resource, not to your VPC or account. |
| Atlan-side VPC endpoint | Atlan accepts the share and creates an endpoint in your Atlan tenant's VPC. Each shared resource surfaces in the Atlan VPC as an endpoint-specific DNS name and port. |
Two ways to share
- Standalone resource share, RAM-share an individual resource configuration; Atlan consumes it through a Resource-type VPC endpoint. Suitable for one or two databases.
- Service network share (recommended), associate your resource configurations with a VPC Lattice service network and RAM-share the service network once. Atlan creates a single service-network endpoint, and every resource configuration you associate afterwards becomes reachable with no further handoff. This is the pattern Atlan customers run in production and the right choice beyond a couple of databases. See Connect Atlan using AWS VPC Lattice for the full service-network guide.
How Atlan connects
Each shared database surfaces in Atlan's VPC as an endpoint-specific DNS name with an assigned port.
- You create the resource gateway and resource configuration, and share with Atlan's AWS account via AWS RAM.
- Atlan verifies the share is visible, accepts it, and creates the VPC endpoint in your tenant's VPC. The endpoint must reach the Available state before anything can connect.
- Each shared database surfaces in the Atlan VPC as an endpoint-specific DNS name with an assigned port, for example, a hostname of the form
vpce-xxxx.vpce-svc-xxxx.<region>.vpce.amazonaws.comon a port such as6001, rather than the database's native5432. You configure the Atlan connector with exactly the hostname and port Atlan support confirms with you. - When a connector runs, traffic flows: Atlan connector → VPC endpoint in the Atlan VPC → resource gateway in your VPC → database. The gateway performs source NAT, so your database sees connections arriving from the gateway's addresses, not from Atlan.
Properties worth understanding:
- Traffic is one-way. Atlan initiates all connections; nothing in your network connects into Atlan. Only return traffic flows back, and no VPC association is required for the database's VPC, the path is ingress-only.
- The assigned port is intentional. A connector configured with port
6001against avpce-…hostname isn't a misconfiguration, it's how shared resources are addressed on the consumer side. Don't "correct" it to the native database port. - RDS IAM authentication needs the real hostname. IAM token generation validates against the genuine
*.rds.amazonaws.comhostname, which an endpoint-specificvpce-…name can't satisfy. If you need RDS IAM auth, tell Atlan support up front, the setup then uses private DNS so the true database hostname resolves inside the Atlan VPC (the default behavior with a service-network share, and solvable with a private hosted zone otherwise). - Authentication is a separate layer. Network reachability is established first; then Atlan authenticates using either database credentials or a cross-account IAM role you provision (role ARN + external ID, with Atlan's tenant node role as the trusted principal). A working network path with a failing login is a database-grants or role-trust problem, not a PrivateLink problem.
How it compares
| Classic PrivateLink (NLB + endpoint service) | PrivateLink via resource gateway | VPC Lattice service network | |
|---|---|---|---|
| Customer builds | NLB, target groups, listeners, endpoint service | Resource gateway + resource configuration | Gateway + configurations + service network |
| Per-database effort | New listener port, target group, health checks | New resource configuration | New resource configuration (self-service, no Atlan handoff) |
| RDS failover / IP churn | Target groups can go stale; needs monitoring or automation | Handled by AWS, no targets to maintain | Handled by AWS |
| Shares with Atlan | Endpoint service name + AZ IDs, allowlist Atlan's principal | One RAM share per resource | One RAM share total |
| Best for | A few databases; sources that need an NLB anyway (on-prem via proxy, Redshift multi-cluster hubs) | A few databases, minimal infra | Tens to hundreds of databases |
If you already operate a working classic PrivateLink to Atlan, there is no need to migrate, the patterns coexist. Choose the resource-gateway path for new setups where you'd rather not own an NLB.
How's this different from VPC Lattice?
Less than the naming suggests. The resource gateway and resource configuration are VPC Lattice primitives, both options use the exact same data plane: a gateway in your VPC performing source NAT, TCP-only, one-way Atlan-to-you traffic, ingress-only with no VPC association. What differs is how the shared resources are consumed:
| PrivateLink via resource gateway | VPC Lattice service network | |
|---|---|---|
| What you share with Atlan | Each individual resource configuration, via its own RAM share | The service network, once |
| Atlan-side endpoint | A Resource-type VPC endpoint per shared resource | One service-network endpoint, ever |
| Adding another database | New RAM share + new Atlan-side endpoint, a coordinated handoff per database | Associate a new resource configuration on your side; it becomes reachable from Atlan automatically |
| Grouping and isolation | None, point-to-point resource sharing | The service network is the grouping: per-environment isolation, up to 500-1,000 resources behind one share |
| CIDR constraint | Point-to-point, so no cross-resource routing concerns | VPCs with overlapping CIDRs can't coexist on one service network |
In short: the resource-gateway share is the point-to-point flavor, and the service network is the many-to-one flavor of the same underlying path. The unit of sharing is the only real difference, and it determines the operational cost of every database after the first. The per-resource share-and-endpoint exchange stops being worth it at around the second database, which is why Atlan recommends the service-network flavor for anything beyond one or two sources.
Don't publish the same database over more than one private path (for example, both a Lattice service network and a dedicated PrivateLink endpoint). The Lattice path takes DNS precedence inside the Atlan VPC, which makes the other path silently unused and confuses troubleshooting. Pick one path per database.
Which connectors can use this path?
The deciding question is the same as for any resource-gateway-based connectivity: does the source have a private TCP endpoint inside your AWS VPC? If yes, a resource configuration can front it. If the source is a regional AWS API, a vendor-hosted SaaS, in another cloud, or pushes data to Atlan, this path doesn't apply.
Supported over resource gateway
| Connector | Resource configuration type | Notes |
|---|---|---|
| PostgreSQL (RDS / Aurora) | ARN | Recommended path; validated in production at scale |
| MySQL / MariaDB (RDS / Aurora) | ARN | Recommended path; validated in production at scale |
| SQL Server (RDS) | ARN | |
| Oracle (RDS) | ARN | |
| Amazon Redshift | DNS or IP | Possible by design, but Atlan's validated Redshift path today is classic PrivateLink (NLB with port-based routing) or Redshift-managed endpoints, confirm with Atlan support first |
| Amazon DocumentDB | DNS or IP | Via the MongoDB connector |
| Self-hosted databases on EC2 (PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, Cassandra, ClickHouse, SingleStore, and similar) | DNS or IP | Any TCP endpoint reachable from the resource gateway's VPC |
| Trino / Starburst, Presto, Hive (self-managed or EMR in your VPC) | DNS or IP | Coordinator/metastore endpoint fronted by DNS |
| Kafka (Amazon MSK or self-managed in your VPC) | DNS or IP | Every broker's advertised listener must be resolvable and fronted, not just the bootstrap address, validate with Atlan support before committing |
| Teradata Vantage, SAP HANA (deployed in your AWS VPC) | DNS or IP |
Not applicable to this path
| Connector | Why not | How Atlan connects instead |
|---|---|---|
| AWS Glue | Regional AWS API, there is no endpoint in your VPC for a resource gateway to front | AWS API over HTTPS; access controlled by cross-account IAM role + external ID |
| Amazon Athena | Regional AWS API | AWS API + IAM role |
| Amazon S3 | Regional AWS API | AWS API + IAM role |
| Amazon DynamoDB | Regional AWS API (no ARN-type resource configuration either) | AWS API + IAM role |
| Snowflake | Vendor SaaS, the endpoint lives in Snowflake's AWS account, not your VPC | HTTPS; Snowflake's own PrivateLink offering for private connectivity |
| Databricks | Vendor SaaS control plane | HTTPS; Databricks PrivateLink for private connectivity |
| Google BigQuery, Cloud SQL, GCS | Runs on GCP, resource gateways are AWS-only with no GCP/Azure equivalent | HTTPS APIs; GCP-native private options where applicable |
| Microsoft Synapse, Fabric, Azure Data Lake, Power BI | Runs on Azure | HTTPS APIs |
| SaaS BI and tools (Tableau Cloud, Looker, Sigma, Mode, ThoughtSpot, Qlik Cloud, Salesforce, Fivetran, Matillion, dbt Cloud, and similar) | Vendor-hosted, no endpoint in your network at all | Vendor HTTPS APIs with tokens/OAuth |
| On-premises databases | Not reachable inside your AWS network on their own | Direct Connect or Site-to-Site VPN into your VPC first, then this path (or classic PrivateLink with a reverse proxy) |
| Push-based integrations (dbt Core artifacts, OpenLineage / Airflow events) | Traffic flows in the opposite direction, your systems push to Atlan; this path only carries Atlan-to-you traffic | Your pipeline calls Atlan's API endpoint |
A self-hosted instance of an otherwise-SaaS tool changes the answer: for example, Tableau Server or a Superset deployment running on EC2 in your VPC exposes a TCP (HTTPS) endpoint that a DNS-type resource configuration can front. Confirm the specific setup with Atlan support.
Prerequisites
- Access to the AWS account and VPC where your database resides, and IAM permissions to create a resource gateway, resource configuration, and AWS RAM share.
- Atlan's AWS account ID and your tenant's region, provided by Atlan support. The share and endpoint are same-region with your Atlan tenant.
- Database details: RDS/Aurora ARN (or DNS name / IP for other sources), engine, and port.
- For ARN-type configurations, the RDS/Aurora database must not be publicly accessible, AWS doesn't permit resource configurations for publicly accessible clusters.
- If the resource gateway lives in a different AWS account than the database (common with centralized networking accounts), confirm that a test instance in the gateway's VPC can reach the database before involving Atlan, cross-account routing and security groups are your side of the boundary.
Information to share with Atlan
When you raise the support ticket, provide the following. Gathering it up front turns a multi-round exchange into a single handoff.
| Detail | Example / notes |
|---|---|
| Resource configuration ARN (or service network name/ID/ARN for the service-network flavor) | arn:aws:vpc-lattice:<region>:<account>:resourceconfiguration/rcfg-… |
| Confirmation the AWS RAM share is in place | A screenshot of the share's principals and associations helps |
| Per database: engine and native hostname | PostgreSQL, mydb.abc123.<region>.rds.amazonaws.com |
| Per database: port | 5432, 3306, 1433 |
| Authentication method | Credential-based, or a cross-account IAM role (role ARN + external ID). Flag if RDS IAM auth is required, it changes the DNS setup |
| Which Atlan tenant | Production or non-production, each needs its own share and endpoint, and Atlan's network ranges differ per tenant |
In return, Atlan provides the values you need on your side: its AWS account ID and your tenant's region for the RAM share. Once the share is accepted and the endpoint is Available, Atlan shares back the endpoint DNS names and ports to use in your connections.
Set up connection
Step 1: Create resource gateway
In the AWS VPC console, go to PrivateLink and Lattice → Resource gateways:
- Select the VPC where the database lives.
- Select subnets in at least two Availability Zones, and make sure they have free IP addresses.
- Attach a security group governing what the gateway can send.
Step 2: Create resource configuration
- Type ARN for RDS/Aurora (recommended), or DNS / IP for other TCP sources.
- Select the resource gateway from Step 1.
- Specify TCP and the database ports.
Step 3: Open database security group
Add inbound rules on the database's security group allowing traffic from the resource gateway (reference the gateway's security group) on the database port. Also permit the VPC Lattice managed prefixes for your region, AWS publishes these as a managed prefix list, plus the link-local range 169.254.171.0/24. Missing these ranges is the single most common cause of connection timeouts after an otherwise-correct setup.
No egress rule changes are needed if your security groups use the default permit-all outbound; if you restrict egress, make sure return traffic to the gateway is permitted.
Step 4: Share with Atlan via AWS RAM
- In AWS RAM, create a resource share containing your resource configuration (or your service network, for the recommended at-scale pattern).
- Add Atlan's AWS account ID as the principal and enable Allow sharing with external accounts.
- Verify the share saved. Open the share after creation and confirm Atlan's account appears as a principal and the resources are listed. Shares that silently fail to save are the most common cause of a stalled setup.
Step 5: Send details to Atlan
Raise a support ticket with everything listed in Information to share with Atlan, the resource configuration ARN (or service network name/ID/ARN), confirmation the RAM share is in place, the per-database details, the authentication method, and which Atlan tenant this connects to.
What Atlan does next
- Confirms the shared resource is visible from Atlan's account and accepts the RAM share.
- Creates the VPC endpoint in your tenant's VPC and waits for it to reach Available.
- Shares back the endpoint DNS names and ports to use in your connections.
- Validates TCP reachability from the Atlan cluster to each database, then validates authentication, before handing over for crawling.
Limitations and considerations
- TCP only, Layer 4 only. Resource gateways carry TCP traffic with no Layer 7 features. UDP isn't supported.
- Same region as your tenant. Cross-region sources need either your network extended into the tenant's region or a cross-region classic PrivateLink, handled case-by-case with Atlan support.
- ARN-type configurations cover RDS and Aurora only. Other sources (self-hosted databases on EC2, DocumentDB, and similar) use DNS- or IP-type configurations. For Redshift, Atlan's validated production path today is classic PrivateLink, discuss with Atlan support before planning Redshift over a resource gateway.
- On-premises sources are out of scope for this pattern on their own. A resource gateway can only front resources reachable inside your AWS network; on-prem databases first need Direct Connect or Site-to-Site VPN into your VPC.
- IP space matters on both sides. Gateways and endpoints consume subnet IPs. Atlan likewise needs free, contiguous address space in the tenant VPC for the endpoint, endpoint creation can fail on nearly-exhausted subnets even when a few addresses show as free.
- One share per environment. Production and non-production Atlan tenants are separate consumers: separate shares, separate endpoints, and different Atlan CIDR ranges. Reusing values across environments (for example, allowlisting the production tenant's ranges for a non-production setup) is a recurring source of silent failures.
- Avoid stale duplicates. Two service networks or shares under the same owner account targeting Atlan can prevent the endpoint from configuring correctly. Delete or unshare superseded ones.
Troubleshooting
Atlan reports nothing is shared. The RAM share didn't save, targets the wrong account ID or region, or external sharing is disabled. Re-open the share, verify the principal and resources, and re-share if needed. Atlan can't proceed until the resource is visible from its account.
Connection test times out. Timeouts are network-path issues; work through them in order:
- Confirm a test instance in the resource gateway's VPC can reach the database on its port. If this fails, the problem is between the gateway and the database (cross-account routing, security groups, NACLs), outside the PrivateLink path entirely.
- Check the database security group permits inbound from the resource gateway and the Lattice managed prefixes.
- Confirm the resource configuration is associated with the shared service network (if using one).
- Ask Atlan support to confirm the endpoint is Available and the association completed, an endpoint stuck mid-provisioning on Atlan's side produces exactly the same timeout.
"Authentication failed" errors on a brand-new setup. Connector frameworks often wrap TCP timeouts as authentication errors (for example, a connection-pool failure such as Cannot create PoolableConnectionFactory, or a driver login timeout). If the connection has never worked, treat it as a network problem first and validate reachability. Conversely, an explicit Access denied for user … error means the network path is fine, fix the database user's grants or the IAM role ARN / external ID pairing.
It worked from your desktop but not from Atlan. A local client connects to the database directly and never exercises the PrivateLink path. Only a test from the Atlan side (or from an instance routing through the gateway) validates the actual path.
A previously working connection stopped. Check, in order: the RAM share and endpoint are still in an accepted/available state (an unshared resource or rejected association drops traffic silently); no second private path to the same database was introduced; and no security-group or CIDR change landed on your side in the window when it broke.
See also
- Private connectivity overview: Decision guide for choosing the right connectivity pattern for your cloud and source type.
- PrivateLink, classic (NLB + endpoint service): The broadest reach—on-premises sources, proxies, and multi-account hubs.
- VPC Lattice: The at-scale option—one service-network share, self-service database onboarding.