PrivateLink

Private Preview | Workbench | Advanced

Overview

The Workbench Native App supports operating in a Snowflake PrivateLink (AWS) enabled account. Please reach out to your Snowflake representative to request more information on when Azure and GCP PrivateLink may become available.

This configuration enables secure PrivateLink-based communication from the Snowflake-managed containerized environment (SPCS) into your VPC for OAuth and SQL traffic. Due to current limitations in Snowflake’s Native Application framework, outbound access to Snowflake’s own endpoints (such as OAuth and SQL APIs) is not directly supported within Snowflake’s PrivateLink infrastructure.

To address this, Snowflake explicitly documents and supports this configuration using a VPC Endpoint Service and Network Load Balancer, which enables your application to proxy outbound traffic back to Snowflake’s PrivateLink interfaces.

All resources created in this setup—VPC Endpoint Services, internal Network Load Balancers, private IP target groups, and Snowflake external access configurations—are standard AWS networking primitives, deployed in accordance with both Snowflake’s validated PrivateLink architecture and AWS PrivateLink best practices. No public-facing infrastructure is created, and all traffic remains confined within your AWS environment, maintaining strong security and network boundaries.

Network architecture

A high level overview of the required AWS resources is shown below. If you have already configured Snowflake private connectivity for outbound traffic you may not have to create any AWS resources.

This architecture uses:

• A VPC interface endpoint to connect to Snowflake privately.
• A Network Load Balancer that proxies SPCS outbound requests to Snowflake.
• A VPC Endpoint Service accepted by Snowflake.

PrivateLink Architecture

Summary of steps

This guide assumes you have already followed the regular Workbench App installation steps. Once you have completed this configuration, all Snowflake data and OAuth will travel through your configured VPC.

In order to use Workbench in PrivateLink you must:

1. Configure AWS PrivateLink access for your Snowflake account.
2. Create a VPC Endpoint Service backed by an NLB.
3. Register your service in Snowflake with an external access integration.
4. Notify the Native App to use this PrivateLink.

For more information see Snowflake instructions on setting up PrivateLink and setting up private endpoints.

Configure AWS PrivateLink to Snowflake

You must configure your AWS platform to access Snowflake via your PrivateLink VPC. Snowflake provides detailed instructions on getting this set up. If you are already using PrivateLink to access your Snowflake account and the Snowsight UI you likely already have this setup.

This setup process is complicated and easy to get wrong; we highly advise that you meet with your Snowflake Account representative while getting this set up. Failure to get this set up properly will result in weird errors later in the setup that are difficult to debug.

Important

Take special care to configure all the Snowflake DNS entries. Even if you have already configured PrivateLink in the past you should check these since there are special SPCS endpoints that were recently introduced.

Once you have this step complete, please take note of the VPC endpoint DNS name the Snowflake instructions ask you to create. It should have the form vpce-<id>.<region>.vpce.amazonaws.com. Make sure to choose the DNS entry which does not have a zone in it and only has a region. This will allow you to resolve all the IPs associated with that VPC endpoint.

Validate DNS

Ensure your Private Hosted Zones are set up and resolve the following endpoints inside your VPC:

• <org-account>.privatelink.snowflakecomputing.com
• *.registry.snowflakecomputing.com
• OAuth endpoints (/oauth/authorize, etc.)

In order to determine your <org-account>.privatelink.snowflakecomputing.com use the following SQL. The format of the url is important later for Workbench OAuth authentication. The PrivateLink account url should be lowercase and substitute - for all _ characters.

SELECT REPLACE(LOWER(CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME() || '.privatelink.snowflakecomputing.com'), '_', '-');

Determine the internal IPs for the VPC endpoint

You can resolve this VPC endpoint from outside of your VPC using a terminal tool or python.

dig +short vpc-endpoint

import socket
print(socket.gethostbyname("<vpc-endpoint>"))

You should get several IPs all within your VPC keep track of these for configuring the network load balancer later.

Create and configure AWS private endpoint service

To allow Snowflake to send egress traffic from the SPCS Workbench Native Application you need to create a service endpoint for Snowflake to connect into. The Snowflake docs detail several outbound configurations but for our specific use case we must configure a VPC endpoint service.

Important

The VPC Endpoint Service must be in the same AWS region as your Snowflake account.

While configuring the Private Endpoint Service, it will ask you to create a new Network Load Balancer.

Once created in your AWS account you will need the VPC service endpoint name of the form com.amazonaws.vpce.us-west-2.vpce-svc-012345678910f1234.

Configure Network Load Balancer

1. Create an internal network load balancer
2. Create a listener for TCP on port 443 detailed in the AWS documentation on listeners
3. Create and register a target group with ipv4 for TCP and set the target IPs to the VPC endpoint IPs resolved above. The target status should be Healthy after a minute. AWS provides detailed documentation on creating a target group.

Example code

aws elbv2 create-load-balancer \
  --name proxy-nlb \
  --type network \
  --scheme internal \
  --subnets subnet-xxxxxxxx subnet-yyyyyyyy

aws elbv2 create-target-group \
  --name ip-targets \
  --protocol TCP \
  --port 443 \
  --target-type ip \
  --vpc-id vpc-xxxxxxxx \
  --health-check-protocol TCP \
  --health-check-port 443 \
  --health-check-interval-seconds 30

aws elbv2 register-targets \
  --target-group-arn <target-group-arn> \
  --targets Id=10.51.16.135,Port=443

aws elbv2 create-listener \
  --load-balancer-arn <nlb-arn> \
  --protocol TCP \
  --port 443 \
  --default-actions Type=forward,TargetGroupArn=<target-group-arn>

Important

Wait for the target status to report healthy in 2-3 minutes. If they are not healthy this setup will not work. It is extremely likely that a misaligned security group is the cause of the issue. Your Snowflake configuration will have no impact on the status of these target groups.

Create AWS VPC Endpoint Service

1. Create a VPC endpoint service configuration using your network load balancer (Note the service name or ID created)
2. Add your PrivateLink account principal to the allowed principals tab for the endpoint

Example code

Find Snowflake’s allowed principal:

SELECT key, value
FROM TABLE(FLATTEN(INPUT => PARSE_JSON(SYSTEM$GET_PRIVATELINK_CONFIG())));

aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns <nlb-arn> \
  --acceptance-required

aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id <service-id> \
  --add-allowed-principals arn:aws:iam::<snowflake-account-id>:root

Provision endpoint in Snowflake

Now we have to inform Snowflake for outbound connectivity to route traffic through our newly created VPC Service Endpoint detailed in the Snowflake outbound connectivity docs. We inform Snowflake to connect to our VPC service endpoint via the following SQL. Please substitute your VPC service endpoint name and <org-account>.privatelink.snowflakecomputing.com that was checked in Validate DNS.

Note

Snowflake allows for a maximum of 10 registered private endpoints per account.

call SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
    'com.amazonaws.vpce.us-west-2.vpce-svc-aaaa',      -- proxy endpoint service name
    '<org-account>.privatelink.snowflakecomputing.com' -- privatelink snowflake account url
);

If you misconfigure this step you will need to contact Snowflake support to have the endpoint revoked which can take 1-3 days.

Approve endpoint request

Once you have executed the Snowflake SQL, several minutes later you will have to approve the Snowflake request on your VPC Endpoint Service. AWS documentation details how to approve. Upon completion all that remains is configuring the Workbench Native Application to send traffic through this.

Approved endpoint

Check that the endpoint has been set up - this may take up to an hour to fully provision.

SELECT SYSTEM$GET_PRIVATELINK_ENDPOINTS_INFO();

SELECT * from SNOWFLAKE.ACCOUNT_USAGE.OUTBOUND_PRIVATELINK_ENDPOINTS;

Important

If you have not approved this endpoint request it means that the snowflake connection is not established and further steps will not work.

Example code

aws ec2 accept-vpc-endpoint-connections \
  --service-id <service-id> \
  --vpc-endpoint-ids <endpoint-id>

aws ec2 describe-vpc-endpoint-connections \
  --filters Name=service-id,Values=<service-id>

Modify Snowflake app configuration

Snowflake does not currently provide support for our Native Application to present users with multiple configuration options for external access. Thus we have to give instructions for customers to modify the existing external access integration and network rule setup on initial install.

Create network rules

You will need to create one network rule. A private host port rule to route traffic through the VPC Service Endpoint you setup in AWS. Use DNS name <org-account>.privatelink.snowflakecomputing.com from DNS validation

Substitute your application name in {POSIT_WORKBENCH} below and your Snowflake account url in the value list. Both host and port 443 need to be specified.

CREATE OR REPLACE NETWORK RULE
{POSIT_WORKBENCH}_APP_DATA.DATA.PRIVATE_EGRESS
  MODE = EGRESS
  TYPE = PRIVATE_HOST_PORT
  VALUE_LIST = ('<org-account>.privatelink.snowflakecomputing.com:443');

Alter External Access Integration

Modify the existing external access integration to only allow private egress using your network rules. You can find the correct integration name by running SHOW EXTERNAL ACCESS INTEGRATIONS.

ALTER EXTERNAL ACCESS INTEGRATION POSIT_WORKBENCH_EGRESS_EXTERNAL_ACCESS
  SET ALLOWED_NETWORK_RULES = (POSIT_WORKBENCH_APP_DATA.DATA.PRIVATE_EGRESS);

Set the Workbench Native Application ENABLE_PRIVATELINK reference

Visit the native application details page and configure the ENABLE_PRIVATELINK reference. The value of this secret does not matter but it being set notifies the application that PrivateLink is enabled.

Configure reference

Add secret

Setting this value should trigger the Workbench Native Application to upgrade and be available in 2-3 minutes.

Update Workbench OAuth redirect URI

Since the URL for the Workbench native application has changed to use the PrivateLink URLs, we need to update the OAuth redirect URIs.

CALL POSIT_WORKBENCH.APP.WORKBENCH_OAUTH_UPDATE()

Test connection

Everything should just work at this point. In fact if your Workbench Native App starts it means that our network checks for PrivateLink have already succeeded. Visit your Workbench Native Application.

1. Complete the normal OAuth managed credential flow in Workbench; you should see OAuth authentication go through PrivateLink URLs and complete successfully
2. Start a session in any IDE

• Open a terminal and run cat $SNOWFLAKE_HOME/connections.toml and you should see a .privatelink in the text

3. Follow the Posit Workbench user guide for connecting with R in RStudio or Positron
4. Follow the Posit Workbench user guide for connecting with Python in VS Code, Jupyter, or Positron

FAQ

What if I want to connect to other resources within my VPC?

This can be important if you have other resources like myservice.company.com that is only accessible within your VPC and you want to expose to your SPCS Workbench Native App running PrivateLink. This is completely possible but be aware of the Snowflake limit that allows for a maximum of 10 registered private endpoints per account. You have already used one by following this guide.

To add myservice.company.com you will perform the same steps again as outlined above but with slight modifications. The overall goal of these changes is to instead point the network load balancer to the myservice.company.com service accessible within your VPC. This service could for example be a VM running within your VPC but is not limited to that.

1. Start at configuring Private Endpoint Service and give the endpoint service a name that relates to the dns name.
2. When configuring the network load balancer targets instead of setting IPs for the VPC endpoint to snowflake you need to point the targets to your instance. See the AWS documentation on setting targets there are many target types other than IP. If you are running a VM it is likely that instance target type may be appropriate. It is hard for us to give exact instructions here.
3. When provisioning the Snowflake endpoint instead of using <org-account>.privatelink.snowflakecomputing.com substitute the host name that you want to be forwarded in your Workbench Native App such as myservice.company.com.

call SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
    'com.amazonaws.vpce.us-west-2.vpce-svc-aaaa',      -- proxy endpoint service name
    'myservice.company.com'                            -- hostname to forwad within SPCS Workbench Native App
);

4. Instead of creating a network rule to attach to your external access integration you should intead alter the network rule and add the new endpoint myservice.company.com. These changes should apply immediately

ALTER NETWORK RULE
{POSIT_WORKBENCH}_APP_DATA.DATA.PRIVATE_EGRESS
  MODE = EGRESS
  TYPE = PRIVATE_HOST_PORT
  VALUE_LIST = ('<org-account>.privatelink.snowflakecomputing.com:443', 'myservice.company.com');

5. No need to alter the external access integration

Troubleshooting

Setting up PrivateLink properly can go wrong in many ways. When troubleshooting we suggest starting from the VPC endpoint to Snowflake and then moving towards the SPCS Workbench Native Application when debugging. All customers VPCs can look entirely different. We have marked important checks throughout this guide on things to check.

1. Check that Network Load Balancer target groups are healthy this step gives you high assurance that the VPC endpoint service is properly connected to your VPC endpoint for Snowflake (basically all AWS specific components are configured properly). Note that security groups are a common way that health checks fail.
2. Check that you have accepted the VPC endpoint request this step completed confirms that Snowflake is connected to your VPC.
3. Check that <org-account>.privatelink.snowflakecomputing.com matches in the provision Snowflake endpoint and the network rule that you created and that the hostname is the one generated from validating DNS.
4. Check that the PrivateLink application reference is set and that Workbench is accessible after setting. If Workbench starts this means that the network check by our application checking PrivateLink succeeded.

If you are still running into issues please contact support@posit.co and detail which step is currently failing.