Skip to main content

Choose how Atlan connects to Amazon Redshift

Connect docs via MCP
TL;DR

Compare the three ways Atlan can reach your Amazon Redshift cluster or Serverless workgroup - public IP allowlisting, the AWS private network link, and the self-deployed agent.

There are three ways for Atlan to reach your Redshift cluster or Serverless workgroup. This page helps you pick the right one in about two minutes - before you touch any AWS configuration.

Before you start: Two facts you need​

Every path below depends on knowing these. Gather them first - they determine which options are even available to you.

FactHow to find it
Your Redshift deployment type - Provisioned (RA3 or DC2 nodes) or Serverless - and whether it's publicly accessibleAsk your AWS administrator, or check the AWS console: Amazon Redshift → Clusters → (your cluster) → Properties. Node type and the "Publicly accessible" setting are both listed there. Serverless deployments appear under Serverless dashboard → Workgroups.
Which cloud and region your Atlan tenant runs on, and whether it's a Single Tenant SaaS deploymentAsk your Atlan admin or raise a support request - say "which cloud and region is my tenant hosted in, and is it Single Tenant SaaS?"

Compare three methods​

Public + IP allowlistingAWS private network linkSelf-deployed agent
Traffic pathPublic internet, TLS/SSL-encrypted, from Atlan's fixed source IPsNever leaves the AWS private network (a Redshift-managed VPC endpoint)Extraction runs inside your own network
Redshift requirementsCluster or workgroup must be publicly accessibleProvisioned RA3 node type, cluster relocation turned on, port 5439 reachable, spare VPC endpoint quotaAny (RA3, DC2, Serverless, private-only)
Who is involvedYou + your AWS adminYou + your AWS admin + Atlan supportYour infrastructure team
Typical setup timeUnder an hour (one support ticket for your Atlan IPs)2–5 business days (two support round-trips)Days to weeks
Atlan deploymentAnySingle Tenant SaaS (cross-region and cross-cloud supported - say so in your ticket)Any
Start hereFirewall & IP allowlistingPrivate network link guideSelf-deployed runtime docs
Authentication is a separate choice

Whichever network path you pick, you also choose how Atlan authenticates to Redshift: a database username and password (Basic), an AWS IAM user, or an AWS IAM role. That choice is covered in Set up access and authentication - and it matters, because IAM authentication adds a second traffic path (to the AWS API) that has its own failure modes.

Which method to pick​

  • Pick public + IP allowlisting if your cluster or workgroup is (or can be made) publicly accessible and your security policy permits TLS traffic from known IPs. It's the fastest path: one support ticket to get your tenant's IPs, one security-group rule on your side.
  • Pick the private network link if your Redshift is private-only (not publicly accessible) or your organization prohibits any public path. Check the RA3 + cluster-relocation prerequisites first - DC2 clusters can't use it.
  • Pick the self-deployed agent if Redshift is reachable only from inside your network and the private-link prerequisites can't be met (for example, DC2 nodes you can't upgrade), or if policy requires all extraction to run in your own environment.
The decision customers most often get wrong

"The cluster is in a VPC, so PrivateLink is needed"—not necessarily. If the cluster is publicly accessible (an AWS console setting), Atlan can connect over the internet once your security group permits Atlan's IPs on port 5439. The private network link is for clusters that aren't publicly accessible. Checking that one console setting first saves days.

See also​