Setting up VPC Peering on AWS - Cube

<Note>

This page covers backend connectivity — Cube reaching into your network to query data sources, auth providers, BI APIs targeted by Semantic Layer Sync, and other upstream services. See Backend and frontend connectivity for the full picture. For frontend connectivity (exposing Cube's APIs to your applications, browsers, BI tools, and embedded analytics clients), see Private API Connectivity on AWS.

</Note>

To set up AWS VPC Peering between Cube's Dedicated Infrastructure and your VPC, you collect the information below and hand it over to your Cube representative. Next, you accept a VPC peering request initiated by Cube, then configure security groups and route tables so that Cube can reach your data source.

Information required by Cube

To allow Cube to peer with a VPC on AWS, please share the following with the Cube team:

AWS Account ID: The AWS account ID of the VPC owner. This can be found in the top-right corner of the AWS Console.
AWS Region: The AWS region that the VPC resides in.
AWS VPC ID: The ID of the VPC that Cube will connect to, for example vpc-0099aazz.
AWS VPC CIDR: The CIDR block of the VPC that Cube will connect to, for example 10.0.0.0/16.
Cube Region: VPC Peering requires Cube to be hosted on Dedicated Infrastructure. Specify which Cube Region should host your Dedicated Infrastructure.

Setup

Accepting the peering request

After receiving the information above, Cube will send a VPC peering request that must be accepted. This can be done either through the AWS Web Console or through an infrastructure-as-code tool.

To accept the VPC peering request through the AWS Web Console, follow the instructions below:

Open the Amazon VPC console.
<Warning>
Ensure you have the necessary permissions to accept a VPC peering request. If you are unsure, please contact your AWS administrator.
</Warning>
Use the Region selector to choose the Region of the accepter VPC.
In the navigation pane, choose Peering connections.
Select the pending VPC peering connection (the status should be pending-acceptance), then choose Actions, followed by Accept request.
<Warning>
Ensure the peering request is from Cube by checking that the AWS account ID, region, and VPC IDs match those provided by your CSM.
</Warning>
When prompted for confirmation, choose Accept request.
Choose Modify my route tables now to add a route to the VPC route table so that you can send and receive traffic across the peering connection.

<Info>

For more information about peering connection lifecycle statuses, check out the VPC peering connection lifecycle on AWS.

</Info>

Updating security groups

The initial VPC setup will not allow traffic from Cube; this is because the security group for the database will need to allow access from the Cube VPC CIDR block.

This can be achieved by adding a new security group rule:

Protocol	Port Range	Source/Destination
TCP	3306	The Cube VPC CIDR block for the AWS region.

<Info>

The Cube VPC CIDR block is shared with you by the Cube team alongside the peering request, and is also visible in the AWS Console on the Peering connections → <your peering> → Details page as the Requester VPC CIDR.

</Info>

Updating route tables

The final step is to update route tables in your VPC to allow traffic from Cube to reach your database. The Cube VPC CIDR block must be added to the route tables of all subnets that connect to the database. To do this, follow the instructions on the AWS documentation.

Troubleshooting

Database connection issues with misconfigured VPCs often manifest as connection timeouts. If you are experiencing connection issues, please check the following:

Verify that all security groups allow traffic from the Cube VPC CIDR block.
Verify that a route exists to the Cube VPC CIDR block from the subnets that connect to the database.

Supported Regions

VPC Peering is available in all AWS commercial regions where Dedicated Infrastructure can be provisioned. AWS China (cn-north-1, cn-northwest-1) and AWS GovCloud (us-gov-east-1, us-gov-west-1) are not supported.