# Connect to Amazon Redshift

> Add a one-sentence summary.

Connect · 17 min read · Updated 2026-11-05

> **Tip:** **How this works — and why there's an AWS step.** Golden Analytics connects to Amazon Redshift through the **Amazon Redshift Data API**, AWS's HTTPS interface for running SQL, rather than through a database driver. Two things follow from that:
>
> - **No network setup.** Golden never opens a connection to your cluster, so nothing changes in your VPC, security groups, or public-access settings — a private cluster works as-is.
> - **An AWS identity step.** The Data API is an AWS service, so every request must be signed with AWS credentials. It does not accept a database user name and password the way a JDBC or ODBC driver does. Golden therefore needs an IAM user with an access key and a policy allowing the Data API calls; which *database user* your queries run as is a separate, second choice you make below.

### Before you start

You'll need three things:

- **A Redshift data warehouse the Data API supports.** Any Amazon Redshift Serverless workgroup, or a provisioned cluster on RA3, DC2, or RG node types. Older DS2 and DC1 clusters don't support the Data API.
- **Someone who can create an IAM policy and IAM user** in the AWS account that owns the cluster or workgroup. Golden's IAM user must live in that same account.
- **Someone who can grant privileges in the Redshift database** — a superuser or the owner of the schemas you want to analyze.

Set aside about 15 minutes. Steps 1–4 happen in the AWS console, Step 5 in Golden, and Step 6 back in Redshift.

### Two layers of access

If you've connected other tools to Redshift with a hostname, user name, and password, expect that single login to split in two here:

| Layer | What it decides | Where you set it up |
| --- | --- | --- |
| **AWS** (always required) | May this caller use the Data API at all, and which database identity may it take on? | IAM — a user, an access key, and a policy (Steps 2 and 3) |
| **Database** | Which database user do the queries run as, and which schemas and tables can it read? | Redshift — a database user (created by you, or automatically) and its GRANTs (Steps 4 and 6) |

The AWS layer is the same for everyone. The database layer has three variants, and the **Database sign-in** setting in Golden is where you pick one.

### Choose how Golden signs in to the database

The **Database sign-in** setting decides which *database user* your queries run as — and therefore which tables Golden can see. Pick one now; it changes what you do in Steps 2, 4, and 6.

| Method | How it works | Choose it when | Works with |
| --- | --- | --- | --- |
| **IAM identity** (default) | Redshift automatically creates a database user named `IAM:golden-analytics` (matching the IAM user) and Golden signs in as that user. No database password exists anywhere. | You're setting up fresh and want the fewest secrets to manage. | Provisioned clusters and Serverless workgroups |
| **Database user** | Golden signs in as a database user you name (for example `golden_reader`). AWS issues short-lived credentials for that user on every request, so no password is stored in Golden. | You already have a read-only database user with the grants you want. | Provisioned clusters only — the option disappears when you enter a Serverless endpoint |
| **Secrets Manager secret** | Golden signs in with a username and password that you store in AWS Secrets Manager. Golden only ever holds the secret's ARN. | Your database user needs to keep a password, or your team standardizes on Secrets Manager. | Provisioned clusters and Serverless workgroups |

### Step 1 — Find your endpoint

Open the [Amazon Redshift console](https://console.aws.amazon.com/redshiftv2/).

**Provisioned cluster:** choose **Clusters** in the left navigation, click your cluster, and copy the **Endpoint** from the **General information** panel. It looks like this:

```
my-cluster.abc123xyz789.us-east-1.redshift.amazonaws.com:5439/dev
```

**Serverless workgroup:** choose **Redshift Serverless**, then **Workgroup configuration**, click your workgroup, and copy the **Endpoint** from **General information**. It looks like this:

```
default.123456789012.us-east-1.redshift-serverless.amazonaws.com:5439/dev
```

You'll paste the whole thing into Golden later — the trailing `:5439/dev` is fine, Golden trims it.

While you're here, note four values you'll need for the policy in Step 2:

- **Region** — the label just before `redshift` or `redshift-serverless` in the hostname (`us-east-1` above).
- **Cluster identifier or workgroup name** — the first label of the hostname (`my-cluster` or `default` above).
- **Database name** — the part after the slash (`dev` is Redshift's default).
- **AWS account ID** — the 12-digit number in the account menu at the top right of the console.

### Step 2 — Create the permissions policy

Rather than attaching AWS's managed `AmazonRedshiftDataFullAccess` policy, create a small custom one. It is narrower, and for two of the three sign-in methods it is the only one that works (see the note at the end of this step).

1. Open the [IAM console](https://console.aws.amazon.com/iam/), choose **Policies**, then **Create policy**.
2. Switch to the **JSON** tab, delete the placeholder, and paste the policy below.
3. Keep the first two statements as-is. Of the four **sign-in** statements that follow, keep **only the one for your method** and delete the other three.
4. Replace the UPPERCASE placeholders using the table under the policy.
5. Click **Next**, name the policy `GoldenAnalyticsRedshiftAccess`, and click **Create policy**.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GoldenRedshiftDataApi",
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:BatchExecuteStatement",
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:CancelStatement",
        "redshift-data:ListSchemas",
        "redshift-data:ListTables"
      ],
      "Resource": "*"
    },
    {
      "Sid": "GoldenServiceLinkedRole",
      "Effect": "Allow",
      "Action": "iam:CreateServiceLinkedRole",
      "Resource": "arn:aws:iam::ACCOUNT_ID:role/aws-service-role/redshift-data.amazonaws.com/AWSServiceRoleForRedshift",
      "Condition": {
        "StringLike": { "iam:AWSServiceName": "redshift-data.amazonaws.com" }
      }
    },

    {
      "Sid": "SignInIamIdentityProvisionedCluster",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentialsWithIAM",
      "Resource": "arn:aws:redshift:REGION:ACCOUNT_ID:dbname:CLUSTER_ID/*"
    },
    {
      "Sid": "SignInIamIdentityServerlessWorkgroup",
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "arn:aws:redshift-serverless:REGION:ACCOUNT_ID:workgroup/*"
    },
    {
      "Sid": "SignInDatabaseUserProvisionedCluster",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentials",
      "Resource": [
        "arn:aws:redshift:REGION:ACCOUNT_ID:dbuser:CLUSTER_ID/DB_USER",
        "arn:aws:redshift:REGION:ACCOUNT_ID:dbname:CLUSTER_ID/*"
      ]
    },
    {
      "Sid": "SignInSecretsManager",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:golden-analytics/redshift-*"
    }
  ]
}
```

| Placeholder | Replace with | Example |
| --- | --- | --- |
| `REGION` | The region from Step 1 | `us-east-1` |
| `ACCOUNT_ID` | Your 12-digit AWS account ID | `123456789012` |
| `CLUSTER_ID` | The cluster identifier — the first label of a provisioned endpoint | `my-cluster` |
| `DB_USER` | Database user method only: the database user Golden will sign in as (you create it in Step 4) | `golden_reader` |

The policy doesn't name a database. A connection in Golden targets exactly one database (its **Database** field), and this one policy covers every connection you make to the cluster or workgroup.

Three optional tightenings: for a provisioned cluster, replace the asterisk in `dbname:CLUSTER_ID/*` with a single database name to limit the key to that database; for Serverless, replace the asterisk in `workgroup/*` by pasting the workgroup's full ARN from its configuration page; for Secrets Manager, the resource already matches only a secret named `golden-analytics/redshift`, which is the name you'll give it in Step 4.

**Why not just attach AmazonRedshiftDataFullAccess?**

AWS's managed policy is built around its own defaults, and two of them bite here. For the **Database user** method it only allows a database user literally named `redshift_data_api_user`. For **IAM identity on Serverless** it only works if the workgroup itself carries a tag with the key `RedshiftDataFullAccess`. It also grants more than Golden needs (listing databases, describing tables, reading every tagged secret in the account). If you already use it for other tooling it will work for the IAM identity method on a provisioned cluster, and for Secrets Manager as long as the secret is tagged `RedshiftDataFullAccess` — but the custom policy above avoids all of these caveats.

### Step 3 — Create an IAM user for Golden and an access key

1. In the IAM console choose **Users**, then **Create user**.
2. For **User name** enter `golden-analytics`. Leave **Provide user access to the AWS Management Console** unchecked and click **Next**.
3. Under **Permissions options** choose **Attach policies directly**, search for `GoldenAnalyticsRedshiftAccess`, tick it, click **Next**, then **Create user**.
4. Open the new user, go to the **Security credentials** tab, scroll to **Access keys**, and click **Create access key**.
5. For the use case choose **Third-party service**. AWS will suggest alternatives; tick the confirmation box, click **Next**, then **Create access key**.
6. Copy both the **Access key** and the **Secret access key**, or click **Download .csv file**. **The secret is shown only once** — if you lose it, delete the key and create a new one.

> **Warning:** Use this dedicated user rather than your own credentials or the account root user. Anyone who can use the connection in Golden is effectively using this key, so its permissions should be exactly the policy above and nothing more. AWS allows two active keys per user, which is what makes rotation possible later (see Good to know).
>
> If you chose **IAM identity**, the user name matters: Redshift will name the database user `IAM:` followed by this exact IAM user name. If you pick something other than `golden-analytics`, substitute it in Step 6.

### Step 4 — Prepare the database sign-in

Do only the part for the method you chose.

### IAM identity

Nothing to do yet. Redshift creates the database user `IAM:golden-analytics` automatically the first time Golden connects (Step 5). You'll grant it read access in Step 6.

### Database user (provisioned clusters only)

Sign in to the database — with query editor v2 in the Redshift console, or any SQL client — as a superuser or schema owner. Either reuse an existing read-only user, or create one. `PASSWORD DISABLE` means the user can only be reached through AWS temporary credentials, never with a password:

```sql
CREATE USER golden_reader PASSWORD DISABLE;
GRANT USAGE ON SCHEMA public TO golden_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO golden_reader;
```

Repeat the two GRANT lines for every schema you want to analyze in Golden, connected to the database that holds each schema. The user itself is cluster-wide, so create it only once. Its name must match the `DB_USER` you put in the policy in Step 2.

### Secrets Manager secret

First create a database user with a password and grant it read access (in query editor v2 or any SQL client, as a superuser or schema owner):

```sql
CREATE USER golden_reader PASSWORD 'Choose-a-strong-password-1';
GRANT USAGE ON SCHEMA public TO golden_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO golden_reader;
```

Repeat the two GRANT lines for every schema you want to analyze, connected to the database that holds each schema (the user itself is cluster-wide). Then store those credentials in Secrets Manager:

1. Open the [AWS Secrets Manager console](https://console.aws.amazon.com/secretsmanager/) and click **Store a new secret**.
2. **Provisioned cluster:** choose **Credentials for Amazon Redshift data warehouse**, enter the **User name** and **Password**, and select your cluster. **Serverless workgroup:** choose **Other type of secret** and add two key/value rows — key `username` with the user name, and key `password` with the password.
3. Click **Next**. For **Secret name** enter `golden-analytics/redshift` (this is the name the policy in Step 2 matches). Under **Tags**, add a tag with the key `RedshiftDataFullAccess` and any value.
4. Click **Next** past the rotation page (leave automatic rotation off), then **Store**.
5. Open the secret and copy its **Secret ARN** — you'll paste it into Golden in Step 5.

> **Note:** The `RedshiftDataFullAccess` tag is what AWS's own Redshift tooling looks for on a Data API secret. Golden's custom policy doesn't need it, but adding it keeps the secret usable from the AWS query editor and CLI too. If you encrypt the secret with a customer-managed KMS key rather than the default AWS-managed key, Golden's IAM user also needs `kms:Decrypt` on that key.

### Step 5 — Create the connection in Golden

1. On the Golden home page click **Create Connection** (inside a Space, use **Create**, then **Saved connection**). In the **Add a Connection** panel choose **Amazon Redshift**.
2. Fill in the form:

| Field | What to enter |
| --- | --- |
| **Connection Name** | Anything your team will recognize, such as "Sales warehouse". |
| **Endpoint** | The endpoint from Step 1. Pasting it with the `:5439/dev` tail is fine. |
| **Database** | The database name — `dev` unless you created another. |
| **AWS Access Key ID** | The access key from Step 3 (it starts with `AKIA`). |
| **AWS Secret Access Key** | The secret access key from Step 3. |
| **Database sign-in** | The method you chose. **IAM identity** needs nothing more. **Database user** reveals a **Database User** field — enter the name from Step 4 (for example `golden_reader`, with no prefix). **Secrets Manager secret** reveals a **Secrets Manager secret** field — paste the Secret ARN from Step 4. |
| **More options** → **AWS Region** | Leave blank; Golden reads it from the endpoint. Set it only if you connect through a custom domain name. |
| **More options** → **Schema** | The schema Golden should treat as the default — `public` unless your tables live elsewhere. |
| **More options** → **AWS Session Token** | Leave blank. This is only for temporary credentials from AWS SSO or STS (access keys starting with `ASIA`), which expire within hours and aren't suitable for a saved connection. |
| **Save to Space** | Where the connection lives. Saving it to a shared Space lets other members query through it — see the note below. |

**Then click Test Connection.** Golden runs a one-line query (`SELECT 1`) through the Data API. When the button reads **Connected**, your AWS setup is correct.

**Finally, click Save Connection.**

> **Note:** A connection saved to a shared Space runs every member's queries as this same IAM user and database user. That is by design — it's why Step 3 creates a dedicated, read-only identity — but keep it in mind when you decide which schemas to grant.

### Step 6 — Grant read access (IAM identity method)

Skip this step if you chose **Database user** or **Secrets Manager secret** — you granted access in Step 4.

With **IAM identity**, the Test Connection in Step 5 made Redshift create the database user `IAM:golden-analytics`. It starts with no privileges beyond Redshift's PUBLIC defaults, so until you grant access Golden can connect but will see "permission denied" as soon as it reads a table.

As a superuser or schema owner, run the following. The double quotes are required because of the colon in the user name:

```sql
GRANT USAGE ON SCHEMA public TO "IAM:golden-analytics";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "IAM:golden-analytics";
```

Repeat for each schema you want available in Golden, connected to the database that holds it. The user is cluster-wide, so other databases need only the grants, not a new user. To have tables you create later picked up automatically, also run:

```sql
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO "IAM:golden-analytics";
```

Then, back in Golden, open the connection and browse its tables to confirm they load.

> **Note:** If you named the IAM user something other than `golden-analytics`, the database user is `IAM:` followed by your name. If Golden connects with temporary credentials from an assumed role (the **AWS Session Token** field), Redshift names the user `IAMR:` followed by the role name instead.

### Troubleshooting

When AWS rejects a request, Golden shows the AWS error code and message, so the left column is what you'll actually see.

| What you see | Cause | Fix |
| --- | --- | --- |
| `AccessDeniedException` … is not authorized to perform: `redshift-data:` … | The policy from Step 2 isn't attached to the user, or its first statement was edited. | Check the user's **Permissions** tab in IAM and re-attach `GoldenAnalyticsRedshiftAccess`. |
| `AccessDeniedException` … `redshift:GetClusterCredentialsWithIAM`, `redshift-serverless:GetCredentials`, `redshift:GetClusterCredentials`, or `secretsmanager:GetSecretValue` | The sign-in statement for your method is missing, or one of its placeholders (region, account, cluster, user, secret name) doesn't match. | Compare the statement's Resource against the values from Step 1. For Database user, `DB_USER` must equal the **Database User** field exactly. |
| `AccessDeniedException` mentioning KMS or `kms:CreateGrant`, on a cluster or workgroup encrypted with a customer-managed key | The Data API encrypts query text and results with your key and needs a KMS grant, which Redshift creates automatically on the first query — but the key's policy doesn't allow it. Clusters on the default AWS-owned key never hit this. | In the key policy, allow `kms:CreateGrant` and `kms:DescribeKey` for callers in your account via `redshift.amazonaws.com` — see [Using AWS KMS with the Data API](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-kms.html). |
| `UnrecognizedClientException`, or "The security token included in the request is invalid" | The access key or secret was pasted incorrectly (a trailing space is enough), or the key has been deactivated or deleted in IAM. | Re-paste both values from the .csv, or create a fresh key as in Step 3. |
| "Temporary AWS credentials (an ASIA… access key) require an AWS Session Token…" | You pasted a temporary key from AWS SSO or STS. | Use the permanent key created for the `golden-analytics` user in Step 3. |
| "Could not determine the AWS region from the Redshift endpoint…" or "Host must end with one of: `.redshift.amazonaws.com`, `.redshift-serverless.amazonaws.com`." | The endpoint isn't the standard AWS hostname — usually a custom domain name or a typo. | Paste the **Endpoint** value from the console (Step 1). For a custom domain, also set **AWS Region** under More options. |
| `ResourceNotFoundException`, "Cluster … not found", or "Workgroup … not found" | The endpoint is in a different region than the one Golden is calling, or the cluster or workgroup name is misspelled. | Re-check the endpoint and clear any **AWS Region** override. |
| "Redshift query failed: … user … does not exist" | Database user method: the **Database User** you entered hasn't been created in Redshift. | Create it as in Step 4, or correct the name in the connection. |
| "Redshift query failed: permission denied for schema …" or "… permission denied for relation …" | The database user can connect but has no grants on that schema or table. | Run the GRANT statements from Step 4 or Step 6 for that schema. |
| "Redshift query failed: … password authentication failed for user …" | The Secrets Manager secret holds the wrong username or password, or the password was changed in Redshift. | Update the secret's value in Secrets Manager — its ARN stays the same, so Golden needs no change. |
| "Redshift query cancelled or exceeded the request deadline" | A query ran longer than Golden's interactive limit (about two minutes). | Filter or aggregate earlier, add sort keys, or give the cluster or workgroup more capacity. |
| "Some table metadata didn't load — search may be incomplete." | A schema holds more than 50,000 tables, so Golden stopped listing. | Point the connection's **Schema** at a smaller schema, or search tables by exact name. |
| `ThrottlingException` | Too many Data API requests in the same second for your account's quota. | Retry. If it recurs under normal use, request a higher Data API quota from AWS. |

### Good to know

- **Queries run live.** Golden doesn't copy your data. Every chart, filter, and AI question compiles to SQL that runs on your cluster or workgroup at that moment, so Redshift compute (or Serverless RPU-hours) is used as people work.
- **Limits.** Golden waits about two minutes for an interactive query, and the Data API returns at most 500 MB per result. Golden aggregates in the warehouse, so real dashboards stay far below both.
- **What AWS logs.** Every request Golden makes appears in CloudTrail as a `redshift-data` call by the `golden-analytics` user, and every query appears in Redshift's system tables under the database user from your sign-in method.
- **Rotating the key.** Create a second access key for `golden-analytics` in IAM, edit the connection in Golden and paste the new pair, click **Test Connection**, then deactivate and delete the old key. Two active keys per user is what makes this a no-downtime swap.
- **Revoking access.** Deactivate the access key (or delete the user) in IAM and Golden loses access on its next query. Removing the database grants works too, but the key is faster.
- **Same account only.** Golden signs requests with the user's own key and doesn't assume roles, so the IAM user must live in the AWS account that owns the cluster or workgroup.
- **Private clusters are fine.** The Data API is an AWS endpoint, so your cluster's "Publicly accessible" setting and its security groups don't affect Golden.
- **Customer-managed KMS keys.** If the cluster or workgroup is encrypted with your own KMS key, the Data API uses that same key for query text and results and creates a KMS grant on the first query. The key policy must allow `kms:CreateGrant` via `redshift.amazonaws.com`; the default AWS-owned key needs nothing.

### AWS documentation referenced

- [Using the Amazon Redshift Data API](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api.html)
- [Configuring IAM permissions for the Data API](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-iam.html)
- [Storing database credentials in AWS Secrets Manager](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-secrets.html)
- [Connecting to Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-connecting.html)
- [Creating temporary IAM credentials](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-iam-credentials-steps.html)
- [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)
- [AmazonRedshiftDataFullAccess managed policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRedshiftDataFullAccess.html)
- [Using AWS KMS with the Amazon Redshift Data API](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-kms.html)

Source: https://goldenanalytics.com/docs/imported-mupzjnb7