How to Connect Amazon Redshift to Google Sheets (VPC Security Group Setup Included)

You can connect Amazon Redshift to Google Sheets in three ways: UNLOAD to S3 then import (manual, no live connection), Apps Script JDBC (free, requires VPC access), or a third-party connector like brooked.io (automated, works inside a private VPC). Before any method works, you must configure your VPC security group to allow inbound traffic on port 5439. This is the single most common silent failure, and it will block every connection attempt without any meaningful error message.

Why Redshift Connections Fail Silently

The most common Redshift connection failure looks like this: you enter your credentials, click Connect, and the application hangs for 30 seconds before timing out with a generic "connection failed" or "could not connect to host" message. There is no indication of what went wrong.

The cause, in the vast majority of cases, is the VPC security group.

Amazon Redshift clusters run inside a Virtual Private Cloud (VPC). By default, the security group attached to your Redshift cluster does not allow any inbound traffic from outside the VPC. This is correct behavior from a security standpoint, but it means that every external connection attempt, including from Apps Script, a third-party connector, or even your own laptop running a SQL client, will fail silently.

The security group acts as a stateful firewall at the network level. When an inbound connection attempt arrives on port 5439 (Redshift's default port) from an IP address not permitted by the security group, the connection is simply dropped. The client receives no error response. It just times out. This is why the failure is silent: there is no "access denied" message, no error code, nothing except a timeout.

This is the single most common silent failure when connecting Redshift to Google Sheets. Configure the security group first. Every other step depends on it.

VPC Security Group Configuration (Step by Step)

This section walks through the exact steps to open port 5439 in your Redshift cluster's security group. You need AWS Console access with at least read access to EC2 (security groups) and Redshift.

Step 1: Find Your Cluster's Security Group

Navigate to the Amazon Redshift console. If you are using Redshift Provisioned, click "Clusters" in the left navigation and select your cluster. If you are using Redshift Serverless, click "Workgroups" and select your workgroup.

On the cluster or workgroup detail page, look for the "Network and security" section (sometimes under a "Properties" tab). You will see a field labeled "VPC security groups" with one or more security group IDs and names listed as clickable links.

Click the security group link. This takes you to the EC2 Security Groups console with that group already selected.

Step 2: View the Inbound Rules

With your security group selected in the EC2 console, click the "Inbound rules" tab at the bottom of the page. You will see the existing rules that allow inbound traffic to your Redshift cluster.

A newly created cluster often has no inbound rules, or a single rule permitting traffic only from within the VPC CIDR block. Neither allows external connections.

Step 3: Edit Inbound Rules

Click "Edit inbound rules."

Click "Add rule."

Configure the new rule:

• Type: Select "Custom TCP" (or "Redshift" if it appears in your dropdown. This pre-fills port 5439).
• Protocol: TCP (pre-filled).
• Port range: 5439.
• Source: This is the critical decision.

Step 4: Configure the Source

Your source options are:

Option A. Specific IP address or CIDR: Enter the IP address of the connector or client that needs access, in CIDR notation (e.g., 203.0.113.47/32 for a single IP). This is the most secure option. Use it when your connector publishes a static IP range for whitelisting.

Option B. Anywhere (0.0.0.0/0): Allows connections from any IP address on the internet. This is the fastest way to test connectivity but is not recommended for production clusters containing sensitive data. Use this temporarily to confirm connectivity, then lock it down to specific IPs.

Option C. VPC CIDR or security group: If your connector runs inside the same VPC (for example, a Lambda function or an EC2 instance acting as a relay), you can scope the rule to the VPC CIDR block or to another security group ID. This is the most secure architecture for production.

For connecting to Google Sheets via Apps Script, Apps Script runs on Google's infrastructure outside your VPC. You need either Option A (whitelist Google's IP ranges, which change and are difficult to maintain statically) or Option B for testing.

For a third-party connector like brooked.io, the connector publishes a static IP range. Use Option A with that IP range.

Step 5: Add a Description and Save

Enter a description for the rule (e.g., "brooked.io connector" or "Apps Script access"). This makes it easier to audit rules later.

Click "Save rules."

Changes take effect within seconds. No restart of your Redshift cluster is required.

Step 6: Verify Cluster Publicly Accessible Setting

Security group rules are necessary but not sufficient if your cluster is not configured to be publicly accessible.

On your cluster detail page, look for "Publicly accessible" in the Network and security section. If it shows "No," your cluster can only be reached from within the VPC, regardless of security group rules.

To change this: Click "Actions" > "Modify cluster." Find the "Network and security" section. Check "Enable publicly accessible." Save changes. The cluster will apply the modification. This takes a few minutes.

For Redshift Serverless, look for "Publicly accessible" on the Workgroup configuration page under "Network and security."

Note: Making your cluster publicly accessible exposes the endpoint to the internet. Combine this with restrictive security group rules (specific IP whitelisting) rather than leaving it open to 0.0.0.0/0.

Finding Your Credentials in AWS Console

Finding Redshift connection credentials is a 30-minute time sink for most users the first time, because the information is spread across multiple places in the AWS Console and the endpoint string requires parsing.

The Endpoint String

Navigate to your Redshift cluster detail page. In the "General information" or "Connection details" section, find the "Endpoint" field. It looks like this:

mycluster.xxxxxxxxxxxx.us-east-1.redshift.amazonaws.com:5439/mydatabase

This string contains three pieces of information:

• Host: mycluster.xxxxxxxxxxxx.us-east-1.redshift.amazonaws.com (everything before the colon)
• Port: 5439 (the number after the colon, before the slash)
• Database name: mydatabase (everything after the slash)

When configuring a connector or JDBC connection string, you need these three values separately. Do not paste the full endpoint string into a "host" field: strip the port and database name first. This is an extremely common mistake that produces a confusing connection error.

The Master User Credentials

When you created your Redshift cluster, you set a master username and password. If you do not remember the password, you can reset it: on the cluster detail page, click "Actions" > "Reset admin password."

If your organization uses AWS Secrets Manager for Redshift credentials (common in security-conscious teams), navigate to AWS Secrets Manager, find the secret associated with your Redshift cluster, and retrieve the username and password from there.

The Database Name

The database name is embedded in the endpoint string after the slash, as shown above. The default database name for a new cluster is typically dev. Your actual data may be in a different database. Check with whoever set up the cluster if you are unsure.

Redshift Serverless Credentials

For Redshift Serverless, the endpoint appears on the Workgroup detail page and follows a slightly different format:

workgroupname.accountid.us-east-1.redshift-serverless.amazonaws.com:5439/dev

Apply the same parsing: host is everything before the colon, port is 5439, database is after the slash.

Redshift Provisioned vs Serverless: Auth Differences

Redshift Provisioned and Redshift Serverless share the same wire protocol and port, but they differ in authentication capabilities.

Redshift Provisioned:

• Supports database users with passwords (standard username/password authentication).
• Supports IAM authentication via GetClusterCredentials API (generates temporary credentials).
• Supports federated identity via SAML.
• For Google Sheets integration, standard database user authentication is the most practical approach.

Redshift Serverless:

• Supports database users with passwords.
• Supports IAM authentication via GetWorkgroupCredentials API (note: different API call than Provisioned).
• Does not support some older authentication methods that work with Provisioned.
• Standard database user authentication works the same way as Provisioned.

For both deployment types, the practical approach for connecting to Google Sheets is to use a database user with a password. IAM authentication requires generating temporary credentials (which expire) and is not practical for a persistent connector or Apps Script connection without additional infrastructure to refresh them.

One key difference: Redshift Serverless requires you to explicitly set a password for the admin user after creating the workgroup, because Serverless supports IAM-based admin access as the default. If you created a Serverless workgroup and did not set a password, you need to connect via the Redshift Query Editor in the AWS Console and run ALTER USER admin PASSWORD 'your_password' (replacing admin with your actual admin username).

Method 1: UNLOAD to S3 Then Import

Best for: Large datasets, one-time exports, situations where a live connection is not required.

How it works:

Redshift's UNLOAD command writes query results to Amazon S3 as CSV files. You then download those files and import them into Google Sheets.

UNLOAD ('SELECT * FROM your_schema.your_table WHERE created_at > CURRENT_DATE - 30')
TO 's3://your-bucket/exports/your_table_'
IAM_ROLE 'arn:aws:iam::123456789:role/RedshiftS3Role'
CSV
HEADER
PARALLEL OFF;

After the UNLOAD completes, navigate to the S3 bucket in the AWS Console, find the exported file(s), download them, and import into Google Sheets via File > Import.

Limitations:

• Requires an IAM role with S3 write access attached to the Redshift cluster.
• PARALLEL OFF produces a single file, which is easier to import. Without it, Redshift splits the output across multiple files.
• Completely manual. No live connection, no scheduling.
• Google Sheets has a 5 million cell limit and does not handle very large CSVs well.

There is no AWS-native export path that pushes data directly to Google Sheets. You cannot connect Redshift to Sheets from within the AWS Console. The UNLOAD approach requires the intermediate S3 step.

Method 2: Apps Script JDBC

Best for: Technical teams comfortable with JavaScript who want free, automated scheduled refreshes and have public VPC access configured.

Google Apps Script's JDBC service supports Redshift via the PostgreSQL JDBC driver. Redshift is wire-compatible with PostgreSQL, and this works reliably for standard queries.

Prerequisites

• VPC security group configured to allow inbound TCP on port 5439 from Google's IP ranges (or 0.0.0.0/0 for testing).
• Cluster publicly accessible setting enabled.
• Database user with password authentication.
• Endpoint host, port (5439), and database name parsed separately from the endpoint string.

Step 1: Open Apps Script

In your Google Sheet, go to Extensions > Apps Script.

Step 2: Write the Connection Script

function importFromRedshift() {
  // Parse these from your endpoint:
  // mycluster.xxxx.us-east-1.redshift.amazonaws.com:5439/mydatabase
  var host = 'mycluster.xxxx.us-east-1.redshift.amazonaws.com';
  var port = '5439';
  var database = 'mydatabase';
  var username = 'your_db_user';
  var password = 'your_password';

  // JDBC connection string for Redshift (uses PostgreSQL driver)
  var connectionString = 'jdbc:redshift://' + host + ':' + port + '/' + database;

  // Alternative: use PostgreSQL driver directly
  // var connectionString = 'jdbc:postgresql://' + host + ':' + port + '/' + database;

  var conn = Jdbc.getConnection(connectionString, username, password);

  var query = 'SELECT * FROM your_schema.your_table LIMIT 5000';
  var stmt = conn.createStatement();
  stmt.setMaxRows(5000);

  var results = stmt.executeQuery(query);
  var metaData = results.getMetaData();
  var numCols = metaData.getColumnCount();

  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Redshift Data');
  if (!sheet) {
    sheet = SpreadsheetApp.getActiveSpreadsheet().insertSheet('Redshift Data');
  }
  sheet.clearContents();

  // Write headers
  var headers = [];
  for (var i = 1; i <= numCols; i++) {
    headers.push(metaData.getColumnName(i));
  }
  sheet.appendRow(headers);

  // Batch rows for performance
  var rows = [];
  while (results.next()) {
    var row = [];
    for (var j = 1; j <= numCols; j++) {
      row.push(results.getString(j));
    }
    rows.push(row);
    if (rows.length >= 500) {
      sheet.getRange(sheet.getLastRow() + 1, 1, rows.length, numCols).setValues(rows);
      rows = [];
    }
  }
  if (rows.length > 0) {
    sheet.getRange(sheet.getLastRow() + 1, 1, rows.length, numCols).setValues(rows);
  }

  results.close();
  stmt.close();
  conn.close();

  Logger.log('Import complete. Rows written: ' + (sheet.getLastRow() - 1));
}

Step 3: Schedule the Script

Click the Triggers (clock) icon in Apps Script. Create a time-driven trigger for importFromRedshift. Choose a frequency that matches how often your Redshift data updates: hourly, daily, or weekly.

Redshift Serverless Connection String

For Redshift Serverless, use the workgroup endpoint:

var connectionString = 'jdbc:redshift://workgroupname.accountid.us-east-1.redshift-serverless.amazonaws.com:5439/dev';

Authentication is identical to Provisioned: database username and password.

Apps Script JDBC Limitations

• Requires a publicly accessible Redshift cluster. Many production clusters are private and cannot easily be made publicly accessible.
• Apps Script has a 6-minute execution timeout. Large queries will fail.
• No automatic error alerting without additional code.
• Maintaining Google's IP whitelist in your security group is operationally difficult because the ranges change.

Method 3: Third-Party Connectors

Best for: Teams that want automated, scheduled syncs from a private Redshift cluster without making it publicly accessible or managing firewall rules.

brooked.io: Designed for database-to-Google Sheets connections. Supports Redshift Provisioned and Serverless. Uses a secure outbound tunnel so your cluster does not need to be publicly accessible. Provides a static IP for security group whitelisting on clusters that can be made publicly accessible but want tight control. Automated scheduling with configurable refresh intervals. No code required.

Coefficient: Google Sheets add-on with Redshift support. Requires a publicly accessible cluster or network-level access. Good for self-service analytics use cases where users want to write queries interactively in Sheets.

Hightouch: Primarily a reverse ETL tool that pushes data from Redshift to business tools (CRMs, marketing platforms). Can write to Google Sheets but is more complex to configure for a simple Sheets sync. Better suited for operational use cases than analytics reporting.

Weld: Combines ETL and a SQL-based analytics layer. Can sync Redshift data to Google Sheets as part of a broader data pipeline. More overhead than a purpose-built Sheets connector but useful if you are also managing transformations.

Connector Comparison Table

WLM Memory Errors on Large Queries

Redshift's Workload Management (WLM) system allocates memory to queries running in different queues. When a query requests more memory than WLM has allocated to its queue, the query fails with an error like:

ERROR: Query exceeded memory limit

or

ERROR: WLM query slot count limit exceeded

These errors are more likely when querying large tables or running complex aggregations from a connector, because connector queries may run in the default WLM queue with conservative memory limits.

How to work around WLM memory errors:

1. Limit query scope: Add a WHERE clause to restrict the query to a recent time window or a subset of rows. This is the fastest fix. Example: WHERE created_at > CURRENT_DATE - 7 to limit to the last 7 days.

1. Use a materialized view or summary table: Create a Redshift materialized view or a summary table that pre-aggregates the data you need. Query the summary table instead of the raw data. This is also better for query performance and for not consuming Redshift cluster resources with every Sheets refresh.

1. Adjust WLM configuration: In the Redshift console, modify the WLM configuration to allocate more memory or more query slots to the queue where connector queries run. This requires DBA access and affects overall cluster resource allocation.

1. Use Redshift Concurrency Scaling: Enable Concurrency Scaling on your cluster. Concurrency Scaling automatically adds cluster capacity during periods of high demand. It does not specifically address memory limits but can help when slot limits are the issue.

1. UNLOAD the result set: For truly large result sets, use the UNLOAD approach to write to S3, then import the file. This avoids WLM limits entirely because UNLOAD has its own resource allocation path.

Best practice for ongoing connectors: Query only the data you actually need in your Google Sheet. Use aggregated queries (SUM, COUNT, AVG grouped by date or dimension) rather than raw row-level exports. A connector that pulls 10,000 aggregated rows once a day is far more efficient than one that pulls 10 million raw rows.

Troubleshooting

Connection times out with no error message This is almost always the VPC security group. Confirm: (1) the security group attached to your cluster has an inbound rule for TCP port 5439 from your connector's IP. (2) The cluster "Publicly accessible" setting is enabled. (3) You are connecting to the correct endpoint hostname (not the full endpoint string with port and database appended).

"FATAL: password authentication failed for user" The username or password is wrong. For Redshift Provisioned, reset the admin password via "Actions > Reset admin password" in the Redshift console. For Redshift Serverless, connect via the Query Editor (which uses IAM authentication) and run ALTER USER username PASSWORD 'newpassword'.

"Connection refused" on port 5439 The cluster is not publicly accessible, or the security group rule is not yet in effect, or you are connecting to the wrong hostname. Verify the "Publicly accessible" setting on the cluster and check that the security group change was saved.

Endpoint hostname is wrong or not resolving Make sure you stripped the port and database from the endpoint string. The host field in your connector or JDBC string should only contain the hostname portion: mycluster.xxxx.us-east-1.redshift.amazonaws.com. Do not include :5439 or /databasename in the host field.

Apps Script JDBC returns "Communications link failure" This typically means the connection timed out at the network level before the JDBC driver could establish a connection. Return to the security group configuration and verify the inbound rule is correctly configured.

WLM memory limit error Add a row limit to your query (LIMIT 10000) or add a WHERE clause to restrict the date range. For aggregate queries, ensure you are grouping appropriately. Consider querying a pre-built summary view instead of raw tables.

Data appears stale or sync does not run For Apps Script, check the Triggers configuration and review execution logs (View > Executions). For third-party connectors, check the connector dashboard for failed sync logs and error messages.

Bottom Line

Connecting Amazon Redshift to Google Sheets is primarily a networking and configuration challenge, not a code challenge. The single most common failure (a silent timeout) is caused by the VPC security group blocking port 5439. Configure the security group first and verify the cluster's publicly accessible setting before attempting any connection method.

For one-time or infrequent data exports, UNLOAD to S3 and manual import gets the job done without any persistent connectivity. For automated, scheduled syncs from a publicly accessible cluster, Apps Script JDBC is free and effective once the firewall is open. For private Redshift clusters, large-scale queries, or teams that want automation without infrastructure management, brooked.io handles the connectivity complexity and delivers scheduled Sheets syncs in about 15 minutes of setup.

The credential-finding process, the endpoint string parsing, and the WLM memory limits are friction points that every team hits. Work through them once with this guide and the connection becomes straightforward.

Get Connected in 15 Minutes

Connect Redshift to Google Sheets with brooked.io, works with private VPC clusters, no publicly accessible setting required, no firewall rule changes, no code. Scheduled, automated syncs from Redshift Provisioned or Serverless to any Google Sheet.

Related Guides

• How to Connect SQL Server to Google Sheets
• How to Connect PostgreSQL to Google Sheets
• How to Connect BigQuery to Google Sheets
• Google Sheets Database Sync: The Complete Guide

Troubleshooting quick reference

Frequently asked questions