Private connectivity on Google Cloud with Private Service Connect

||Connect docs via MCP

Atlan supports private network connectivity to Google Cloud data sources using Private Service Connect (PSC), Google Cloud's equivalent of AWS PrivateLink. Traffic between Atlan and your sources stays on Google's private network and never traverses the public internet.

note

PSC connectivity requires your Atlan tenant to be hosted on Google Cloud. If your tenant runs on AWS, PSC to a GCP source doesn't apply across the cloud boundary; the alternatives are a Single Tenant SaaS cross-cloud endpoint layer, a site-to-site VPN, or IP allowlisting—contact Atlan support to determine which applies. See the private connectivity overview for the decision guide.

PSC at Atlan comes in two distinct patterns, and which one you need depends on the kind of source:

Pattern	For	Who builds what
Google APIs PSC	Google-managed API services: BigQuery (the documented, standard path) and Google Cloud Storage	Atlan builds everything, an endpoint in the Atlan VPC targeting Google's API backplane. No customer-side networking at all
Published-service PSC	Databases and services in your VPC: databases on Compute Engine VMs, self-hosted tools, and similar	You publish a service attachment behind an internal TCP load balancer; Atlan creates a PSC endpoint against it

Pattern 1: BigQuery (and GCS) via Google APIs PSC

BigQuery isn't a resource in your VPC, it's a Google-managed API. The private path therefore runs from Atlan's VPC to Google's API front end, not into your project:

Your VPC-SC perimeter is the real boundary.

How it works:

1. You raise a support ticket asking for BigQuery private connectivity. There is nothing to build or approve on your side. Google-managed services autoaccept PSC endpoints.
2. Atlan creates the PSC endpoint in the tenant VPC and shares back a private DNS name of the form bigquery-<name>.p.googleapis.com.
3. You configure the BigQuery connection in Atlan with that hostname as the host (port 443) using the private network connectivity option. This DNS override is mandatory, without it, client libraries silently use the public googleapis.com path.
4. Since the network path is Google's own backplane, the real access boundary is VPC Service Controls: if your organization runs a VPC-SC perimeter, add an ingress rule admitting Atlan for the services the connector touches, at minimum bigquery, plus storage, sts, iamcredentials, iam, and cloudresourcemanager depending on your authentication method.
5. Authentication is unchanged: a service account key or Workload Identity Federation, exactly as with public connectivity.

The same pattern serves Google Cloud Storage on request. Note it's strictly per-service: a BigQuery PSC endpoint can't be reused to reach a database VM or any other target, each service gets its own endpoint.

Pattern 2: Databases in your VPC via published-service PSC

For sources that live inside your VPC, a database on a Compute Engine VM, a self-hosted tool, the model mirrors AWS PrivateLink: you publish the service, Atlan consumes it.

1. You place the source behind an internal TCP load balancer and create a service attachment targeting it. Set the connection preference to autoaccept Atlan's project, or accept the connection explicitly when it arrives.
2. You share the service attachment URI (projects/<project>/regions/<region>/serviceAttachments/<name>), the hostname Atlan needs to map, and the port with Atlan support.
3. Atlan creates the PSC endpoint with a static internal IP in the tenant VPC and a private Cloud DNS zone entry so connectors reach the source by a stable hostname.
4. Atlan validates DNS resolution and TCP reachability from the tenant, then authentication, before handing over for crawling.

The endpoint must be in the same region as the service attachment, which in practice means your source region must match your Atlan tenant region.

Support-led

This pattern is arranged case-by-case with Atlan support, unlike BigQuery, it's not a self-serve or per-connector documented flow. Engage support at the design stage, before building the load balancer.

Information to share with Atlan

What you provide depends on the pattern. Gathering it up front turns a multi-round exchange into a single handoff.

Pattern	What to share with Atlan
Google APIs PSC (BigQuery / GCS)	The request for private connectivity to the service (BigQuery or GCS) and which Atlan tenant. Nothing to build or approve on your side. Atlan shares back the private hostname of the form bigquery-<name>.p.googleapis.com to use as the connection host on port 443
Published-service PSC (databases in your VPC)	The service attachment URI (projects/<project>/regions/<region>/serviceAttachments/<name>), the hostname Atlan must map in DNS, the port, the region, and which Atlan tenant. Atlan creates the PSC endpoint and a private Cloud DNS entry, then shares back the stable hostname for connectors

For both patterns, note which Atlan tenant (production or non-production) the setup is for, each is a separate consumer with its own endpoints. For Google APIs PSC, also be ready to add an ingress rule for Atlan to your VPC Service Controls perimeter (see Pattern 1) if you run one.

What this doesn't cover

Setting expectations honestly, since these come up often:

• Cloud SQL and AlloyDB aren't currently documented Atlan PSC targets. Private connectivity for them typically runs through Atlan's Self-Deployed Runtime (an agent inside your network) rather than a tenant-side PSC endpoint. Discuss the options with Atlan support.
• Snowflake and Databricks on GCP publish their own PSC attachments as vendors. Atlan can consume these, but the flow involves the vendor's authorization process, treat it as a support-led engagement rather than a documented standard path.
• Some connectors can't yet take a custom private endpoint. BigQuery's connector supports the private hostname override; not every GCP-family connector does. Confirm connector support with Atlan before provisioning PSC for a new source type.
• On-premises sources behind your VPC: PSC alone can't reach a private data-center subnet, it delivers traffic to your load balancer, and your existing interconnect/VPN must carry it onward. The same applies to reaching services in other clouds through a GCP transit VPC: PSC covers the Atlan-to-your-VPC leg only, and your interconnect does the rest.

Limitations and considerations

• GCP-hosted tenants only, same region as the target for published services.
• Scoped per project and VPC, not per organization. A PSC setup for one GCP project doesn't cover sibling projects; each producer project/service needs its own attachment and endpoint.
• One endpoint per service. There is no GCP equivalent of AWS VPC Lattice's service network, connecting many published services means one attachment + endpoint each.
• One-way, TCP. Atlan initiates all connections; published-service PSC carries TCP only.
• Per-environment. Production and non-production Atlan tenants each need their own endpoints.

Troubleshooting

BigQuery connector works but traffic isn't private. The host field must be the …p.googleapis.com name Atlan shared. With the default public hostname, everything still works, over the public path. Verify the connection config, not the network.

BigQuery calls blocked after switching to PSC. Almost always VPC Service Controls: the perimeter's ingress rules don't yet admit Atlan for one of the services in play (commonly storage or sts rather than bigquery itself). Check the VPC-SC audit logs for the denied service.

Published-service endpoint stuck pending. The service attachment's connection preference doesn't automatically accept Atlan's project and no one accepted manually. Accept the connection, or add Atlan's project to the accept list.

Endpoint accepted but TCP times out. Work the producer side: the load balancer's backend health, and VPC firewall rules on the path from the ILB to the source. As with every private connectivity pattern, an explicit authentication error means the network is fine; a timeout means it isn't.

See also

• Private connectivity overview: Decision guide for choosing the right connectivity pattern for your cloud and source type.