Network Security and Connectivity
How clients reach Snowflake
Connections use the Snowflake service endpoint over TLS. Network policies define allowed and blocked IP ranges (IPv4) at the account or user level, and can be scoped to specific services. Private connectivity options include AWS PrivateLink, Azure Private Link, and GCP Private Service Connect, which keep traffic off the public internet. SnowCD and connectivity diagnostics help troubleshoot blocked endpoints.
Ingress vs. egress
Distinguish ingress (clients to Snowflake) from egress controls for external network access: an integration object plus a network rule governs outbound calls from Snowpark or external functions. Questions often blur these - a network policy does not authorize outbound calls; a network rule and integration do.
Federated and private auth interplay
Private connectivity is frequently paired with SAML SSO and key-pair auth for service accounts. Snowflake Partner Connect and drivers (JDBC/ODBC/Python) still respect network policies.
Traps
- Assuming a network policy blocks a user already connected - policies apply at connection time; existing sessions may persist depending on configuration.
- Confusing network rules (used by external access and other features) with network policies (IP allow/block lists).
- Forgetting that private connectivity requires configuration on both the Snowflake side and the cloud provider side.
- Believing TLS alone satisfies private-connectivity requirements.
Rule of thumb
For regulated workloads, combine a restrictive network policy (allow only known CIDRs) with private connectivity, and use key-pair auth for automated clients. For outbound access from Snowpark, create a network rule and an external access integration - never rely on a network policy for egress.