By default, a Snowflake account accepts connections from anywhere on the internet that has valid credentials. For many organizations that's too open - you want logins to come only from the corporate VPN, a set of office IP ranges, or a specific cloud service. Network rules and network policies are how Snowflake restricts where connections are allowed from, turning "anyone with a password" into "anyone with a password, from an approved location."

Network rules vs. network policies

The two work together. A network rule is a reusable object that defines a group of identifiers - IPv4 ranges in CIDR notation, private cloud endpoints, or other categories - and whether they're being used for ingress or for internal-stage access. A network policy ties those rules together into an allow/block decision and is what you actually attach to an account or a user.

-- A rule listing approved office and VPN ranges
CREATE NETWORK RULE corp_ingress
  MODE = INGRESS
  TYPE = IPV4
  VALUE_LIST = ('203.0.113.0/24', '198.51.100.10');

-- A policy that allows that rule and blocks one bad actor
CREATE NETWORK POLICY corp_access
  ALLOWED_NETWORK_RULE_LIST = ('corp_ingress')
  BLOCKED_IP_LIST = ('192.0.2.55');

Allow lists, block lists, and precedence

A policy can carry both an allowed list and a blocked list. The blocked list always wins: if an address appears in both, the connection is rejected. If you set an allowed list, everything not in it is implicitly denied - which is the safer posture for production accounts. Leave the allowed list empty and only block, and you're running an open-by-default account with a few exceptions, which is rarely what you want for sensitive data.

Applying a policy: account vs. user

A network policy can be attached at two levels. At the account level it governs every connection to the account. At the user level it governs a single user and overrides the account policy for that user - useful for a service account that connects from a fixed integration IP while human users come through the VPN. The order of evaluation matters: a user-level policy takes precedence over the account-level one for that user.

ALTER ACCOUNT SET NETWORK_POLICY = corp_access;
ALTER USER etl_service SET NETWORK_POLICY = integration_only;

The lockout trap

The classic mistake is activating an account-level policy whose allowed list doesn't include your own current IP - which locks everyone out, including the admin who set it. Snowflake guards against this by checking that the activating session's IP is permitted, but it's still worth confirming your range is in the allowed list before applying, and keeping an ACCOUNTADMIN path that you know is covered. Network policies also integrate with private connectivity (AWS PrivateLink, Azure Private Link, Google Private Service Connect), so connections can be restricted to a private endpoint rather than any public IP at all.

Frequently asked questions

What is the difference between a network rule and a network policy? A network rule defines a group of identifiers (IP ranges, private endpoints); a network policy combines rules into an allow/block decision and is what you attach to an account or user.

What happens if an IP is in both the allowed and blocked lists? The blocked list wins - the connection is rejected.

Can different users have different network restrictions? Yes. A user-level network policy overrides the account-level policy for that user, which is how you let a service account connect from a fixed IP while humans come through the VPN.

How do I avoid locking myself out? Confirm your current IP is in the allowed list before activating an account-level policy; Snowflake also blocks an activation that would exclude the activating session's own address.