Skip to main content

How private network links work

Connect docs via MCP
TL;DR

Learn how Redshift-managed VPC endpoints work, who builds which half, and the three traffic paths between Atlan and Amazon Redshift.

This page explains Redshift-managed VPC endpoints, who is responsible for each part of the setup, and the three traffic paths between Atlan and Redshift. No prior AWS knowledge is required.

Private driveway​

Normally, Atlan reaches Redshift over the public internet - encrypted, but travelling shared roads. A private network link is like a private driveway between two properties: traffic flows over AWS's internal network and never touches the internet.

For Redshift, AWS provides a purpose-built version of this called a Redshift-managed VPC endpoint. It has two halves, owned by different parties:

  • You grant access. In the Redshift console, you add Atlan's AWS account as a grantee account on your cluster - like registering a neighbor who's allowed to build a driveway to your property.
  • Atlan builds the endpoint. Atlan creates the Redshift-managed VPC endpoint inside its own network (its VPC), pointed at your cluster. AWS wires the two together privately.

Unlike some other sources (Snowflake, for example), there is no separate "approve the pending connection" step - the grant you perform up front is the approval. The step setups most often stall on instead is the prerequisites: the endpoint can only be built against an RA3 cluster with cluster relocation turned on.

Three traffic paths​

Diagram of the three traffic paths between Atlan and Amazon Redshift: SQL queries and metadata over the private endpoint, IAM authentication calls to the AWS API, and the generic miner reading query files from S3

The private endpoint secures path 1 only. Paths 2 and 3 exist depending on your choices and need their own consideration.

  1. SQL queries and metadata (Atlan → Redshift, port 5439). The path the private endpoint protects. This is what the how-to guide configures.
  2. IAM authentication calls (Atlan → the AWS API). If you use IAM user or IAM role authentication, Atlan first calls the AWS Redshift API (for example GetClusterCredentials) to obtain short-lived database credentials, then connects on port 5439. This API call is a separate network path with separate permissions - a missing IAM permission fails the workflow even when the network link itself is perfect. See Troubleshooting Amazon Redshift connectivity.
  3. Generic miner (Atlan → your S3 bucket). If you use the generic (S3-based) miner for lineage beyond Redshift's short query-history window, Atlan reads query files from an S3 bucket you populate. S3 access is validated by a preflight check and uses S3 endpoints, not your cluster.

Glossary​

For definitions of every term used in these guides - VPC, Redshift-managed VPC endpoint, grantee account, cluster relocation, RA3/DC2, security group, NAT IP, CIDR range, and more - see the Network connectivity glossary.

See also​