Grab a spot →
Skip to main content

Private connectivity with AWS VPC Lattice

Connect docs via MCP

Atlan supports private network connectivity to your AWS-hosted data sources using AWS VPC Lattice. With VPC Lattice, Atlan reaches your databases over the AWS private network, traffic never traverses the public internet, and your databases don't need to be publicly accessible.

VPC Lattice is the recommended private connectivity option when you need to connect many databases across multiple VPCs or AWS accounts. If you only need to connect a small number of databases, the resource gateway pattern or classic PrivateLink may be simpler.

note

VPC Lattice connectivity requires a Single Tenant SaaS deployment of Atlan (a dedicated Atlan VPC). Contact your Atlan representative if you are unsure of your deployment type.

What is AWS VPC Lattice?​

AWS VPC Lattice is an application networking service that connects services and resources across VPCs and AWS accounts without VPC peering, Transit Gateway, or per-service endpoints. For connecting Atlan to databases, four building blocks matter:

ComponentWhat it does
Resource gatewayA private entry point into the VPC where your database lives. It receives inbound connections and forwards them to resources in that VPC. You create one per VPC (spanning at least two subnets).
Resource configurationA pointer to a single resource behind a resource gateway, identified by ARN (for RDS/Aurora), DNS name, or IP address, plus the ports that are reachable. You create one per database.
Service networkA logical grouping that resource configurations are associated with. Consumers (like Atlan) connect to the service network once and can then reach every resource associated with it.
AWS RAM shareThe cross-account sharing mechanism. You share your service network (or an individual resource configuration) with Atlan's AWS account using AWS Resource Access Manager.

The key property that makes VPC Lattice attractive at scale: consumers connect to the service network, not to individual databases. Once the one-time share with Atlan is in place, adding a new database is a change you make entirely on your side, associate a new resource configuration with the service network, and it becomes reachable from Atlan automatically. There is no per-database handoff, endpoint, or load balancer.

How Atlan connects via VPC Lattice​

You own the VPC Lattice control plane; Atlan is purely a consumer of it. The connection is established once, then shared by all your database connections:

One service-network share carries every database; connectors use real hostnames on native ports.

  1. You create a resource gateway in each VPC that hosts databases, and a resource configuration for each database.
  2. You associate the resource configurations with a service network (typically in a central networking or management account), and share the service network with Atlan's AWS account via AWS RAM.
  3. Atlan accepts the RAM share and creates a service-network VPC endpoint in your Atlan tenant's VPC, enforced by Atlan-managed security groups.
  4. When a connector runs, traffic flows: Atlan connector → service-network endpoint in the Atlan VPC → VPC Lattice → your resource gateway → your database. The resource gateway performs source NAT, so your database sees the connection arriving from the gateway, not from Atlan directly.

A few properties of this design worth understanding:

  • Traffic is one-way. Atlan initiates connections to your databases; your network never initiates connections into Atlan. Only return traffic flows back.
  • DNS is propagated automatically. Once the association is complete, VPC Lattice advertises each resource's DNS name privately into the Atlan VPC. You configure Atlan connectors with the real database hostname and native port (for example, mydb.cluster-xxxx.us-east-2.rds.amazonaws.com:5432), not a vpce-… endpoint name. When you advertise a new database on the service network, its DNS propagates to Atlan without any action on Atlan's side.
  • IAM database authentication works. Because connectors use the database's genuine hostname, RDS IAM authentication, which validates against the true endpoint name, works over VPC Lattice. Atlan assumes a single cross-account IAM role (role ARN + external ID) that you provision, rather than needing per-database credentials plumbing.
  • Overlapping CIDRs between your network and Atlan's are fine. VPC Lattice doesn't route on your VPC address space the way peering does, so Atlan's VPC CIDR overlapping with yours isn't a problem.
AWS PrivateLinkAWS VPC Lattice
Unit of connectionOne NLB + endpoint service + interface endpoint per database (or per group, with port-based routing)One service network share; databases are associated on your side
Adding a databaseNew setup and handoff with AtlanSelf-service, associate a resource configuration, no Atlan involvement
Database DNSConnectors point at a vpce-… endpoint; RDS failover requires target-tracking automationConnectors use the real RDS hostname; DNS propagates automatically
RDS IAM authNot compatible with vpce-… hostnamesSupported (real hostname preserved)
ScalePractical for a handful of databasesUp to 500 resource configurations per service network (adjustable to 1,000)
Cross-regionSupportedSame-region only

As a rule of thumb: use PrivateLink for a few databases; use VPC Lattice when you have tens to hundreds of databases spread across VPCs and accounts, or when you need RDS IAM authentication.

Which connectors can use VPC Lattice?​

The deciding question is always the same: does the source have a private TCP endpoint inside your AWS VPC? If yes, VPC Lattice can carry the traffic. If the source is a regional AWS API, a vendor-hosted SaaS, in another cloud, or pushes data to Atlan, VPC Lattice doesn't apply.

Supported over VPC Lattice​

ConnectorResource configuration typeNotes
PostgreSQL (RDS / Aurora)ARNRecommended path; validated in production at scale
MySQL / MariaDB (RDS / Aurora)ARNRecommended path; validated in production at scale
SQL Server (RDS)ARN
Oracle (RDS)ARN
Amazon RedshiftDNS or IPNo ARN-type support in AWS; front the cluster endpoint by DNS
Amazon DocumentDBDNS or IPVia the MongoDB connector
Self-hosted databases on EC2 (PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, Cassandra, ClickHouse, SingleStore, and similar)DNS or IPAny TCP endpoint reachable from the resource gateway's VPC
Trino / Starburst, Presto, Hive (self-managed or EMR in your VPC)DNS or IPCoordinator/metastore endpoint fronted by DNS
Kafka (Amazon MSK or self-managed in your VPC)DNS or IPEvery 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 VPC Lattice​

ConnectorWhy notHow Atlan connects instead
AWS GlueRegional AWS API, there is no endpoint in your VPC for a resource gateway to frontAWS API over HTTPS; access controlled by cross-account IAM role + external ID
Amazon AthenaRegional AWS APIAWS API + IAM role
Amazon S3Regional AWS APIAWS API + IAM role
Amazon DynamoDBRegional AWS API (no ARN-type resource configuration either)AWS API + IAM role
SnowflakeVendor SaaS, the endpoint lives in Snowflake's AWS account, not your VPCHTTPS; Snowflake's own PrivateLink offering for private connectivity
DatabricksVendor SaaS control planeHTTPS; Databricks PrivateLink for private connectivity
Google BigQuery, Cloud SQL, GCSRuns on GCP, VPC Lattice is AWS-only with no GCP/Azure equivalentHTTPS APIs; GCP-native private options where applicable
Microsoft Synapse, Fabric, Azure Data Lake, Power BIRuns on AzureHTTPS 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 allVendor HTTPS APIs with tokens/OAuth
Push-based integrations (dbt Core artifacts, OpenLineage / Airflow events)Traffic flows in the opposite direction, your systems push to Atlan; Lattice only carries Atlan-to-you trafficYour pipeline calls Atlan's API endpoint
note

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.
  • IAM permissions to create a VPC resource gateway, a resource configuration, and an AWS RAM resource share.
  • Atlan's AWS account ID and your tenant's region, provided by Atlan support. Your Atlan tenant's VPC endpoint is created in the same region as your tenant, so your service network must be in that region.
  • Database details: the RDS/Aurora ARN (or DNS name / IP address for non-RDS sources) and the ports Atlan needs to reach.
  • The database must not be publicly accessible if you want to use an ARN-type resource configuration, AWS doesn't permit resource configurations for publicly accessible RDS clusters.

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.

DetailExample / notes
Service network name, ID, and ARN (or the resource configuration ARN for a single-resource share)sn-… / arn:aws:vpc-lattice:<region>:<account>:servicenetwork/sn-…
Confirmation the AWS RAM share is createdTargets Atlan's account ID, external sharing enabled, same region as your tenant
Per database: resource identifierARN, DNS name, or IP
Per database: engine and portPostgreSQL 5432, MySQL 3306
Availability Zones used by your resource gatewayfor example usw2-az1, usw2-az2
IAM role ARN and external IDIf using a cross-account IAM role or RDS IAM auth
Which Atlan tenantProduction or non-production, each needs its own endpoint

In return, Atlan provides its AWS account ID and your tenant's region for the share. After accepting the share and confirming the service-network endpoint is Available with DNS propagated, connectors use the databases' real hostnames on native ports, no endpoint hostnames to look up.

Set up VPC Lattice connectivity​

Step 1: Create resource gateway​

In the AWS VPC console, go to PrivateLink and Lattice → Resource gateways and create a gateway in the VPC that contains your database:

  1. Select the VPC where the database lives.
  2. Select subnets in at least two Availability Zones for resilience.
  3. Attach a security group to the gateway. This security group governs what the gateway can send to your database.
  4. Make sure the subnets you select have free IP addresses available, the gateway consumes IPs from them.

You need one resource gateway per VPC, regardless of how many databases that VPC contains.

Step 2: Create resource configuration for each database​

  1. Choose the resource type: ARN (for a non-public RDS/Aurora database, recommended), DNS (any TCP service reachable by domain name), or IP (any TCP service reachable by IPv4/IPv6 address within the VPC).
  2. Select the resource gateway you created in Step 1.
  3. Specify the protocol (TCP) and the ports Atlan needs to reach, for example, 5432 for PostgreSQL or 3306 for MySQL.

Step 3: Allow resource gateway to reach your database​

Add an inbound rule to your database's security group that permits traffic from the resource gateway (reference the gateway's security group, or its subnet ranges) on the database port.

Because the resource gateway performs source NAT, your database only ever needs to permit the gateway, and you don't need to open your database's security group to Atlan's IP ranges.

note

No egress changes are needed on the database's security group. The default permit-all outbound rule is sufficient for return traffic; if you run restricted egress, make sure return traffic to the resource gateway is permitted.

Step 4: Associate with service network and share with Atlan​

For a single database, you can RAM-share the individual resource configuration directly. For anything more than a couple of databases, use a service network:

  1. Create a VPC Lattice service network (commonly in a central networking account). Consider separate service networks per environment, for example, one for staging and one for production.
  2. Associate your resource configurations with the service network.
  3. In AWS RAM, create a resource share: resource type Service network (or Resource configuration for the single-resource pattern); principal: Atlan's AWS account ID; enable Allow sharing with external accounts.

The RAM share grants Atlan access only to the shared service network or resource configuration, not to your wider AWS account or VPC.

caution

After creating the share, verify in AWS RAM that the share shows as active and Atlan's account appears as a principal. A share that fails to save (or is created against the wrong account ID) is one of the most common causes of a stalled setup, Atlan can't proceed until the shared resource is visible on its side.

Step 5: Send details to Atlan​

Raise a support ticket with everything listed in Information to share with Atlan, the service network name/ID/ARN, confirmation the RAM share is created, the per-database details, the resource gateway's Availability Zones, and the IAM role ARN + external ID if using IAM auth.

What Atlan does next​

  1. Verifies the shared service network is visible and accepts the RAM share.
  2. Creates a service-network VPC endpoint in your tenant's VPC, secured by Atlan-managed security groups.
  3. Waits for the endpoint to reach the Available state and for private DNS to propagate.
  4. Validates TCP reachability to each database hostname and port from the Atlan cluster.
  5. Confirms authentication (IAM role assumption with external ID, or credential-based) before handing the connection over for crawling.

Atlan support confirms with you when the endpoint is live and asks you to validate one connection end-to-end from the Atlan UI.

Adding databases later​

This is where VPC Lattice pays off. To connect a new database:

  1. Create (or reuse) the resource gateway in the database's VPC.
  2. Create a resource configuration for the database and associate it with the already-shared service network.
  3. Configure the connection in Atlan with the database's hostname and port.

No new RAM share, no Atlan-side infrastructure change, and no support ticket for network setup is required. Many customers automate steps 1-2 in Terraform so every new database is reachable from Atlan at creation time.

Limitations and considerations​

  • TCP only, Layer 4 only. Resource gateways carry TCP traffic. UDP-based protocols aren't supported, and there is no Layer 7 routing (no path- or header-based rules).
  • Same region as your tenant. The service network and Atlan's endpoint must be in your Atlan tenant's region. To reach a database in another region, either extend your Lattice deployment into the tenant's region or use cross-region PrivateLink instead.
  • ARN-type configurations are RDS/Aurora only. Services such as Redshift, DynamoDB, ElastiCache, and DocumentDB have no ARN-type resource configuration. You can still connect them through VPC Lattice using DNS- or IP-type resource configurations.
  • No overlapping CIDRs within your service network. While Atlan-vs-customer CIDR overlap is fine, VPC Lattice can't correctly route to resources when multiple VPCs associated with the same service network share the same IP address space. Plan for non-overlapping CIDRs across the VPCs whose resources join one service network, or split them across service networks.
  • Quotas. A service network supports 500 resource configurations by default, adjustable to 1,000 via AWS quota increase.
  • Don't dual-publish a database. If the same database is advertised over both VPC Lattice and a dedicated PrivateLink endpoint, the Lattice path takes precedence for DNS resolution in the Atlan VPC. Pick one path per database.
  • IP space on both sides. Resource gateways and service-network endpoints consume IP addresses from their subnets. Make sure the subnets involved have contiguous free address space; endpoint creation fails when a subnet is nearly exhausted.
  • AWS only. VPC Lattice has no equivalent on GCP or Azure. For sources in other clouds, see Atlan's other private connectivity options.

Troubleshooting​

Connection test times out. Timeouts almost always mean a network-path issue, in order of likelihood:

  1. The resource configuration isn't associated with the shared service network.
  2. The database's security group doesn't permit inbound traffic from the resource gateway on the database port.
  3. A network ACL or firewall between the gateway and the database is blocking the port.
  4. The Atlan-side endpoint association isn't yet complete, check with Atlan support.

A useful isolation step: launch a test instance in the VPC where the resource gateway lives and confirm it can reach the database on the port. If that fails, the problem is on the database side, not the Lattice path.

Connection reaches the database but authentication fails. Errors such as Access denied for user or connection-pool failures (Cannot create PoolableConnectionFactory) mean the network path is healthy and the problem is at the authentication layer: verify the database user's grants, and, for IAM-based auth, that the IAM role ARN and external ID match on both sides.

Atlan reports the share isn't visible. Re-check the RAM share: confirm it saved, targets the correct Atlan account ID, has external sharing enabled, and is in the same region as your tenant. Also make sure you don't have duplicate or stale service networks shared under the same owner account, delete or unshare superseded ones.

DNS resolves but to the wrong path. If a hostname resolves through Lattice when you expected PrivateLink (or vice versa), check whether the database is advertised on both; remove one.

See also​