Snowflake PrivateLink 连接：账户授权、端点绑定与网络策略

Private connectivity is often discussed as though it were a single control. In practice, a Snowflake deployment can involve several distinct controls: AWS account authorization, endpoint-specific pinning, network-policy allowlisting, and Snowflake authentication. This article focuses on inbound AWS PrivateLink connectivity to the Snowflake service.

Understanding the difference matters when a customer asks questions such as:

• Can a specific AWS account create more than one PrivateLink endpoint?
• Does authorizing an AWS account automatically pin one endpoint?
• Does a successful TLS connection prove that the endpoint is permitted?
• Can Snowflake cap the number of VPCEs a customer creates?

The short answer is:

• VPCE account pinning is supported where inbound private connectivity and endpoint pinning are available.
• AWS account authorization and VPCE pinning are different operations.
• Network policies provide the account-side control for allowing specific VPCE IDs.
• AWS PrivateLink does not provide a normal configurable provider-side quota that limits the number of VPCEs created by one consumer AWS account.

Reading the Architecture Diagram

The diagram has two layers: the traffic path and the control plane.

Traffic path

Customer workload → customer VPC interface endpoint (VPCE) → AWS PrivateLink endpoint service → Snowflake-managed network load balancer and service edge → target Snowflake account.

The network load balancer provides the service transport on Snowflake’s side. It is Snowflake-managed infrastructure, not a customer-configured authorization gate.

Control plane

Gate 1 — Authorize the customer AWS account. The customer authorizes one or more AWS accounts to establish private connectivity using the Snowflake PrivateLink service endpoint. After authorization, those AWS accounts can create interface VPC endpoints in their VPCs that target Snowflake’s PrivateLink endpoint service.

Gate 2 — Pin the VPC interface endpoint to a Snowflake account. After creating a VPC interface endpoint, the customer registers its VPCE ID with the specific Snowflake account it is intended to access. If the pinned VPCE is used to reach a Snowflake account that has not also registered that VPCE, Snowflake will reject the request with 390431: Fail : Blocked by pinned private link endpoint.

Gate 3 — Apply a network-policy allowlist. The Snowflake account can attach an ingress network rule with TYPE = AWSVPCEID to a network policy. The rule lists the VPCE IDs permitted to access the account. A request from a VPCE that does not match the allowed rule will be blocked with 390422: INCOMING_REQUEST_BLOCKED.

These controls operate on different parts of the connection: AWS account authorization enables service access, endpoint pinning binds a VPCE to a registered target account, and the network policy restricts which VPCE IDs may enter the account.

The Three PrivateLink Controls

1. AWS account authorization

Snowflake’s SYSTEM$AUTHORIZE_PRIVATELINK function enables private connectivity to the Snowflake service for the current account using the customer’s AWS account identity and a scoped token.

A representative form is:

USE ROLE ACCOUNTADMIN;

SELECT SYSTEM$AUTHORIZE_PRIVATELINK(
    '<12-digit-aws-account-id>',----------Your AWS Account Id
    '<federated-token>' ------------------STS Token generated from your AWS Account
);

This is an AWS-account-level authorization step. It does not mean that only one VPCE can be created, and it does not identify one specific VPCE as the only endpoint allowed to access the account.

NOTE: STS token generation is done in your AWS account, please consult your AWS admin for guidance or help.

To list the AWS accounts currently authorized for PrivateLink in Snowflake, use:

SELECT SYSTEM$GET_PRIVATELINK_AUTHORIZED_ENDPOINTS();

This returns the AWS account authorization records, including the AWS account ID authorized for PrivateLink.

2. VPCE account pinning

Endpoint pinning binds a particular VPC interface endpoint to a Snowflake account for inbound access. For AWS, that endpoint is identified by its VPCE ID.

A representative registration is:

USE ROLE ACCOUNTADMIN;

SELECT SYSTEM$REGISTER_PRIVATELINK_ENDPOINT(
    '<vpce-id>',----------------------------Your VPC Endpoint Id
    '<12-digit-aws-account-id>',------------Your AWS Account Id
    '<scoped-federated-token>',-------------Your AWS Account STS Token
    0
);

The fourth argument is the optional delay_time, specified in minutes. A value of 0 means that the endpoint registration is enforced immediately. Use 0 when the VPCE, DNS path, and Snowflake account mapping are ready and the pinning control should take effect without a transition period.

A value from 1 through 1440 delays enforcement for that many minutes, up to 24 hours. A delay can provide time to validate the endpoint and update dependent configurations before the pinning rule becomes active. For example, 60 provides a one-hour transition window; it does not disable pinning or make the endpoint less restrictive after enforcement begins.

NOTE: Use a separately scoped token for endpoint registration; do not reuse the token used for SYSTEM$AUTHORIZE_PRIVATELINK.

Registrations can be validated with:

SELECT SYSTEM$GET_PRIVATELINK_ENDPOINT_REGISTRATIONS();

The same VPCE can be registered to multiple Snowflake accounts. The request is allowed only when the target account has also registered that VPCE.

Note: The VPCE ID pinning described in this article is currently available only for AWS PrivateLink and Azure LinkIds. The examples use AWS VPCE IDs; GCP Private Service Connect uses different endpoint types and identifiers and is not supported at the time of this writing.

3. Network-policy allowlisting

Network-policy allowlisting: Snowflake account → permitted VPCEs

If the requirement is to allow only specific VPCEs to access a Snowflake account, configure an ingress network rule using AWSVPCEID and attach it to a network policy.

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE NETWORK RULE ALLOW_PRIVATE_ENDPOINTS
  MODE = INGRESS
  TYPE = AWSVPCEID
  VALUE_LIST = ('<approved-vpce-id>');---------Your VPC Endpoint Id

CREATE OR REPLACE NETWORK POLICY PRIVATE_ENDPOINT_POLICY
  ALLOWED_NETWORK_RULE_LIST = ('ALLOW_PRIVATE_ENDPOINTS');

ALTER ACCOUNT SET NETWORK_POLICY = PRIVATE_ENDPOINT_POLICY;

This is the account-side access-control layer. The policy should be checked together with its scope and any other network rules. If the requirement is to authorize specific PrivateLink endpoints, an AWSVPCEID rule is more precise than relying only on a broad IPv4/CIDR rule.

For private-connectivity requests, an AWSVPCEID network rule takes precedence over IPv4 and IPv6 network rules. Because ALTER ACCOUNT SET NETWORK_POLICY activates the policy, merge this rule with the existing policy and verify the current access path before applying it.

Snowflake Authentication Versus Network Reachability

A DNS response, TCP connection, TLS handshake, or HTTP response is not the same as a successful Snowflake login.

For example, this test is useful for validating network reachability:

curl -vkI https://<account>.us-east-1.privatelink.snowflakecomputing.com/

A successful TLS handshake or an HTTP 302 redirect to /console shows that the request reached the Snowflake frontend. The -k option in the example disables certificate validation, so use it only as a connectivity diagnostic—not as proof of certificate trust. The request still does not prove that:

• The Snowflake credentials were accepted;
• A Snowflake session was created;
• A query can execute;
• The account-side network policy accepted the request; or
• The intended VPCE was the source of the request.

The decisive validation is an actual Snowflake client login followed by a query such as:

SELECT
    CURRENT_ACCOUNT(),
    CURRENT_USER(),
    CURRENT_REGION();

Common Misconceptions and Error Interpretation

Can Snowflake cap the number of VPCEs per customer AWS account?

The practical answer is no — not as a normal customer-configurable PrivateLink service setting.

Snowflake and AWS can authorize an AWS account, accept or reject endpoint connections, pin individual endpoints, and restrict account access with network policies. Those controls are not equivalent to a hard quota on the number of VPCEs one AWS account can create or maintain.

Common Outcomes

1. Service endpoint provisioning fails

Private Endpoint provisioning in your VPC whose AWS account that has not been authorized in Snowflake, fails with “Service Name Could Not Be Verified”

2. TLS succeeds, but no Snowflake login is proven

This demonstrates private-path and frontend reachability only. Continue with an authenticated client test.

3. A second VPCE reaches the same Snowflake account

This does not show that Snowflake lacks endpoint pinning. It may mean that:

• AWS account authorization permits the customer account to create or connect another endpoint;
• No AWSVPCEID network-policy restriction is attached;
• The test reached only the frontend and did not authenticate; or
• The test occurred before the pinning enforcement timestamp.

4. Error 390431: Fail : Blocked by pinned private link endpoint

This is a pinning relationship failure: the VPCE/account combination was rejected because the target account had not registered that VPCE.

5. Error 390422: INCOMING_REQUEST_BLOCKED

This indicates an incoming request was blocked, but the exact cause should be correlated with the effective network policy, endpoint identifier, and ingress history. Do not attribute it to pinning without checking those fields.

SELECT
    event_timestamp,
    user_name,
    is_success,
    client_ip,
    client_private_link_id,
    error_code,
    error_message
FROM snowflake.account_usage.login_history
WHERE event_timestamp >= DATEADD('hour', -12, CURRENT_TIMESTAMP())
ORDER BY event_timestamp DESC;

Conclusion

Secure inbound AWS PrivateLink uses three complementary controls: AWS account authorization establishes service access, VPCE pinning binds an endpoint to each Snowflake account that registers it, and an AWSVPCEID network policy restricts which endpoint IDs may access the account. Network reachability must still be validated separately from Snowflake authentication.

Disclaimer: This post reflects the author’s personal views and not an official Snowflake publication, statement, recommendation, or position.

Public References

Snowflake: AWS PrivateLink and Snowflake

Snowflake: Pinning private connectivity endpoints for inbound traffic

Snowflake: SYSTEM$AUTHORIZE_PRIVATELINK

Snowflake: SYSTEM$REGISTER_PRIVATELINK_ENDPOINT

Snowflake: Network rules

Snowflake: Network policies

AWS: Configure an endpoint service

Snowflake PrivateLink Connectivity: Account Authorization, Endpoint Pinning, and Network Policies was originally published in Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.