Skip to main content

Special cases: Serverless & more

Connect docs via MCP
TL;DR

Amazon Redshift Serverless, DC2 clusters, multiple clusters, cross-region and cross-cloud tenants, external (Glue/Spectrum) schemas, and sources reachable only from inside your network.

Redshift Serverless, DC2 clusters, multiple clusters, cross-region and cross-cloud tenants, external (Glue/Spectrum) schemas, and sources reachable only from inside your network.

Redshift serverless​

Serverless has no "cluster" - a workgroup provides compute and networking, and a namespace holds the data. What changes for connectivity:

AspectProvisionedServerless
Deployment Type fieldProvisionedServerless - changes which credential fields appear
Database permissionsUser + group (atlan_user / atlan_users)Role-based: atlan_role
IAM role authUsername + role ARNRole ARN only (no username); the IAM role must carry the tag RedshiftDbRoles: atlan_role
Private accessManaged VPC endpoint via the guide, or optional Cluster ID field with IAM authFill the optional Workgroup field; the private-link guide covers provisioned RA3 clusters only - for a private Serverless workgroup, raise a support ticket to confirm the path
Query-history miningFull support (with the stl_* grants and SYSLOG ACCESS UNRESTRICTED)Supported via SYS_QUERY_HISTORY, SYS_QUERY_TEXT, and SYS_CONNECTION_LOG; the provisioned SYSLOG/stl_* grants don't apply

DC2 clusters​

  • No private network link. Managed VPC endpoints require RA3 with cluster relocation - DC2 clusters must use IP allowlisting (publicly accessible) or a self-deployed agent.
  • One workflow per database. DC2 doesn't support cross-database joins, so set up a separate crawler workflow for each database you want cataloged.

Multiple clusters, one Atlan tenant​

Each cluster needs its own grant and its own Redshift-managed VPC endpoint - an existing private link to one cluster doesn't carry a second, even in the same AWS account and VPC. To add a cluster to an existing setup:

  • Grant Atlan's account/VPC access on the new cluster (Phase 2 of the guide).
  • Reply on a support ticket with the new cluster identifier; Atlan builds another endpoint and returns another private hostname.
  • Each Atlan connection uses its own hostname. Label multiple clusters clearly in one ticket to avoid mix-ups.

Cross-region and cross-cloud tenants​

Your cluster doesn't need to be in the same AWS region as your Atlan tenant - and the tenant doesn't even need to be on AWS. Atlan deploys region-specific endpoint networks and privately peers (or tunnels, for Azure/GCP tenants) back to your tenant, and configures the cross-region routing on your behalf. See Cross-region private network connectivity. The setup steps are identical - just state both regions/clouds in your support ticket so Atlan builds the endpoint in the right place.

External schemas (AWS Glue / Redshift Spectrum)​

  • Grant USAGE on external schemas backed by S3/Glue; for external schemas backed by another Redshift database, also grant SELECT ON ALL TABLES.
  • Can't grant on the external schema directly? Create a cloned schema containing metadata views and point Atlan at that instead (see Set up Amazon Redshift).

Reachable only from inside your network​

If Redshift can't be made publicly accessible and the private-link prerequisites can't be met, run extraction inside your network with the self-deployed runtime (agent): the agent connects to Redshift locally and pushes metadata out to Atlan, so no inbound path to your cluster is ever opened. (The older Docker/Kubernetes offline-extraction modes are sunset - use the self-deployed runtime.)

See also​