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

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. Modify the Native App to use this PrivateLink configuration.

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

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 have a DNS name of the form vpce-svc-<id>.<region>.vpce.amazonaws.com for your VPC service endpoint. Additionally 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>

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 DNS name.

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
    'vpce-svc-1111.us-west-2.vpce.amazonaws.com'     -- proxy endpoint service DNS
);

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

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;

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 two network rules. A host port rule for your Snowflake account endpoint and a private host port rule for your proxy endpoint.

  1. Host port rule for Snowflake account URL
Important

This network rule is needed to resolve DNS for your account name. All traffic to this endpoint will still go through PrivateLink.

If you wish to add your account to a network rule using a private host port then you will need to create a secondary service endpoint using that hostname.

Determine your Snowflake account URL with the following SQL.

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

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

CREATE OR REPLACE NETWORK RULE
{POSIT_WORKBENCH}_APP_DATA.DATA.EGRESS
  MODE = EGRESS
  TYPE = HOST_PORT
  VALUE_LIST = ('org-account.privatelink.snowflakecomputing.com:443');
  1. Private host port for NLB DNS name

Substitute your application name in {POSIT_WORKBENCH} below and your proxy endpoint DNS name in the value list. Both host and port 443 needs to be specified.

CREATE OR REPLACE NETWORK RULE
{POSIT_WORKBENCH}_APP_DATA.DATA.PRIVATE_EGRESS
  MODE = EGRESS
  TYPE = PRIVATE_HOST_PORT
  VALUE_LIST = ('vpce-svc-1111.us-west-2.vpce.amazonaws.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, POSIT_WORKBENCH_APP_DATA.DATA.EGRESS,);

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. 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
  1. Follow the Posit Workbench user guide for connecting with R in RStudio or Positron
  2. Follow the Posit Workbench user guide for connecting with Python in VS Code, Jupyter, or Positron
Back to top