/ Docs

Amazon Redshift

Last updated December 22, 2025 · View as Markdown

Amazon_RedShift_Logo.png Amazon Redshift is a data warehousing solution from Amazon Web Services. It is a fully managed, petabyte-scale data warehouse service in the cloud.

In order to integrate Amazon Redshift you will need to create a new role with permissions to allow Relyance AI's AWS account to read table and schema details.

This process is defined through 4 requirements:

  1. Create a new role (explained below) in your AWS account (allowing Relyance AI AWS Account access).
  2. Grant this role the permissions for read/list and GetClusterCredentials.
  3. Add a trust relationship in the role to be accessed by the provided Relyance AWS account ID and Iam user name and external ID.
  4. This Relyance AI Integration will need the following details: Account ID, Role Name, External ID, Region, Cluster Identifier, Database User, and Database name.

In Amazon:

  1. Click Create Role in the Amazon Roles Identify and Access Management.
  2. On the role page enter the following:

Amazon-1.png

Under the Trusted entity type section: Under the An AWS account section:

  • AWS account: Selected
  • Another AWS Account: Selected
  • Account ID: 580082088342 (This is the Relyance AI’s account ID, that will be used to do the connection to your account using assumeRole).
  • Require external ID: Checked
  • External ID: Use <tenant-subdomain>-relyance, where 'tenant-subdomain' is your Relyance tenant name.
  1. Click Next.
  2. Attach a policy. AmazonRedshiftFullAccess will work, but it grants create, modify and delete on your clusters, which a read-only scan never uses — expect a security review to reject it. The least-privilege equivalent is a custom policy with exactly the actions listed under Verify the connection is really working below, which is also what the Terraform module at the end of this page generates.

RedshiftUpdate-1.png

Example Custom Policy: ---

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "redshift-data:ListTables",
        "redshift-data:DescribeTable",
        "redshift-data:GetStatementResult",
        "redshift:DescribeClusters",
        "redshift:GetClusterCredentialsWithIAM",
        "redshift:GetClusterCredentials",
        "redshift-data:DescribeStatement",
        "redshift-data:ListSchemas",
        "redshift-data:ListStatements",
        "redshift-data:ListDatabases",
        "redshift-data:ExecuteStatement"
      ],
      "Resource": "*"
    }

  ]
}

  1. Click Next to apply the policy.
  2. Fill out the role details: Name: Provide a meaningful name (e.g. relyance_redshift_integration) Description: Provide a meaningful description
  3. Click the Create role button.
  4. Open the newly created role, it should look something like this:
  5. Go to the Trust relationships tab on the newly created role.
  6. Click on the Edit trust policy.
  7. Change the line with 'Principal':
{
  "AWS": "arn:aws:iam::580082088342:root"
}

to

{
  "AWS": "arn:aws:iam::580082088342:user/tenant-prod-access"
}
  1. Click the Update policy button.

RedshiftUpdate-2.png

RedshiftUpdate-3.png

In the Relyance AI application:

  1. Login to your Relyance AI account.
  2. Navigate to the Settings (bottom-left corner).
  3. Select Integrations.
  4. Search and locate the Amazon Redshift integration card and click on it.
  5. Click on the Add Connection button on the top right.
  6. Provide a meaningful name for the integration and click on the Add button.
  7. In the Overview section, select the integration features you wish to enable for the integration, review the Scope and Permission, and Endpoint details and click on Continue. For more details, see Integration Features.
  8. In the Connection section, provide the appropriate values and click on Continue,
    • Connection Name: This property allows you to update the integration specified in Step 6. If you have multiple integrations for the same vendor, you may want to assign distinct names to each. This helps streamline filtering by Discovery Source across the Inventory, Visual Maps, Assets, and Data Flow Analysis pages.
    • Rescan Frequency: This property allows you to configure how often Relyance executes scans against this Vendor connection.
    • Business Atlas Associations (required): the business entities or products that newly discovered third parties, services and assets from this integration are attributed to. Choose at least one from the Select Associations dropdown — the wizard will not advance past this step without one. For more details, see Business Atlas.
  9. In the Authentication section, choose IAM Assume-Role (the only method Redshift offers), provide the following retrieved from the Amazon Redshift section, and click Continue.
    • Account ID

    • Role Name

    • External ID

    • Region

    • Cluster Identifier — optional; leave empty to auto-discover every cluster in the region.

    • Database User — optional; leave empty to connect as the IAM role.

    • Default Database — optional.

    • Scan Config Options — required. Allow/deny lists scoping which databases and tables are scanned; deny wins, and the pattern is database.table:

      {
        "allow_list": [],
        "deny_list": ["your_database.*"]
      }
    • Maximum Concurrent API Calls — optional; lower it to be gentler on the cluster.

  10. This step applies only if the Data Inspection check box was enabled in Step 7. In the Data Inspection section, provide the appropriate values and click on Continue,
    • Minimum Confidence Level: This property adjusts the sensitivity of the Data Inspection feature. Lower likelihoods (e.g., unlikely) offer more coverage but may produce false positives, while higher sensitivity (e.g., very likely) provides greater accuracy but less coverage.
    • Sampling Percentage: This property adjusts the percentage of records using the table's row count (1000 records max) to return from a table.
  11. Review the configuration summary from the Completion section and click on Finish.
  12. Confirm the integration Status reflects Connected.

Screenshot

Screenshot 2025-11-04 104236.png

Screenshot

Screenshot

Screenshot

  • Leave Cluster Identifier empty to have every cluster in the region discovered, and fill it in only when one specific cluster is in scope. Discovery uses redshift:DescribeClusters.
  • Leave Database User empty so the connection authenticates as the IAM role itself (redshift:GetClusterCredentialsWithIAM) rather than as a named database user. That removes the second credential to manage.
  • Lower Maximum Concurrent API Calls if the scan is competing with production queries — the Data API shares the cluster's capacity.
  • No firewall change is needed. Relyance uses the Redshift Data API, an AWS service endpoint, rather than a direct SQL connection to the cluster, so the security group and publicly-accessible setting are untouched. This is the main practical difference from the RDS integration.

Verify the connection is really working

Permission Used for
redshift:DescribeClusters discovering clusters in the region
redshift:GetClusterCredentialsWithIAM authenticating as the IAM role
redshift-data:ListDatabases, ListSchemas, ListTables, DescribeTable walking the catalog
redshift-data:ExecuteStatement, ListStatements, DescribeStatement, GetStatementResult running the sampling query and collecting its result
  1. Tables are discovered but nothing is classified. The Data API statement permissions and the in-database privileges are separate: the IAM identity still needs SELECT on the schemas you want read. Granting the IAM policy without granting SELECT inside Redshift produces a complete catalog and an empty classification.
  2. A failure at Authenticate is the trust policy or the external ID; both must match the connection exactly.
  3. No clusters found. Either the region on the connection is not the region the cluster is in, or redshift:DescribeClusters is missing. One connection covers one account and region.
  4. Redshift Serverless is not covered by these permissions. They are the provisioned-cluster API (redshift:DescribeClusters); serverless workgroups sit behind a different API surface. If your data is on Serverless, raise it with your Relyance contact rather than widening the policy.

Manage this integration with Terraform

Connections for this integration can be managed as code with the Relyance Terraform provider. Non-secret fields go in auth.params; secret fields go in auth.secrets_wo, which is write-only — never stored in Terraform state. Rotate secrets by bumping auth.secrets_wo_version.

resource "relyance_integration_connection" "aws_redshift" {
  vendor = "aws_redshift"
  name   = "<your connection name>"

  auth = {
    method = "iam-role"
    params = {
      accounts = "<accounts>"
      role_name = "<role_name>"
      external_id = "<external_id>"
      region = "<region>"
      config_options = jsonencode({
        allow_list = []
        deny_list = [
          "your_database.*"
        ]
      })
    }
  }

  scans = { "data-inspection" = { enabled = true } }
}