Connecting Amazon Redshift

Last updated August 14, 2026 · By the SaturnSQL team

Redshift needs one more decision than most databases, because a cluster is created inside a VPC and is not reachable from the internet until you say so. There are three ways to bridge that gap, and two of them let the cluster stay private:

1. SSH bastion — the cluster stays in its private subnet and SaturnSQL reaches it through a small jump host. Best if you already run a bastion or can launch one EC2 instance.
2. Data API (IAM) — no network setup at all; queries travel over HTTPS with AWS credentials. The fastest secure option if you can create an IAM key pair.
3. Public endpoint — the quickest to set up, but it puts your cluster on the internet. Use it only if the first two are not an option.

Option 1: Connect through an SSH bastion

A bastion is a small EC2 instance in a public subnet of the same VPC. SaturnSQL opens an SSH connection to it and tunnels the Redshift traffic through, so the cluster itself never needs a public endpoint. Two security group rules make it work: allow our static IP address (100.49.19.161/32) into the bastion on port 22, and allow the bastion's security group into the cluster's on port 5439.

In the connection form tick Use SSH tunnel, point it at the bastion, and use the cluster's endpoint as the database host as usual. The SSH tunnel guide walks through the whole setup, including creating the key pair.

Option 2: Connect with the Data API (no network setup)

The Data API skips the network question entirely: choose Data API (IAM) as the connection mode instead of Host and port. It talks to Redshift over HTTPS using an AWS access key pair, so there is no security group to open, no public endpoint to create, and no bastion to run. It works for clusters in private subnets and is available on Starter plans and above.

Fill in the Region your cluster or workgroup lives in, the Database name, an Access key ID and Secret access key, and exactly one of:

• Serverless: the workgroup name.
• Provisioned: the cluster identifier and a database user.

The IAM user or role behind those keys needs its own permissions, separate from the database user. Both modes need:

• redshift-data:ExecuteStatement
• redshift-data:DescribeStatement
• redshift-data:GetStatementResult
• redshift-data:CancelStatement

Serverless additionally needs redshift-serverless:GetCredentials scoped to the workgroup. Here is a complete policy for that case:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:CancelStatement"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "arn:aws:redshift-serverless:<region>:<account-id>:workgroup/<workgroup-name>"
    }
  ]
}

A provisioned cluster needs redshift:GetClusterCredentials instead, scoped to both the database user and the database name: dbuser:<cluster>/<dbUser> and dbname:<cluster>/<database>.

Option 3: Make the cluster publicly accessible

First the security group. In the AWS console open your cluster, then Properties → Network and security, and click the VPC security group. Under Inbound rules add: type Redshift, port 5439, source 100.49.19.161/32. Every SaturnSQL connection leaves from that single static IP address, so this is the only address you need to allow — never open the port wider than that.

Then the public route, because a security group rule cannot help if the cluster has none. Check Properties → Network and security → Publicly accessible. If it says No, edit it and set it to Yes; the cluster also needs to sit in a subnet whose route table has an internet gateway.

The name is misleading: "publicly accessible" means the cluster has a public endpoint, not that anyone can log in. Your security group still decides who may reach it, which is why the inbound rule comes first and why it should stay as narrow as one address.

Use the cluster's own endpoint

Copy the host from Properties → Endpoint. It ends in redshift.amazonaws.com, or redshift-serverless.amazonaws.com for a Serverless workgroup. Paste only the host: SaturnSQL asks for the port and database name in their own fields, so leave off the :5439/dev tail if you copied the full JDBC string.

Do not point at a load balancer in front of the cluster. It is a common way to expose Redshift, and it breaks two things at once. Health checks that never pass make the connection hang exactly like a firewall drop, and the TLS certificate is issued for the Redshift hostname rather than the load balancer's, so once traffic does flow you get a certificate error instead. If you have no choice, tick Allow expired or mismatched certificates under Advanced to get past the certificate half.

Settings that trip people up

• Port: 5439, not 5432. Redshift speaks the PostgreSQL protocol but does not use its port.
• Database: usually dev on a provisioned cluster.
• SSL: leave it on. Redshift accepts TLS, and its certificate verifies normally when you use the cluster endpoint.
• User: a read-only user with USAGE on the schema and SELECT on its tables is enough.

Reading the error you got

• Timed out: packets are being dropped, not refused. On a direct connection that is the security group rule or public accessibility; on a tunnel it is usually the bastion's port 22 rule.
• Connection refused: something answered and said no. Usually the wrong port.
• Host not found: the endpoint is mistyped, or the cluster was renamed or deleted.
• Certificate does not cover this host name: you are connecting through something other than the cluster endpoint. See the endpoint section above.
• Authentication failed: the network side is solved. Only the username or password is wrong now.

Still stuck? Send us the exact error text from the connection form and we will tell you which side it is coming from.