Establish private connectivity between Amazon QuickSight and Snowflake using AWS PrivateLink

October 2023: This post was reviewed and updated to include SPICE setup

Amazon QuickSight is a scalable, serverless, embeddable, machine learning-powered business intelligence (BI) service built for the cloud. QuickSight lets you easily create and publish interactive BI dashboards that include Machine Learning-powered insights. QuickSight dashboards can be accessed from any device, and seamlessly embedded into your applications, portals, and websites.

QuickSight offers several sources for data, including but not limited to Amazon Athena, Amazon Redshift, Amazon Simple Storage Service (Amazon S3), and Snowflake. This post presents solutions to enable you to set up Snowflake as a data source for QuickSight regardless of your network configuration requirements.

We cover the following configurations of Snowflake as a data source for QuickSight:

• QuickSight connection to Snowflake via AWS PrivateLink
• QuickSight connection to Snowflake via AWS PrivateLink and virtual private cloud (VPC) peering (same Region)
• QuickSight connection to Snowflake via AWS PrivateLink and VPC peering (cross-Region)
• QuickSight connection to Snowflake (public network)

Prerequisites

To complete this solution, you need the following:

• An AWS account
• The AWS Command Line Interface(AWS CLI) installed on your workstation (for instructions, see (Installing, updating, and uninstalling the AWS CLI version 2)
• An Enterprise edition QuickSight account
• A Business Critical tier Snowflake account
• A Snowflake database and table
• A Snowflake warehouse
• Sufficient AWS Identity and Access Management(IAM) privileges to create VPC endpoints, security groups, route tables, and Amazon Route 53 hosted zones and resource record sets.   IAM user that can call AWS STS GetFederationToken

QuickSight connection to Snowflake via AWS PrivateLink

First, we show you how to connect to Snowflake with QuickSight over AWS PrivateLink. The following diagram illustrates the solution architecture.

The process involves the below steps, which we will further detail.

• Identify an AWS VPC to use
• Generate an AWS Security Token Service (STS) federated token
• Enable Amazon VPC PrivateLink on Snowflake
• Enable internal staging on Snowflake for Amazon QuickSight SPICE
• Create an Amazon VPC Security Group
• Create AWS VPC PrivateLink
• Create an Amazon VPC Endpoint for Amazon S3 Interface
• Configure DNS for Snowflake endpoints in your VPC
• Configure DNS for Snowflake internal stage in your VPC
• Configure a Route 53 resolver inbound endpoint for your VPC
• Connect a VPC to QuickSight
• Set up a Snowflake data source through the VPC
• Create your first QuickSight dashboard

Identify an AWS VPC to use

 This VPC should be:

• In the same region as intended Snowflake setup
• DNS hostnames enabled
• DNS resolution enabled
• Provisioned with private subnets

Generate an AWS Security Token Service (STS) federated token

From the AWS CLI, using an IAM user that can call get-federation-token, execute the below to get the AWS Security Token Service federation token.

aws sts get-federation-token --name sam
{
    "Credentials": {
        "AccessKeyId": "xxxxx",
        "SecretAccessKey": "xxxxx",
        "SessionToken": "xxxxx”,
        "Expiration": "xxxxx"
    },
    "FederatedUser": {
        "FederatedUserId": "123xxx:sam",
        "Arn": "arn:aws:sts::123xxx:federated-user/sam"
    },
    "PackedPolicySize": 0
}

Save the output for the next step.

Enable Amazon VPC PrivateLink on Snowflake

In a Business Critical tier account of Snowflake, enable AWS PrivateLink by executing the below, where <aws_id> is the 12 digit AWS account in FederatedUserId (the number before ’:sam’), and the <federated_token>, would be the entire output from prior step.

use role accountadmin;
select SYSTEM$AUTHORIZE_PRIVATELINK ( '<aws_id>' , '<federated_token>' );

For example:

use role accountadmin;
select SYSTEM$AUTHORIZE_PRIVATELINK (
    '123xxx...',
    '{
       "Credentials": {
           "AccessKeyId": "xxxxx",
           "SecretAccessKey": "xxxxx",
           "SessionToken": "xxxxx",
           "Expiration": "xxxxx"
       },
       "FederatedUser": {
           "FederatedUserId": "123xxx:sam",
           "Arn": "arn:aws:sts::123xxx:federated-user/sam"
       },
       "PackedPolicySize": 0
    }'
)

Enable internal staging on Snowflake for Amazon QuickSight SPICE

 Amazon QuickSight SPICE (Super-fast, Parallel, In-memory Calculation Engine) is Amazon QuickSight’s in-memory engine for rapid intelligent queries and calculations.  Snowflake uses Amazon S3 as an internal stage for Amazon QuickSight SPICE.  Enable this internal staging by running the below in Snowflake.

alter account set enable_internal_stages_privatelink = true; 

Note that Amazon QuickSight Direct Query, and trivial storage amounts on SPICE will still function without the above.  But for any material QuickSight SPICE use, and to leverage QuickSight’s AI/ML facilities, SPICE, and this Snowflake’s internal staging, needs to be enabled.

After Amazon VPC PrivateLink and the internal stage is enabled, retrieve the configuration for your region by running the following command in a Snowflake worksheet, then retrieve the values for privatelink-vpce-id,  privatelink-account-url, privatelink_ocsp-url  and privatelink-internal-stage. Examples of each value are as follows.

select SYSTEM$GET_PRIVATELINK_CONFIG();

privatelink-vpce-id: com.amazonaws.vpce.<region>.vpce-svc-xxxxxxxxxxxxxxxxx
privatelink-account-url: xxxx.<region>.privatelink.snowflakecomputing.com
privatelink_ocsp-url: ocsp.xxxxxxx.<region>.privatelink.snowflakecomputing.com
privatelink-internal-stage":"xxx. stage.s3.<region>.amazonaws.com"

Save these values for later use. 

Create an Amazon VPC Security Group

We now pre-emptively create an Amazon VPC Security Group to be used for the Amazon VPC PrivateLink.

Add HTTP and HTTPS Inbound rules, and a general Outbound rule.  Your rule specifics and CIDR blocks  can vary depending on your VPC and your environment. For the CIDR block, you can read from the AWS Management Console for VPC or run the below CLI command.

aws ec2 describe-vpcs --vpc-ids vpc-xxxxxxx

 Create AWS VPC PrivateLink

• From the AWS Management Console for VPC, create a new endpoint.
• Under Other endpoint services, find the service that you created before, using the previously queried value from Snowflake: privatelink-vpce-id.
• Verify the service – if it does not verify, check to ensure that the PrivateLink has been enabled on Snowflake earlier, in the same region as the VPC.
• Use the same VPC that was used to enable PrivateLink on Snowflake.  Choose private subnets.  For high availability, choose more than one subnet in different AWS Availability Zones.
• Configure with the AWS VPC Security Group that was created in the previous step.

Once created, note the DNS names associated with the endpoint. Store these values for later use.

Create an Amazon VPC Endpoint for Amazon S3 Interface

Create an endpoint for the Amazon S3 Interface as well in the same VPC.

• Find the S3 service under AWS Services. The same security group from before can be used, or another can be created. The S3 Gateway type can also be used, but for this exercise, we’ll use the S3 Interface type.

VPC Policy can be further customized – we’ll leave it on default settings for this exercise.

Note the DNS names for later use.

Configure DNS for Snowflake endpoints in your VPC

To configure your Snowflake endpoints, complete the following steps:

1. On the Route 53 console, choose Hosted Zones in the navigation pane.
2. Choose Create hosted zone.
3. For Domain name, enter the value you stored for privatelink-account-url from the previous steps.

In this field, we remove the Snowflake account ID from the DNS name and only use the value starting with the Region identifier (for example, <region>.privatelink.snowflakecomputing.com). We create a resource record set later for the subdomain.

Next. we create a CNAME record for privatelink-internal-stage.

We use the Snowflake internal stage S3 bucket name, and the regional DNS name of the S3 Interface VPC endpoint created earlier.   The first art of privatelink-internal-stage is the S3 bucket name.  Combine with the S3 interface endpoint DNS name from before to create the value.

Value: <S3 bucket name from privatelink-internal-stage>.<S3 Interface VPC Endpoint DNS name>

Configure a Route 53 resolver inbound endpoint for your VPC

QuickSight doesn’t use the standard AWS resolver (the VPC’s .2 resolver). To resolve private DNS from QuickSight, you need to set up Route 53 resolver endpoints.

First, we create a security group for the Route 53 resolver inbound endpoint.

1. On the Security groups page of the Amazon VPC console, choose Create security group.
2. Enter a name for your security group (for example, quicksight-doc-route53-resolver-sg) and a description.
3. Choose the VPC ID used in previous steps.
4. Create rules that allow for DNS (Port 53) over UDP and TCP from within the VPC CIDR block.
5. Choose Create security group.
6. Note the security group ID, because we now add a rule to allow traffic to the VPC endpoint security group.

Now we create the Route 53 resolver inbound endpoint for our VPC.

1. On the Route 53 console, choose Inbound endpoint in the navigation pane.
2. Choose Create inbound endpoint.
3. For Endpoint name, enter a name (for example, quicksight-inbound-resolver).
4. For VPC in the Region, choose the VPC ID used in previous steps.
5. For Security group for the endpoint, choose the security group ID you saved earlier.

6. In the IP address section, choose two Availability Zones and subnets, and leave Use an IP address that is selected automatically selected.

7. Choose Submit.
8. Choose the inbound endpoint after it’s created and take note of the two IP addresses for the resolvers.

Connect a VPC to QuickSight

To connect a VPC to QuickSight, complete the following steps:

1. On the Security groups page of the Amazon VPC console, choose Create security group.
2. Enter a name (for example, quicksight-snowflake-privatelink-sg) and a description.
3. Choose the VPC ID used in previous steps.

Security groups for QuickSight are different from other security groups in that they are stateless, rather than stateful. This means you must explicitly allow return traffic from the targeted security group. The inbound rule in your security group must allow traffic on all ports. It needs to do this because the destination port number of any inbound return packets is set to a randomly allocated port number. For more information, see Inbound Rules.

4. Choose Create security group.
5. Take note of the security group ID, because we now add a rule to allow traffic to the VPC endpoint security group.
6. On the Security groups page, search for the security group ID that is used for the VPC endpoint.
7. Choose Edit inbound rules.
8. Add rules for both HTTPS and HTTP traffic, using the security group ID for the security group you created as the source.
9. Choose Save rules.

We then create an Amazon QuickSIght service role that can create the VPC Connection in QuickSight. This service role would have trust relationships such as the below.

With policies allowing the below:

With this service role created, we can create the VPC connection.

10. Navigate to the QuickSight console.
11. Choose the user name and choose Manage QuickSight.

12. In the navigation pane, choose Manage VPC connections.
13. Choose Add a VPC connection.
14. For VPC connection name, enter a name (for example, snowflake-privatelink).
15. For VPC ID, choose the VPC used in previous steps.
16. Use the Execute role that was created in the last step.
17. Add the private Subnets from the VPC that were used in the earlier steps.
18. Add the Security group that was created in the earlier steps.
19. For DNS resolver endpoints, enter the two IPs for the inbound resolver endpoint you created earlier.

Set up a Snowflake data source through the VPC

To set up a Snowflake data source, complete the following steps.

1. On the QuickSight console, choose Datasets in the navigation page.
2. Choose New dataset.
3. Choose the Snowflake option.
4. For Data source name, enter a name (for example, snowflake).
5. For Connection type¸ choose the VPC connection you created earlier (snowflake-privatelink).
6. For Database server, enter privatelink-account-url.
7. For Database name, enter the name of your database.
8. For Warehouse, enter the name of a running Snowflake warehouse.
9. For Username, enter your Snowflake username.
10. For Password, enter your Snowflake password.
11. Choose Validate.
12. Upon successful validation, choose Create data source.

Create your first QuickSight dashboard

In this section, we cover creating a dataset in QuickSight, then using this data in a visualization. We’re using a dummy dataset that has information about fictional employees.

1. For Schema, choose your schema.
2. For Tables, select your tables.
3. Choose Select.

In the Finish dataset creation section, you can determine if QuickSight imports your dataset into SPICE to improve query performance or directly queries your data each time a dashboard is loaded. For more information about SPICE, see Importing Data into SPICE.

4. For this post, we select Import to SPICE for quicker analytics.
5. Choose Visualize.

Now that we have the schema, table, and SPICE configuration for the dataset, we can create our first visualization.

6. Choose a field from the available fields list. For this post, we choose City.
7. Choose a visualization in the Visual types

This only scratches the surface of the visualization capabilities of QuickSight. For more information, see Working with Amazon QuickSight Visuals.

Next, we cover a network configuration that allows for QuickSight to be connected to one VPC with AWS PrivateLink in another VPC, and use VPC peering to allow QuickSight to use the AWS PrivateLink connection.

QuickSight connection to Snowflake via AWS PrivateLink and VPC peering within the same Region

In this section, we show you how to connect to Snowflake with QuickSight with two VPCs peered and AWS PrivateLink. The following diagram illustrates the solution architecture.

Set up VPC peering

First, we create the VPC peering connection from the requesting VPC.

1. On the Peering connections page of the Amazon VPC console, choose Create peering connection.
2. For Select a local VPC to peer with, choose the VPC in which you configured your Snowflake AWS PrivateLink connection.

3. In the Select another VPC to peer with section, leave the default options for Account and Region (My account and This Region, respectively).
4. For VPC (Accepter), choose the VPC where your QuickSight is connected to.

5. Choose Create peering connection.

Next, we accept the VPC connection from the accepting VPC.

6. On the Peering connections page, select the connection you created.
7. On the Actions menu, choose Accept.
8. Review the information about the request. If everything looks correct, choose Yes, Accept.

Next, we configure DNS to resolve between the two VPCs.

9. On the Peering connections page, choose your new peering connection.
10. On the DNS tab, check if the two options show as Disabled.

If they’re enabled, you can skip to the steps on creating route tables.

11. On the Actions menu, choose Edit DNS Settings.

This requires your VPC to have DNS host name and resolution enabled.

12. Select both check boxes to allow DNS to resolve from both the acceptor and requestor VPCs.
13. Choose Save.

Next, create the route table entry to allow for routes to propagate between the two VPCs.

14. On the Route tables page, choose the route tables in your requesting VPC.
15. On the Route tab, choose Edit routes.
16. Add a route for the CIDR block that your peered VPC uses (for this post, 172.31.0.0/16).
17. Choose Save routes.

18. Repeat for the route tables in your accepter VPC.

Configure DNS in the accepter VPC

In this section, we associate the accepter VPC that with the same private hosted zone as the requester VPC (<region>.privatelink.snowflakecomputing.com).

1. On the Route 53 console, choose Hosted zones in the navigation pane.
2. Select the hosted zone <region>.privatelink.snowflakecomputing.com and choose Edit.
3. In the VPCs to associate with the hosted zone section, choose Add VPC.
4. Choose the Region and VPC ID associated with the accepter VPC.

5. Choose Save changes.

Configure Route 53 resolver inbound endpoints in the accepter VPC

To configure your Route 53 resolver inbound endpoints, complete the following steps:

1. On the Security groups page of the Amazon VPC console, choose Create security group.
2. Enter a name (for example, quicksight-doc-route53-resolver-sg) and a description.
3. Choose the VPC ID used in previous steps.
4. Create rules that allow for DNS (port 53) over UDP and TCP from within the VPC CIDR block (for this post, 172.31.0.0/16).
5. Choose Create security group.

6. Take note of the security group ID, because we now add a rule to allow traffic to the VPC endpoint security group.

Next, we set up the Route 53 inbound endpoint for this VPC.

7. On the Route 53 console, choose Inbound endpoint in the navigation pane.
8. Choose Create inbound endpoint.
9. Enter a name for the endpoint (for example, quicksight-inbound-resolver).
10. For VPC in the Region, choose the VPC ID for the accepter VPC.
11. For Security group, choose the security group ID you saved earlier.
12. In the IP Address section, select two Availability Zones and subnets, and leave Use an IP address that is selected automatically
13. Choose Submit.
14. Choose the inbound endpoint after it’s created.
15. After the inbound endpoint has provisioned, note the two IP addresses for the resolvers.

Connect the accepter VPC to QuickSight

To start, we need to create a security group for QuickSight to allow traffic to the Route 53 resolver inbound endpoints, the VPC endpoint for AWS PrivateLink, and traffic within the local network.

1. On the Security groups page of the Amazon VPC console, choose Create security group.
2. Enter a name (for example, quicksight-snowflake-privatelink-vpc-peering-sg) and a description.
3. Choose the VPC ID for the accepter VPC.
4. Create the following ingress rules:

1. 1. One rule for the local network for all TCP ports (e.g., 172.31.0.0/16).
   2. One rule allowing DNS traffic from the security group for the Route 53 resolver inbound endpoint for all TCP ports.
   3. One rule allowing DNS traffic from the security group for the Route 53 resolver inbound endpoint for all UDP ports.
   4. One rule allowing traffic to the security group for the VPC endpoint (located in the peered VPC).

As discussed earlier, security groups for QuickSight are different from other security groups. You must explicitly allow return traffic from the targeted security group, and the inbound rule in your security group must allow traffic on all ports. For more information, see Inbound Rules.

Next, we modify the security group for the Route 53 resolver inbound endpoint to allow traffic from the security group we created.

5. On the Security groups page, search for the security group ID used for the Route 53 resolver inbound endpoint.
6. Choose Edit inbound rules.
7. Add rules for both DNS over UDP and DNS over TCP, using the security group ID for the security group we created for QuickSight as the source.

8. Choose Save rules.

Next, modify the security group that was created for the VPC endpoint for the AWS PrivateLink connection.

9. On the Security groups page, search for the security group ID used for the VPC endpoint for the AWS PrivateLink connection.
10. Choose Edit inbound rules.
11. Add rules for both HTTPS and HTTP, using the security group ID for the security group created for QuickSight as the source.
12. Choose Save rules.

Next, we set up the VPC connection in QuickSight.

13. On the QuickSight console, choose the user name and choose Manage QuickSight.
14. In the navigation pane, choose Manage VPC connections.
15. Choose Add a VPC connection.
16. For VPC connection name¸ enter a name (for example, snowflake-privatelink-vpc-peering).
17. For Subnet, choose a subnet ID that has a route table with a peering connection to the requester VPC where the AWS PrivateLink connection resides.
18. For Security group ID, enter the ID of the security group created earlier.
19. For DNS resolver endpoints, enter the two IPs for the inbound resolver endpoint you created.
20. Choose Create.

Set up a Snowflake data source in QuickSight through the VPC

To set up a Snowflake data source in QuickSight, complete the following steps:

1. On the QuickSight console, choose Datasets in the navigation pane.
2. Choose New dataset.
3. Choose the Snowflake option.
4. Enter a data source name (for example, snowflake-dataset).
5. Choose the VPC connection you created (snowflake-privatelink).
6. For Database server, enter the privatelink-account-url.
7. For Database name, enter the name of your database.
8. For Warehouse, enter the name of a running Snowflake warehouse.
9. For Username, enter your Snowflake username.
10. For Password, enter your Snowflake password.
11. Choose Validate.
12. Upon successful validation, choose Create data source.

For steps to create a dashboard, see the earlier section, Create your first QuickSight dashboard.

In the next section, we cover a similar network configuration, with the difference being that we use cross-Region VPC peering.

QuickSight connection to Snowflake via AWS PrivateLink and VPC peering across Regions

In this section, we show you how to connect to Snowflake with QuickSight over AWS PrivateLink with two VPCs peered across Regions.

We refer to Regions generically throughout this post, denoting the Region that has the Snowflake AWS PrivateLink connection as Region A and the Region in which QuickSight is set up as Region B.

The following diagram illustrates our solution architecture.

Set up VPC peering between two Regions

First, we create the VPC peering connection from the requesting VPC.

1. Navigate to the Peering connections page on the Amazon VPC console in Region B (the Region in which you plan to use QuickSight to deploy dashboards).
2. Choose Create peering connection.
3. In the Select a local VPC to peer with section, for VPC (Requester), choose the VPC in which you have connected or intend to connect QuickSight.

4. For Select another VPC to peer with, select My account and Another Region.
5. Choose the Region in which your Snowflake AWS PrivateLink connection exists.
6. For VPC ID (Accepter), enter the VPC ID for the VPC in which your Snowflake AWS PrivateLink exists.

7. Choose Create peering connection.
8. Copy the VPC peering connection ID so we can easily locate it in the next steps (it looks like pcx-xxxxxxxxxxxx).

Next, we accept the VPC peering connection from the Region in which you created your AWS PrivateLink connection.

9. Navigate to the Amazon VPC console in Region A (where your Snowflake AWS PrivateLink connection exists).
10. Search for and select the peering connection you created.
11. On the Actions menu, choose Accept Request.

12. Review the information about the request. If everything looks correct, choose Yes, Accept.

Next, we configure DNS to resolve between the two VPCs.

13. On the Peering connections page of the Amazon VPC console, choose your newly created VPC peering connection.
14. On the DNS tab, check if the two options show Disabled.

If they’re enabled, skip to the steps on creating route tables.

15. On the Actions menu, choose Edit DNS settings.

This requires your VPC to have DNS host name and resolution enabled.

16. Select both check boxes to allow DNS to resolve from both the accepter and requestor VPCs.
17. Choose Save.

Next, we create the route table entry to allow for routes to propagate between the two VPCs for Region B.

18. Navigate to the Amazon VPC console in Region B (the Region in which you plan to use QuickSight to deploy dashboards).
19. In the navigation pane, choose Route tables.
20. Select the route tables in your requesting VPC.
21. On the Route tab, choose Edit routes.
22. Add a route for the CIDR block that your peered VPC uses (for this post, 10.0.0.0/16 is the CIDR block for the VPC in which the Snowflake AWS PrivateLink connection resides).
23. Choose Save routes.

Next, create the route table entry to allow for routes to propagate between the two VPCs for Region A.

24. Navigate to the Amazon VPC console in Region A (where your Snowflake AWS PrivateLink connection exists).
25. Repeat the previous steps, using the CIDR block for the peered VPC (in this post, 172.16.0.0/16).

Configure DNS in the VPC in Region B

First, we need to associate the VPC in Region B (where you deploy QuickSight) with the same private hosted zone as the VPC in Region A where your Snowflake AWS PrivateLink connection exists (<region>.privatelink.snowflakecomputing.com).

1. On the Route 53 console, choose Hosted zones in the navigation pane.
2. Select the private hosted zone <region>.privatelink.snowflakecomputing.com and choose Edit.
3. In the VPCs to associate with the hosted zone section, choose Add VPC.
4. Choose the Region and VPC ID associated with the accepter VPC.

5. Choose Save changes.

Configure the Route 53 resolver inbound endpoint for your VPC in Region B

To configure the resolver inbound endpoint in Region B, complete the following steps:

1. On the Security groups page on the Amazon VPC console, choose Create security group.
2. Enter a name (for example, quicksight-doc-route53-resolver-sg) and a description.
3. Choose the VPC ID used in previous steps.
4. Create rules that allow for DNS (port 53) over UDP and TCP from within the VPC CIDR block (for this post, 172.16.0.0/16).

5. Choose Create security group.
6. Take note the security group ID, because we now add a rule to allow traffic to the VPC endpoint security group.

Next, we set up the Route 53 inbound endpoint for this VPC.

7. On the Route 53 console, choose Inbound endpoint in the navigation pane.
8. Choose Create inbound endpoint.
9. Enter a name for the endpoint (for example, quicksight-inbound-resolver).
10. For VPC in the Region, choose the VPC ID used in previous steps.
11. For Security group, choose the security group ID from the previous step.
12. In the IP Address section, select two Availability Zones and subnets, and leave Use an IP address that is selected automatically
13. Choose Submit.
14. Choose the inbound endpoint after it’s created.
15. After the inbound endpoint has provisioned, note the two IP addresses for the resolvers.

Connect the VPC to QuickSight in Region B

To start, we need to create a security group for QuickSight to allow traffic to the Route 53 resolver inbound endpoints, the VPC endpoint for AWS PrivateLink, and traffic within the local network.

1. On the Security groups page of the Amazon VPC console in Region B, choose Create security group.
2. Enter a name (for example, quicksight-snowflake-sg) and a description.
3. Choose the VPC ID for the VPC where you previously created the VPC peering connection.
4. Create the following ingress rules:

1. 1. One for the local network all TCP ports (for example, 172.16.0.0/16).
   2. One rule allowing DNS traffic from the security group for the Route 53 resolver inbound endpoint for all TCP ports.
   3. One rule allowing DNS traffic from the security group for the Route 53 resolver inbound endpoint for all UDP ports.
   4. One allowing traffic for all TCP ports to the CIDR block for the VPC located in Region A, where your Snowflake AWS PrivateLink connection exists (for this post, 10.0.0.0/16).

As discussed earlier, security groups for QuickSight are different from other security groups. You must explicitly allow return traffic from the targeted security group, and the inbound rule in your security group must allow traffic on all ports. For more information, see Inbound Rules.

Next, we modify the security group for the Route 53 resolver inbound endpoint in Region B to allow traffic from the security group we created.

5. On the Security groups page, search for the security group ID used for the Route 53 resolver inbound endpoint.
6. Choose Edit inbound rules.
7. Add rules for both DNS over UDP and DNS over TCP, using the CIDR block for the VPC in Region B (for this post, 172.16.0.0/16).

8. Choose Save rules.

Next, we need to modify the security group we’re using for the AWS PrivateLink connection.

9. Navigate to the Security groups page on the Amazon VPC console in Region A.
10. Search for the security group ID that is used for the VPC endpoint for the AWS PrivateLink connection.
11. Choose Edit inbound rules.
12. Add rules for both HTTPS and HTTP, using the CIDR Block for the VPC in Region B as the source (for this post, 172.16.0.0/16).

13. Choose Save rules.

Finally, we set up the QuickSight VPC connection.

14. Navigate to the QuickSight console in Region B.
15. Choose the user name and choose Manage QuickSight.
16. In the navigation pane, choose Manage VPC connection.
17. Choose Add a VPC connection.
18. For VPC connection name, enter a connection name (for example, snowflake-privatelink-cross-region).
19. For VPC ID, choose the VPC ID of the VPC in Region B.
20. For Subnet, choose a subnet ID from the VPC in Region B that has a route table with a peering connection to the VPC where the AWS PrivateLink connection resides.
21. For Security group ID, enter the ID of the security group you created.
22. For DNS resolver endpoints, enter the two IPs for the inbound resolver endpoint created earlier.

23. Choose Create.

Set up a Snowflake data source in QuickSight through the VPC

To set up a Snowflake data source in QuickSight, complete the following steps:

1. On the QuickSight console, choose Datasets in the navigation pane.
2. Choose New dataset.
3. Choose the Snowflake option.
4. Enter a name for your data source (for example, snowflake-dataset).
5. Choose the VPC connection you created (snowflake-privatelink).
6. For Database server, enter the privatelink-account-url.
7. For Database name, enter the name of your database.
8. For Warehouse, enter the name of a running Snowflake warehouse.
9. For Username, enter your Snowflake username.
10. For Password, enter your Snowflake password.
11. Choose Validate.
12. Upon successful validation, choose Create data source.

For steps to create a dashboard, see the earlier section, Create your first QuickSight dashboard.

For our last configuration, we cover how to set up a QuickSight connection to Snowflake without AWS PrivateLink.

QuickSight connection to Snowflake without AWS PrivateLink

In this section, we show you how to connect to Snowflake with QuickSight without using AWS PrivateLink.

1. On the QuickSight console, choose Datasets in the navigation pane.
2. Choose New dataset.
3. Choose the Snowflake option.
4. Enter a data source name (for example, snowflake-dataset).
5. Leave the connection type as Public network.
6. For Database name, enter the name of your database.
7. For your database server, enter the URL you use to log in to your Snowflake (xxxxxxxx.snowflakecomputing.com).
8. For Warehouse, enter the name of a running Snowflake warehouse.
9. For Username, enter your Snowflake username.
10. For Password, enter your Snowflake password.
11. Choose Validate.
12. Choose Create data source.

For steps to create a dashboard, see the earlier section, Create your first QuickSight dashboard.

Clean up

If your work with QuickSight, Snowflake, and PrivateLink is complete, remove your Route53 resolver inbound endpoint, Route 53 private host zone, and the VPC endpoint for Snowflake in order to avoid incurring additional fees.

Conclusion

In this post, we covered four scenarios for connecting QuickSight to Snowflake as a data source using AWS PrivateLink for connectivity in three different scenarios: the same VPC, with VPC peering in the same Region, and with VPC peering across Regions. We also covered how to connect QuickSight to Snowflake without AWS PrivateLink.

After you set up the data source, you can gain further insights from your data by setting up ML Insights in QuickSight, set up graphical representations of your data using QuickSight visuals, or join data from multiple datasets, as well as all other QuickSight features.

About the Authors

Maxwell Moon is a Senior Solutions Architect at AWS working with Independent Software Vendors (ISVs) to design and scale their applications on AWS. Outside of work, Maxwell is a dad to two cats, is an avid supporter of the Wolverhampton Wanderers Football Club, and is patiently waiting for a new wave of ska music.

Bosco Albuquerque is a Sr Partner Solution Architect at AWS and has over 20 years of experience in working with database and analytics products, from enterprise database vendors, and cloud providers and has helped large technology companies in designing data analytics solutions as well as led engineering teams is designing and implementing data analytics platforms and data products.

Joe Cho is a Senior Technical Account Manager at AWS with extensive experience building, managing and supporting Financial Services technical infrastructure. Outside of work, Joe is an avid off-roader and competitive fighting games enthusiast.