Modernizing Network Security for Snowflake on Azure
As Snowflake deepens its integration with Azure’s cloud-native security framework, customers are adopting more dynamic, policy-driven approaches to managing connectivity. We recommend and will soon require migrating from traditional subnet allowlisting to Azure Network Security Perimeter (NSP).
This post walks through why subnet-based allowlisting is reaching its limits, how NSP enhances network trust by providing centralized firewall for PaaS resources in Snowflake customers’ Azure accounts, and provides an overview to help Azure Snowflake customers modernize their access model.
The limits of subnet allowlisting
Subnet allowlisting has long been the default way for Azure customers to control access to Snowflake.
In this model, customers specify trusted resource identifiers — typically the subnets of Azure VNets owned by Snowflake — that are permitted to reach their Azure account.
While straightforward, this model introduces scaling and governance challenges:
Static configuration: IP ranges change as Azure networks evolve, requiring constant manual updates.
Overly broad trust: All traffic from a subnet is treated as equally trusted, regardless of workload identity or sensitivity.
Limited visibility: There is no native telemetry for determining which Azure resources initiated Snowflake connections.
Operational complexity: Multiregion or multisubscription architectures require duplicated, error-prone configuration.
As data platforms expand, subnet allowlisting becomes a barrier to automation and continuous deployment.
Before vs. after: From subnet lists to perimeters
| Traditional subnet allowlisting | Modern NSP-based architecture |
|---|---|
| Trust based on IP ranges or subnets | Trust defined by resource-level perimeters |
| Manual updates when networks change | Dynamic updates as Azure resources evolve |
| Coarse-grained trust — any subnet member allowed | Fine-grained, policy-driven trust boundaries |
| Limited observability and policy audit | Integrated monitoring via Azure Policy and Azure Monitor |
| Snowflake Network Policy manually maintained | Trust enforced automatically via NSP membership |
Using Azure Network Security Perimeter (NSP)
Azure Network Security Perimeter (NSP) provides a logical, resource-based security boundary for Azure resources. Rather than relying on static IP addresses, NSPs define perimeters that explicitly specify which Azure resources can communicate.
Key benefits for Snowflake deployments
Policy-driven trust: Define trusted boundaries around workloads and Snowflake endpoints.
Dynamic updates: Azure automatically handles IP and subnet changes.
Enhanced visibility: Centralized perimeter access logs and insights for auditability.
Seamless with Private Link: Works natively with Snowflake Private Link endpoints.
Zero trust alignment: Access decisions are based on policy, not location.
Validation Checklist
- Test from inside the perimeter: From an Azure resource such as Key Vaults, SQL DB, Cosmos DB, Event Hubs, Azure Monitor, AI Search and AI Foundry within the NSP, resolve and connect to your Snowflake hostname:
nslookup <account>.<region>.snowflakecomputing.com
2. Verify that this returns a publicly routable IP address from the endpoint. (Note: It would return a private IP if you tested with a Private Link hostname)
3. Test access from outside the perimeter: The connection should fail — confirming NSP enforcement.
4. Monitor access patterns using Azure monitor diagnostics on NSP: Use Azure Monitor for NSP to get visibility 360 access to resources in the perimeter.
Migration path: From IP Lists to NSP
Audit existing Snowflake allowlists: Identify all subnet and IP-based rules on resource firewalls currently in place. (See Snowflake Network Policies Documentation)
Define perimeters: Group related workloads (for example, “Analytics Perimeter” or “Data Ingestion Perimeter”).
Enable Private Link: Refer to Snowflake Private Link Setup Guide.
Create NSP associations: Bind your Snowflake endpoint and trusted resources within the same perimeter.
- Validate and deprecate old allowlists: Once testing completes, remove static subnet rules from Snowflake’s network policies. Use NSP access logs to verify if access is permitted using an NSP access rule prior to turning on enforcement.
Summary
Azure Network Security Perimeter represents a major evolution in how customers can securely manage access to Snowflake.
Using network security perimeters, users can centrally define network isolation trust boundaries for resource instances that need to be protected by the perimeter. This enables:
Simplified network governance
Dynamic, policy-based security
Rich telemetry and auditing
Seamless alignment with zero trust principles
As enterprises modernize their Azure data platforms, migrating from subnet allowlisting to NSP offers stronger security, reduced operational complexity and better scalability for future workloads.
To learn more about Azure Network Security feature and other Snowflake relevant networking features, watch the demo in "Enabling the next wave of cloud transformation with Azure Networking" from Microsoft Ignite 2025.
References
Azure Documentation:
Snowflake Documentation:
Authors
