This guide walks you through configuring Amazon Redshift as a destination for your Webflow Analyze and Optimize data export.
34.69.83.207/32 available during the following steps. It will be required in Step 2.Network allowlisting
Webflow Static IP: 34.69.83.207/32
Connect to Redshift using the SQL client.
Execute the following query to create a user to write the data (replace <password> with a password of your choice).
Creating a user without a password.
Role-based authentication does not require a password. You may create the user using CREATE USER <username> PASSWORD DISABLE;.
Grant user create and temporary privileges on the database. create allows the service to create new schemas and temporary allows the service to create temporary tables.
The schema will be created during the first sync
The schema name supplied as part of Step 4 will be created during the first connection. It does not need to be created manually in the destination ahead of time.
If the schema already exists
By default, the service creates a new schema based on the destination configuration. If you prefer to create the schema yourself before connecting the destination, you must ensure that the writer user has the proper permissions on the schema, using GRANT ALL ON schema <schema> TO <username>;
Once you’ve provided the GRANT ALL permission on the schema, you can safely remove the CREATE permission on the database (but you must retain the TEMPORARY permission on the database).
In the Redshift console, click Clusters, and make a note of the cluster name.
Select the cluster you would like to connect.
In the General information pane, make note of the Endpoint details. You may need to use the copy icon to copy the full details to discover the full endpoint and port number.

Click the Properties tab.
Scroll down to the Network and security settings section.
In the VPC security group field, select a security group to open it.

In the Security Groups window, click Inbound rules.
Click Edit inbound rules.
In the Edit the Inbound rules window, follow the steps below to create custom TCP rules for the static IP:
a. Select Custom TCP in the drop-down menu.
b. Enter your Redshift port number. (likely 5439)
c. Enter the static IP.
d. Click Add rule.
Public accessibility and subnet requirements
For IP allowlisting from outside your VPC, the Redshift cluster must be set to Publicly accessible and deployed in a public subnet with a route to an Internet Gateway. For private Redshift clusters, SSH tunneling is supported. Contact support for instruction on configuring an SSH tunnel for your Redshift cluster.
Create staging bucket
Create policy
Navigate to the IAM service page, click on the Policies navigation tab, and click Create policy.
Click the JSON tab, and paste the following policy, being sure to replace BUCKET_NAME with the name of the bucket chosen above, and REGION_NAME, ACCOUNT_ID, CLUSTER_NAME, USERNAME, and DATABASE_NAME with the proper Redshift values.
Note: the first bucket permission in the list applies to BUCKET_NAME whereas the second permission applies only to the bucket’s contents — BUCKET_NAME/* — an important distinction.
Credential character limitations
For user credentials containing special characters, please avoid using the following characters: @, [, ], /, ?, #, ", \\, +, space, &, : as these characters can break connection string parsing.
Click through to the Review step, choose a name for the policy, for example, transfer-service-policy (this will be referenced in the next step), add a description, and click Create policy.
Create role
Navigate to the IAM service page.
Navigate to the Roles navigation tab, and click Create role.
Select Custom trust policy and paste the provided trust policy (from the prerequisite) to allow AssumeRole access to this role. Click Next.
Add the permissions policy created above, and click Next.
Enter a Role name, for example, transfer-role, and click Create role.
Once successfully created, search for the created role in the Roles list, click the role name, and make a note of the ARN value.
Alternative authentication method: AWS User with HMAC Access Key ID & Secret Access Key
Role-based authentication is the preferred authentication mode for Redshift based on AWS recommendations. However, HMAC Access Key ID & Secret Access Key is an alternative authentication method that can be used if preferred.
transfer-service, click Next. Under Select AWS access type, select the Access key - Programmatic access option. Click Next: Permissions.Use the following details to complete the connection setup: username, host, database, cluster, your chosen schema, IAM role ARN, and staging bucket details.
CREATE and TEMPORARY on the database. If you pre-created the schema, ensure GRANT ALL ON SCHEMA <schema> TO <username>.redshift:GetClusterCredentials on your target cluster (db user and db name resources).ListBucket on arn:aws:s3:::BUCKET_NAME.GetObject, PutObject, DeleteObject on arn:aws:s3:::BUCKET_NAME/*.5439).We use role-based authentication with your AWS IAM Role. The data transfer service assumes your role to obtain short-lived database credentials and network access can be constrained by allowlisting the static egress IPs noted above.
Redshift’s high-throughput path loads data from S3 using COPY. We stage files briefly in your bucket to maximize throughput and reliability. Files are cleaned up after load.
These are identity claims used in the IAM trust policy when federating from GCP to AWS. sub uniquely identifies our Google principal in federation. oaud is an additional claim used to bind role assumption to your organization.
Common causes:
redshift:GetClusterCredentials (ensure it targets the correct cluster ARN and region/account).redshift-serverless:GetCredentials instead of provisioned cluster + redshift:GetClusterCredentials.No. The schema provided in the destination configuration is created automatically on first sync. If you pre-create it, grant ALL on the schema to the writer user and you may remove the database-level CREATE permission (retain TEMPORARY).