Azure access: New VNET subnet IDs required for rules that filter based on subnet ID (Pending)¶
This behavior change applies only to customers who use Azure Virtual Network (VNet) subnet IDs in virtual network, policy, or firewall rules that filter traffic in Azure regions. If you don’t use the VNET subnet IDs feature offered in Snowflake Azure deployments, you can ignore this change.
Snowflake is expanding its support to include additional Azure VNet subnet IDs in some regions. We are doing this by setting up additional subnets and migrating customers to them after verifying readiness. We are verifying that customers have updated their subnet IDs before migrating them. We are doing this verification and migration through dedicated engagement with customers.
However, if you try to update your subnet IDs in these regions, you might encounter an error similar to vnet-******** cannot have more than 200 tagged traffic consumers of service. This is because, per Azure limits, a virtual network can be associated with a maximum of 200 different subscriptions and regions per supported service. This means that Snowflake customers can use a subnet ID queried from the SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO function in 200 Azure subscription/region combinations in aggregate. After a total of 200 subscriptions across all customers have used the subnet ID in a network rule, new attempts to use the subnet ID for another Azure subscription will fail.
To avoid encountering these errors, consider taking the following actions:
If you are already a Business Critical customer, consider using Private connectivity for outbound network traffic.
If you have an Azure Blob Storage account that has allowlisted Snowflake subnets in the firewall, you can use the same subscription and region to create a new storage account. You can then allowlist Snowflake subnets on this new storage account.
Consider not Allowing VNET subnet IDs. For more detailed information, see Network security for Azure Key Vault in Azure documentation.
Ref: 1995, 2078