What you will be able to do
- Authorize and verify private connectivity on AWS, Azure and Google Cloud with the SYSTEM$ privatelink functions
- Diagnose common private connectivity failures in DNS, firewall rules, expired tokens and endpoint approval
- Design network policies that allow private endpoints, block public traffic and work across clouds
1.Enabling private connectivity on each cloud
By default, clients reach Snowflake over the public internet. Private connectivity instead routes traffic from your VPC or VNet over a private IP address to Snowflake, using the cloud provider's own service: AWS PrivateLink, Azure Private Link or Google Cloud Private Service Connect. It controls inbound traffic only. Private endpoints can serve the service, Snowsight, internal stages and Snowflake-managed storage volumes. These sources cover only those Snowflake-hosted storage paths. They do not cover private connectivity for customer-owned storage integrations.
On every cloud, enablement uses the same three ACCOUNTADMIN functions. SYSTEM$GET_PRIVATELINK_CONFIG returns the values to build your endpoint from: privatelink-vpce-id on AWS and privatelink-pls-id on Azure. SYSTEM$AUTHORIZE_PRIVATELINK enables the account. SYSTEM$GET_PRIVATELINK, called with the same arguments, verifies it and returns "Account is authorized for PrivateLink." SYSTEM$REVOKE_PRIVATELINK disables it. Only the arguments differ by cloud.
On Google Cloud, you build the endpoint with gcloud. You reserve a virtual IP in your subnet and create a forwarding rule to Snowflake's service attachment. Traffic flows one way, from your VPC to Snowflake. PSC allows at most 10 connections per project and 50 per account.
| Cloud | Arguments | Where the token comes from |
|---|---|---|
| AWS | '<aws_id>', '<federated_token>' | aws sts get-federation-token --name sam |
| Azure | '<private-endpoint-resource-id>', '<federated_token>' | az account get-access-token --subscription <SubscriptionID> |
| GCP | '<gcp_project_id>', '<access_token>' | gcloud auth print-access-token |
Checkpoint 1 of 6· Put it in order
Put the high-level Azure Private Link steps in order
- 1.Update outbound firewall settings and DNS for the account and OCSP URLs
- 2.Enable the Snowflake account with SYSTEM$AUTHORIZE_PRIVATELINK
- 3.Generate and retrieve an access token from your Azure subscription
- 4.Once the endpoint shows Approved, test with SnowCD and SYSTEM$ALLOWLIST_PRIVATELINK
- 5.Create a Private Endpoint
The endpoint has to exist before you can authorize it. Authorization moves the endpoint from Pending to Approved, and you test only after approval.
“After the Private Endpoint displays a CONNECTION STATE value of Approved, test your connection to Snowflake with SnowCD”Source: docs.snowflake.com
Checkpoint 2 of 6· Exam question
A network policy lists rule `corp_allowed` (TYPE IPV4, MODE INGRESS, `10.20.0.0/16`) in `ALLOWED_NETWORK_RULE_LIST` and rule `quarantine` (TYPE IPV4, MODE INGRESS, `10.20.5.0/24`) in `BLOCKED_NETWORK_RULE_LIST`. A user connects from 10.20.5.9. What is the outcome?
Correct answer: C — The connection is denied, because the address matches the blocked rule and Snowflake applies blocked values before allowed values.
- A. Incorrect: blocked values are not skipped once an allowed rule matches.
- B. Incorrect: the blocked list is independent of the allowed ranges and is not limited to addresses outside them.
- C. Correct: when an address matches both lists, the blocked entry wins, so a narrow quarantine range can be carved out of a wide allowed range.
- D. Incorrect: no repetition is needed; the blocked list takes effect on its own.
2.Troubleshooting private connectivity
Most failures fall into a few places.
Tokens: an AWS federated token expires after 12 hours, and a Google Cloud access token after 1 hour by default. If you authorize, verify or revoke after expiry, generate a new token first. On Azure, the user generating the token needs Read permission on the subscription.
Endpoint state: a new Azure private endpoint shows Pending until SYSTEM$AUTHORIZE_PRIVATELINK completes, then Approved. If Azure rejects the privatelink-pls-id alias, ask Snowflake Support for the resource ID and use that instead.
DNS: CNAME (AWS) or DNS records (Azure) must map the SYSTEM$GET_PRIVATELINK_CONFIG URLs to your endpoint, and they must resolve to private addresses. A record that resolves to a public IP is misconfigured.
Firewalls: on AWS, the security group must allow ports 443 and 80 to the VPCE CIDR. On Azure, the endpoint's network security group must allow TCP 443 and 80. When you update client drivers, also allow the OCSP host name.
Diagnosis: SYSTEM$ALLOWLIST_PRIVATELINK lists the private hosts and ports. Feed its output to SnowCD to test the path.
For problems inside your own VPC, security group or DNS setup, Snowflake points you to AWS or Microsoft Support. Once the connection works, Snowflake recommends pinning private endpoints to harden the account further.
Checkpoint 3 of 6· Check yourself
After AWS PrivateLink is authorized, clients in the VPC still reach Snowflake over the internet. nslookup on the privatelink account URL returns a public address. What is the most likely cause?
The private connectivity URLs must resolve to the VPC endpoint's private IPs. A public answer means traffic never enters the endpoint. An expired token affects only the authorization functions, and cross-region endpoints are supported.
“Your DNS record must resolve to private IP addresses within your VPC.”Source: docs.snowflake.com
Checkpoint 4 of 6· Check yourself
Which pairing gives you the private host list and a way to test it end to end?
SYSTEM$ALLOWLIST_PRIVATELINK returns the private host names and ports, and its output is passed to SnowCD for diagnosis. SYSTEM$GET_PRIVATELINK only confirms authorization.
“The output of this function can then be passed into SnowCD to diagnose and troubleshoot your network connection to Snowflake.”Source: docs.snowflake.com
3.Enforcing private-only access across clouds
Private connectivity on its own does not close the public path. A rule built on private endpoint IDs has no effect on public traffic, so a private-only policy needs two rules: the endpoint rule on the allowed list and an IPV4 0.0.0.0/0 rule on the blocked list. For a request that arrives over private connectivity, an allowed AWSVPCEID or AZURELINKID rule takes precedence, and the policy's IPV4 and IPV6 rules are ignored.
CREATE NETWORK RULE block_public_access
MODE = INGRESS
TYPE = IPV4
VALUE_LIST = ('0.0.0.0/0');
CREATE NETWORK RULE allow_vpceid_access
MODE = INGRESS
TYPE = AWSVPCEID
VALUE_LIST = ('vpce-0fa383eb170331202');
CREATE NETWORK POLICY allow_vpceid_block_public_policy
ALLOWED_NETWORK_RULE_LIST = ('allow_vpceid_access')
BLOCKED_NETWORK_RULE_LIST=('block_public_access');With accounts on several clouds, you apply the same pattern in each one, but the identifiers and the stage controls differ.
Identifiers: AWS uses the VPCE ID. Azure uses the LinkID, which you get from SYSTEM$GET_PRIVATELINK_AUTHORIZED_ENDPOINTS. Google Cloud uses the pscConnectionID, which you get from gcloud compute forwarding-rules describe.
Shared endpoints: when several VPCs, VNets or business units share one endpoint or transit gateway, use the tuple syntax {private_link_id:ip_or_cidr}. Snowflake then evaluates the endpoint ID and the private IP together, which also handles overlapping private ranges.
Internal stages: on AWS you use network rules, as on the previous page. On Azure, you can only block all public access. On Google Cloud, call SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS. It is not a network policy, and it blocks every public IP.
IPv6 rules exist only on AWS.
Checkpoint 5 of 6· Match them up
Match each cloud's private endpoint rule TYPE to how you obtain its identifier
Tap a term, then the definition that fits it.
Each cloud names its endpoint differently, so a multi-cloud design needs a cloud-specific rule TYPE in each account's policy.
“Execute the SYSTEM$GET_PRIVATELINK_AUTHORIZED_ENDPOINTS function to retrieve the LinkID associated with an account.”Source: docs.snowflake.com
Checkpoint 6 of 6· Exam question
Which statement correctly describes network rule modes when building a network policy that restricts who can connect to the Snowflake service?
Correct answer: A — Ingress-mode rules restrict access to the service, while egress-mode rules serve external network access and are invalid in a network policy.
- A. Correct: network policies take INGRESS rules (and INTERNAL_STAGE rules for stages); EGRESS rules belong to external access integrations.
- B. Incorrect: the directions are reversed; ingress controls traffic arriving at Snowflake.
- C. Incorrect: INGRESS is the default mode, and internal stage mode applies to AWS only.
- D. Incorrect: the mode determines how a rule is used, and egress rules cannot be placed in a policy.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Putting an AWSVPCEID rule on the allowed list makes the account private-only, because all public traffic is then blocked.Why is that wrong?
Private endpoint rules have no effect on requests from the public network. To block public traffic, you also need an IPV4 0.0.0.0/0 rule on the blocked list.
Covered in Enforcing private-only access across clouds
2.On Google Cloud, a network policy blocks public access to the internal stage.Why is that wrong?
Google Cloud internal stages are closed to the public with SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS, which blocks every public IP. A network policy does not do this.
Covered in Enforcing private-only access across clouds
Practise it for real
Lock an AWS-hosted account down to its PrivateLink endpoint after verifying the private path
1.As ACCOUNTADMIN, call SYSTEM$GET_PRIVATELINK with the same aws_id and federated token you used to authorize
Why: Confirm the account is authorized before you remove the public path
You should see: Account is authorized for PrivateLink.
2.Run SYSTEM$ALLOWLIST_PRIVATELINK and pass its output to SnowCD from a client inside the VPC
Why: Prove that DNS and firewall rules route through the endpoint
You should see: SnowCD reports the private hosts as reachable
3.Create block_public_access (IPV4, 0.0.0.0/0) and allow_vpceid_access (AWSVPCEID with your VPCE ID), then create allow_vpceid_block_public_policy
Why: The VPCE rule does not affect public traffic, so public traffic has to be blocked separately
You should see: Both rules appear in SHOW NETWORK RULES and the policy is created, but nothing is enforced yet
4.Activate it with ALTER ACCOUNT SET NETWORK_POLICY
Why: A policy restricts nothing until it is activated
You should see: Connections through the VPC endpoint succeed and connections from public IPs are denied
Stuck? Get a nudge
If you lock yourself out, remember that only Snowflake Support can set MINS_TO_BYPASS_NETWORK_POLICY. Test from the private path before you activate the policy on the account.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“These connections use AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect.”
↩︎ Enabling private connectivity on each cloud - 2.
“SYSTEM$GET_PRIVATELINK returns Account is authorized for PrivateLink.”
↩︎ Enabling private connectivity on each cloud“The federated token expires after 12 hours.”
↩︎ Troubleshooting private connectivity“When updating client drivers and using OCSP with PrivateLink, update the firewall rules to allow the OCSP host name.”
↩︎ Troubleshooting private connectivity“authorize a security group of services that connect the Snowflake outgoing connection to port 443 and 80 of the VPCE CIDR”
↩︎ Troubleshooting private connectivity“Your DNS record must resolve to private IP addresses within your VPC.”
↩︎ Checkpoint - 3.
“Maximum 10 connections per project.”
↩︎ Enabling private connectivity on each cloud“By default, the token expires after 1 hour.”
↩︎ Troubleshooting private connectivity - 4.
“If you receive an error message regarding the alias value, contact Snowflake Support to receive the resource ID value”
↩︎ Troubleshooting private connectivity“After the Private Endpoint displays a CONNECTION STATE value of Approved, test your connection to Snowflake with SnowCD”
↩︎ Checkpoint - 5.
“then all IPV4 and IPV6 network rules that contain public or private IP ranges are ignored”
↩︎ Enforcing private-only access across clouds“has no effect on requests coming from the public network”
↩︎ Exam trap 1“has no effect on requests coming from the public network”
↩︎ Prediction - 6.
“Snowflake evaluates the combination of the PrivateLink ID and private IP, not the IP alone, to allow or block traffic”
↩︎ Enforcing private-only access across clouds“Run the gcloud compute forwarding-rules describe command to get the pscConnectionID for each forwarding rule.”
↩︎ Enforcing private-only access across clouds“Execute the SYSTEM$GET_PRIVATELINK_AUTHORIZED_ENDPOINTS function to retrieve the LinkID associated with an account.”
↩︎ Checkpoint
Also cited
“You use the SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS function, not a network policy, to block requests to an internal stage.”
↩︎ Exam trap 2“The output of this function can then be passed into SnowCD to diagnose and troubleshoot your network connection to Snowflake.”
↩︎ Checkpoint