PrivateLink Works, But Queries Time Out
A financial firm connects its VPC to Snowflake via AWS PrivateLink. SYSTEM$WHITELIST shows the private endpoint registered, and SELECT CURRENT_REGION() succeeds from an EC2 instance in the VPC. However, a new application subnet in a different AZ cannot connect: TCP 443 to the private endpoint IP times out. The network team confirms the endpoint ENIs exist in three AZs, but the new subnet's route table sends 0.0.0.0/0 to a NAT gateway and has no route to the endpoint ENI. Separately, the security team wants to enforce that only the private endpoint can reach the account, blocking public internet access entirely.
1. Diagnose the connectivity failure and explain why `SYSTEM$WHITELIST` showing the endpoint is not evidence that this subnet can connect.
Read the worked answer
SYSTEM$WHITELIST confirms the account-level association between the Snowflake account and the PrivateLink endpoint - it proves the endpoint is authorized, not that any given subnet can route to it. The failing subnet's route table has no route to the endpoint ENI; its default route points to a NAT gateway, which does not provide a path to the PrivateLink endpoint (traffic would hairpin to the internet and be dropped/blocked). Fix: add a route in the new subnet's route table for the endpoint's ENI IPs (or the endpoint's service CIDR) to the endpoint, or place the workload in a subnet whose route table already has that path. The successful CURRENT_REGION() call came from a different subnet that does have the route, which is why the endpoint 'looks fine.' The lesson: PrivateLink is an account-level authorization plus a per-subnet routing requirement; both must hold.
2. Describe how to enforce that only the private endpoint can reach the account, and note one operational risk of doing so.
Read the worked answer
Use network policies: create a network policy that allows only the PrivateLink endpoint(s) (by VPCE ID / private endpoint identifier) and set it as the account-level policy, or attach it to the relevant users. This blocks public internet access at the Snowflake side regardless of what the client network allows. Operational risk: if the policy is applied account-wide before all workloads are migrated, any client still connecting over the public internet (BI tools, ad-hoc users, CI runners) is immediately cut off. Mitigation: stage the policy on a test user first, inventory all connection paths, then roll out; keep a break-glass path documented. Also ensure the policy references the correct endpoint IDs - a typo silently locks out legitimate private traffic.