Private connectivity for outbound network traffic

Snowflake features such as external functions and external stages generate outbound network traffic from Snowflake to a cloud platform. For increased security, you can create private endpoints in Snowflake to access the cloud platform using the platform’s private connectivity solution rather than traversing the public Internet. This lets you access cloud platform services privately and securely from Snowflake.

Outbound private connectivity is available for the following Snowflake features:

Outbound private connectivity costs

You pay for each private connectivity endpoint along with total data processed. For pricing of these items, see the Snowflake Service Consumption Table.

You can explore the cost of these items by filtering on the following service types when querying billing views in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas:

  • OUTBOUND_PRIVATELINK_ENDPOINT

  • OUTBOUND_PRIVATELINK_DATA_PROCESSED

For example, you can query the USAGE_IN_CURRENCY_DAILY view and filter on these service types.

Basic workflow

Each Snowflake feature that can use outbound private connectivity has its own prerequisites and configuration procedures. However, there are common steps to establish outbound private connectivity.

For example, a Snowflake account administrator (user with the ACCOUNTADMIN role) or a user that has a role with the appropriate privileges can do the following:

  1. Complete any prerequisite configuration for the feature generating outbound network traffic.

  2. In Snowflake, provision a private connectivity endpoint to connect to the cloud platform.

  3. Authorize the private connectivity endpoint.

  4. Retrieve the private connectivity endpoint URL that points to the service or resource.

  5. Integrate the private connectivity endpoint URL into the Snowflake configuration of your Snowflake feature.

  6. Deprovision private connectivity endpoints that are not actively being used to avoid cloud platform limitations.

Tip

These steps are self-service but might require collaboration with different parties to complete the setup. Consult with the administrators that own the different services before starting.

The placement of these steps depends on the Snowflake feature. For details, refer to the configuration procedure for feature.

Scaling considerations

Your implementation of outbound private connectivity must conform to the following limitations associated with cloud providers:

Cannot have more than five private endpoints per Snowflake account

Private endpoints that have been deprovisioned within the last seven days count toward this limit.

To increase this limit, contact Snowflake Support.

Cannot have more than one endpoint to the same AWS service or Azure subresource

For AWS, this limitation is per service. So if you have one endpoint to an S3 bucket, you cannot have a different endpont to another S3 bucket because the endpoint-to-S3 service combination would be duplicated.

For Azure, if a resource has only one subresource, you can only have one endpoint. But if the resource has different subresources available, you can have multiple endpoints to the resource as long as they connect to different subresources.

Note

You can duplicate an endpoint-to-service or endpoint-to-subresource combination in a different Snowflake account.

To external network locations

You can use outbound private connectivity to reach external network locations from Snowpark Container services or from UDF/UDTF and stored procedures within Snowpark.

From Snowpark
From Snowpark Container Services

To external functions

To external stages for bulk loading and Snowpipe automation

To external volumes for Iceberg tables

Language: English