Introduction
Amazon Quick enables secure connectivity to Amazon Redshift clusters across different AWS regions and accounts, supporting distributed data architectures with centralized analytics. This guide outlines the implementation approach for connecting Quick to a Redshift cluster cross region and cross account using VPC peering and Redshift Database Credentials.
Solution Architecture
The solution uses VPC peering to establish private connectivity between Quick and Redshift located in different Accounts and region. Data flows through the peering connection without traversing the public internet, with security groups controlling traffic on port 5439.
The solution consists of the following key components:
· Amazon Quick (us-east-1) on Account A
· Amazon Redshift Cluster (us-west-2) on Account B
Key Requirements:
-
Non-overlapping CIDR blocks between VPCs
-
VPC peering for private connectivity
-
Security groups configured for port 5439
-
DNS resolution enabled on both VPCs
-
Appropriate IAM permissions
Implementation Steps
The foundation of a cross-region solution is secure, reliable network connectivity. VPC peering provides a straightforward approach for connecting VPCs across Regions. To implement VPC peering in Amazon Virtual Private Cloud (Amazon VPC), complete the following steps
Create a new VPC in the Quick region
-
Open the Amazon VPC console in the us-east-1 Region.
-
Choose Create VPC.
-
Set IPv4 CIDR block to eg :173.32.0.0/16 (verify there is no overlap with the Redshift Region VPC).
-
Select VPC and more (auto-creates subnets, route tables)
-
Leave other settings as default and choose Create VPC.
-
Note the VPC ID for later use.
Set up VPC Peering in the Quick region
VPC peering requires non-overlapping CIDR blocks between the two VPCs. Verify your VPC CIDR blocks do not overlap before proceeding.
1. On the Amazon VPC console, choose Peering connections in the navigation pane and choose Create peering connection.
2. Select the new us-east-1 VPC ID as the requester.
3. For Select another VPC to peer with, select Another account and Another Region.
4. Choose the Redshift Region (us-west-2) and enter the VPC ID of the Redshift VPC
5. Choose Create peering connection.
Accept the VPC Peering
1. Switch to the Redshift Account and Region.
2. On the VPC console ,choose Peering connections in the navigation pane and select the pending connection.
3. On the Actions dropdown menu, choose Accept request
4. Verify the VPC peering connection status is “Active”
Update the Route Tables
Update the Route Tables
1.On the Quick Region VPC, identify route tables associated with VPC subnets:
Navigate to VPC Console → Route tables
Click “Subnet associations” tab
Find route tables used by subnets selected for Quick VPC connection
2. For EACH identified route table:
Add route: Destination = 172.31.0.0/16, Target = Peering connection
Verify route shows “Active” status
3.On the Redshift Account and Region Amazon VPC console, repeat the process, adding a route to the Quick Region VPC CIDR (eg: 173.32.0.0/16) using the peering connection
Configure Security groups
On the Quick Region Amazon VPC console, choose Security groups in the navigation pane and create a new security group.
Add an outbound rule:
-
Type: Custom TCP
-
Port range: 5439
-
Protocol: TCP (auto-populated)
-
Destination: Redshift Region VPC CIDR
On the Redshift Region Amazon VPC console, locate the Redshift cluster’s security group.
a. Add an inbound rule:
· Type: Custom TCP
· Port range: 5439
· Source: Quick Region VPC CIDR
Configure DNS Settings
On the Amazon VPC console for both Regions, choose Your VPCs in the navigation pane.
Select each VPC, and on the Actions dropdown menu, choose Edit VPC Settings.
Select 1) Enable DNS resolution, 2) Enable DNS hostnames under DNS Settings
This completes the network connectivity between the Quick and Redshift Cluster.
Configure Quick
With network connectivity established, complete the following steps to configure Quick to securely access the Redshift data.
1.Verify IAM Service Role Permissions
Before configuring the VPC connection, ensure the Amazon Quick service role has the necessary permissions.
a. Open the Amazon Quick console
b. Click on your username in the top-right corner
c. Select “Manage Quick” from the dropdown menu
d. Navigate to “permissions” in the left navigation pane
e. Scroll down to " AWS services"
f. Check the box for "Amazon Redshift” under “Allow access and auto discovery for these resources”
h. Click “Save”
This will automatically create or update the service role (aws-quicksight-service-role-v0) with basic permissions.
Navigate to the IAM console in a new browser tab
· In the left navigation pane, choose “Roles”
· Search for and select “aws-quicksight-service-role-v0”
· Verify the role has the following EC2 permissions for VPC connections:
• ec2:CreateNetworkInterface
• ec2:DescribeNetworkInterfaces
• ec2:CreateNetworkInterfacePermission
• ec2:DeleteNetworkInterface
• ec2:DescribeSubnets
• ec2:DescribeSecurityGroups
If these permissions are missing, attach a custom policy with the above permissions to the service role
2.Set up a Quick VPC connection:
a. Open the Quick console in the Quick Region.
b. Choose Manage Quick, VPC connections, and Add VPC connection.
c. Configure the connection:
· Name: Enter a name (for example, Cross-Region-Connection).
· VPC: Choose the Quick Region VPC.
· Subnet: Choose the automatically created subnets.
· Security group: Choose the security group created for cross-Region access.
Verify the connection and create datasets
1. On the Quick Admin Console (Manage Quick → AWS Services), grant access to Redshift.
2. On the Quick console, choose Datasets in the navigation pane.
3. Choose Create dataset, then choose create data source
4. Configure the connection:
i. Data source name: Enter a descriptive name.
ii. Connection type: Choose the VPC connection.
iii. Database server: Enter the Redshift cluster endpoint.
iv. Port: 5439
v. Database name: Enter the database name.
vi. Username and Password: Enter credentials.
5. Choose Validate connection to test.
6. Choose Create data source.
7. Choose the schema and tables from the database.
8. Create analysis and dashboards as needed.
Troubleshooting
Connection Timeout Check security group rules allow outbound traffic from Quick VPC on port 5439 and inbound traffic to Redshift cluster from Quick CIDR. Verify route tables contain correct routes in both regions. Confirm VPC peering connection shows “Active” status.
Authentication Failed Verify database credentials are correct and user exists in Redshift with appropriate permissions.
VPC Connection Stuck “Creating” Verify sufficient IP addresses available in selected subnets. Confirm security group attached to VPC connection allows necessary traffic. Check Quick service role has permissions for creating network interfaces.
Slow Query Performance Consider switching from direct query to SPICE for frequently accessed data. Optimize Redshift table structures with appropriate sort keys and distribution styles. Review query execution plans and implement materialized views for common aggregations.
Dataset Refresh Failures Check Redshift cluster availability during scheduled refresh times. Verify sufficient SPICE capacity available. Review Redshift logs for table locks or long-running queries.
Performance considerations for cross-Region analytics
When implementing a cross-Region analytics architecture, be aware of the following performance implications. Cross-Region queries can experience higher latency than single-Region queries, so consider importing frequently used datasets into SPICE (Super-fast, Parallel, In-memory Calculation Engine) to avoid repeated cross-Region queries — SPICE is the Quick Sight in-memory engine that enables fast, interactive visualizations by precomputing and storing datasets locally in the Quick Sight Region. Additionally, minimize the volume of data transferred between Regions by filtering at the source and pushing down predicates where possible, and enable result caching where supported to reduce redundant cross-Region data retrieval.
Conclusion
The cross-Region architecture described in this post addresses specific challenges related to regional compliance requirements and global analytics needs. This approach is particularly well-suited to scenarios where your data must remain in a specific Region for compliance reasons — such as data sovereignty or regulatory mandates — yet teams distributed across different Regions still need to access and analyze that data. It also accommodates situations where distinct user groups have varying workload requirements, enabling each regional environment to be optimized independently to serve the performance and access needs of its respective audience.
References
https://docs.aws.amazon.com/quick/latest/userguide/working-with-aws-vpc.html
https://docs.aws.amazon.com/quick/latest/userguide/create-a-database-data-set.html