## Choose how Atlan connects to Amazon Redshift

URL: https://docs.atlan.com/apps/connectors/data-warehouses/amazon-redshift/how-tos/choose-how-atlan-connects-to-amazon-redshift

> 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.

| Fact | How to find it |
|---|---|
| **Your Redshift deployment type** - Provisioned (RA3 or DC2 nodes) or Serverless - and whether it's *publicly accessible* | Ask 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 deployment | Ask your Atlan admin or [raise a support request](https://docs.atlan.com/support/submit-request) - say "which cloud and region is my tenant hosted in, and is it Single Tenant SaaS?" |

## Compare three methods

| | Public + IP allowlisting | AWS private network link | Self-deployed agent |
|---|---|---|---|
| **Traffic path** | Public internet, TLS/SSL-encrypted, from Atlan's fixed source IPs | Never leaves the AWS private network (a Redshift-managed VPC endpoint) | Extraction runs inside your own network |
| **Redshift requirements** | Cluster or workgroup must be *publicly accessible* | Provisioned **RA3** node type, **cluster relocation turned on**, port `5439` reachable, spare VPC endpoint quota | Any (RA3, DC2, Serverless, private-only) |
| **Who is involved** | You + your AWS admin | You + your AWS admin + Atlan support | Your infrastructure team |
| **Typical setup time** | Under an hour (one support ticket for your Atlan IPs) | 2–5 business days (two support round-trips) | Days to weeks |
| **Atlan deployment** | Any | Single Tenant SaaS (cross-region and cross-cloud supported - say so in your ticket) | Any |
| **Start here** | [Firewall & IP allowlisting](https://docs.atlan.com/llms/connectors/amazon-redshift/firewall-and-ip-allowlisting/llms.txt) | [Private network link guide](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-a-private-network-link-to-amazon-redshift/llms.txt) | [Self-deployed runtime docs](https://docs.atlan.com/llms/platform/self-deployed-runtime/llms.txt) |

:::info 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](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-access-and-authentication/llms.txt) - 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.

:::caution 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

- [How the private network link works](https://docs.atlan.com/llms/connectors/amazon-redshift/how-the-private-network-link-works/llms.txt): The 5-minute explainer - no AWS networking knowledge assumed. Read this if "VPC endpoint" or "grantee account" are new terms.
- [Atlan Network Details](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt): What identity Atlan presents to your AWS account and how to get your tenant's values.
- [Set up access and authentication](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-access-and-authentication/llms.txt): Database user, permissions, and the three authentication methods, in phases with clear ownership.
- [Set up the AWS private network link to Amazon Redshift](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-a-private-network-link-to-amazon-redshift/llms.txt): Six phases, each labeled with who performs it and how long it takes.

---