Use Snowflake Network Identifiers in Azure allowlists for Azure Storage and Azure Key Vault (August 2026) (Pending)

This unbundled behavior change affects your account if you use Azure policy or firewall rules based on subnet IDs for Azure Storage (https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security) or Azure Key Vault (https://learn.microsoft.com/en-us/azure/key-vault/general/network-security) that interface with Snowflake. If you’re unsure whether this change applies, use the Azure Resource Graph validation described later in this topic.

Starting August 20, 2026, Snowflake is launching a set of Snowflake Network Identifiers, which are published IP prefixes that you can use to allowlist traffic from Snowflake networks to your Azure PaaS resources such as Storage and Azure Key Vault. You need to update storage firewall rules or Azure Network Security Perimeter (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-concepts) access rules to include the Snowflake Network Identifiers, while retaining existing subnet ID allowlisting. This lets Snowflake scale the underlying infrastructure in these regions without requiring you to update subnet ID-based allowlists in the future.

Snowflake strongly encourages adoption of Azure’s Network Security Perimeter (NSP) as a future-proof solution for managing your PaaS perimeter. Future Snowflake features will require NSP adoption. To use Snowflake Network Identifiers as the allowlist parameter:

  • On Azure Key Vault: Because of platform restrictions, adoption of Snowflake Network Identifiers for Azure Key Vault requires migration to NSP.
  • On Azure Storage: For storage access, adopt NSP where possible, but you can fall back to the existing storage firewall to bridge the time between this behavior change and an NSP migration.

Important

Customers who require Azure Key Vault access and can’t migrate to NSP on the timeline of this behavior change should open a support ticket with Snowflake to request an extension.

Switching to Snowflake Network Identifiers maintains your security posture. All traffic from Snowflake to your storage accounts and Key Vaults still uses Azure service endpoints (https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview) and traverses only over the Azure backbone.

This is an unbundled behavior change. It isn’t part of the regular release cycle and doesn’t have an opt-in or opt-out option. Customers are required to make the change within 90 days, by November 18, 2026.

Get your Snowflake Network Identifiers

For a Snowflake region, run SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES in your Snowflake account. The output resembles the following:

[
  {
    "ipv4_prefix": "153.45.139.0/24",
    "effective": "2026-08-19T00:00:00Z", // Allowlist this IP range before this date
    "published": "2026-07-15T14:38:56.923Z", // This IP range was published on this date, refresh allowlists if updated before this date.
    "expires": "2026-11-19T00:00:00Z",
    "usage": [
      "Network Identifier - use for Azure services such as Storage, Key Vault",
      "Stable Egress IP - use for endpoints hosted outside of Azure"
    ]
  },
  {
    "ipv4_prefix": "153.45.182.0/24",
    "effective": "2026-08-19T00:00:00Z", // Allowlist this IP range before this date
    "published": "2026-07-15T14:38:56.923Z", // This IP range was published on this date, refresh allowlists if updated before this date.
    "expires": "2026-11-19T00:00:00Z",
    "usage": [
      "Network Identifier - use for Azure services such as Storage, Key Vault"
    ]
  }
]

In this output:

  • Allowlist each IP range before its effective date.
  • If an IP range was published after you last refreshed allowlists, refresh them.
  • The usage field marks public IP ranges to use as Snowflake Network Identifiers. Add those ranges to your storage firewalls or Network Security Perimeter access rules.

Allowlist all IP ranges marked for use as Snowflake Network Identifiers. In the example above, add both IP ranges.

Allowlist the Snowflake Network Identifiers for your storage accounts

Provision an Azure Network Security Perimeter (NSP) (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-concepts) with access rules that allowlist the Snowflake Network Identifiers, and associate all relevant storage accounts with it. If you can’t migrate to NSP on the behavior change timeline, you can also add the Snowflake Network Identifiers to existing storage firewalls along with subnet ID allowlists. Until further notice, retain existing subnet IDs, and keep NSP in transition mode with Snowflake subnet IDs allowed outside of NSP in the resource firewall.

1. Collect relevant storage accounts used for external stages and external volumes

Storage accounts used for CREATE STAGE and External volume storage for Apache Iceberg™ tables might have subnet allowlisting in place. The following commands help you find storage accounts, not whether they have subnet-based allowlisting. Use step 2 to determine that.

For a list of all external stages you have access to, run:

SHOW STAGES ->>
  SELECT
    CONCAT_WS('.', "database_name", "schema_name", "name") AS stage_fqn,
    "url",
    "storage_integration"
  FROM $1
  WHERE "type" = 'EXTERNAL' AND "cloud" = 'AZURE';

In the output, the "url" column points to the relevant storage account.

For a list of all external volumes you have access to, run:

SHOW EXTERNAL VOLUMES;

For each external volume, run:

DESC EXTERNAL VOLUME <my_ext_volume> ->>
  SELECT
    TRY_PARSE_JSON("property_value"):STORAGE_BASE_URL::STRING AS STORAGE_BASE_URL,
    TRY_PARSE_JSON("property_value"):STORAGE_PROVIDER::STRING AS PROVIDER
  FROM $1
  WHERE "parent_property" = 'STORAGE_LOCATIONS'
    AND "property" ILIKE 'STORAGE_LOCATION%';

The storage base URL from the query shows the storage account name to check.

2. Optional: Collect storage accounts that use subnet ID or Snowflake Network Identifiers allowlisting

You can use Azure Resource Graph queries (https://learn.microsoft.com/en-us/azure/governance/resource-graph/first-query-portal) in the relevant Azure tenants to get a list of storage accounts that have allowlisted one or more Snowflake subnet IDs. Fetching the list of Snowflake subnet IDs requires the ACCOUNTADMIN role.

  1. Run the following SQL script in your Snowflake account to get an Azure Resource Graph query (https://learn.microsoft.com/en-us/azure/governance/resource-graph/first-query-portal). Copy the output for use in the Azure console or CLI:

    EXECUTE IMMEDIATE $$
DECLARE
  has_aa       BOOLEAN;
  subnet_ids   ARRAY;
  subnet_list  STRING;
  kql          STRING;
BEGIN
  SELECT ARRAY_CONTAINS('ACCOUNTADMIN'::VARIANT,
                        PARSE_JSON(CURRENT_AVAILABLE_ROLES()))
    INTO :has_aa;

  IF (NOT :has_aa) THEN
    RETURN 'You need the ACCOUNTADMIN role to run SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO()';
  END IF;

  USE ROLE ACCOUNTADMIN;

  SELECT PARSE_JSON(SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO())
           :"snowflake-vnet-subnet-id"::ARRAY
    INTO :subnet_ids;

  SELECT LISTAGG('"' || f.value::STRING || '"', ',\n')
    INTO :subnet_list
    FROM TABLE(FLATTEN(input => :subnet_ids)) f;

  SELECT 'resources\n'
      || '| where type =~ "microsoft.storage/storageaccounts"\n'
      || '| mv-expand vnetRule = properties.networkAcls.virtualNetworkRules\n'
      || '| extend subnetId = tostring(vnetRule.id)\n'
      || '| where subnetId in~ (\n'
      || :subnet_list || '\n'
      || ')\n'
      || '| summarize by id, name'
    INTO :kql;

  RETURN :kql;
END;
$$;

  2. Use the resource graph query from the output in Azure Resource Graph Explorer (https://learn.microsoft.com/en-us/azure/governance/resource-graph/first-query-portal) or the Azure CLI (https://learn.microsoft.com/en-us/azure/governance/resource-graph/first-query-azurecli) to find storage accounts that have one or more subnet IDs allowlisted.

3a. Make the change in Azure Network Security Perimeter

  1. Follow the Azure instructions (https://learn.microsoft.com/en-us/azure/private-link/create-network-security-perimeter-portal) to provision Azure Network Security Perimeter, if you haven’t already.

  2. Keep NSP in Transition mode (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-transition) while retaining the existing subnet IDs.

    Snowflake relies on the ability to automatically fall back to the existing egress path, which uses subnet ID allowlisting by customers, as a risk mitigation measure during the rollout of Snowflake Network Identifiers.

  3. Allowlist the Snowflake Network Identifiers in your inbound IP-based rules.

  4. Associate the Azure Network Security Perimeter with your storage accounts by following the Azure Storage instructions (https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-perimeter).

  5. Optionally, configure Azure Monitor for Azure Network Security Perimeter by using this guide (https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/network-security-perimeter). You can verify that the NSP is using the appropriate allowlisting rules by using diagnostic logs from Azure Monitor (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-diagnostic-logs).

3b. Make the change in your storage firewall

Follow the instructions in the Azure Storage network security documentation (https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security) to add the CIDRs for Snowflake Network Identifiers from SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES to your storage accounts’ firewall rules as an IP network rule.

Allowlist the Snowflake Network Identifiers for Azure Key Vault

For Azure Key Vault (https://learn.microsoft.com/en-us/azure/key-vault/general/overview), provision an Azure Network Security Perimeter (NSP) (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-concepts) with access rules to allowlist the Snowflake Network Identifiers and associate all relevant Key Vaults with it (https://learn.microsoft.com/en-us/azure/key-vault/general/network-security?tabs=azure-portal#network-security-perimeter). Until further notice, retain existing subnet IDs, and keep NSP in transition mode with Snowflake subnet IDs allowed outside of NSP in the resource firewall.

1. Get details on the CMK for the current Snowflake account

Run SYSTEM$GET_CMK_INFO or SELECT SYSTEM$GET_CMK_INFO('<ssa_name>'); to get the Azure Key Vault associated with your customer-managed key (CMK).

2. Optional: Use Azure Resource Graph queries to find Azure Key Vaults that use Snowflake subnet IDs

You can use Azure Resource Graph queries to get a list of Azure Key Vaults with allowlisted Snowflake subnet IDs.

  1. Run the following SQL script to get an Azure Resource Graph query, then copy the output for use in the Azure console or CLI:

    EXECUTE IMMEDIATE $$
DECLARE
  has_aa       BOOLEAN;
  subnet_ids   ARRAY;
  subnet_list  STRING;
  kql          STRING;
BEGIN
  SELECT ARRAY_CONTAINS('ACCOUNTADMIN'::VARIANT,
                        PARSE_JSON(CURRENT_AVAILABLE_ROLES()))
    INTO :has_aa;

  IF (NOT :has_aa) THEN
    RETURN 'You need the ACCOUNTADMIN role to run SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO()';
  END IF;

  USE ROLE ACCOUNTADMIN;

  SELECT PARSE_JSON(SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO())
           :"snowflake-vnet-subnet-id"::ARRAY
    INTO :subnet_ids;

  SELECT LISTAGG('"' || f.value::STRING || '"', ',\n')
    INTO :subnet_list
    FROM TABLE(FLATTEN(input => :subnet_ids)) f;

  SELECT 'resources\n'
      || '| where type =~ "microsoft.keyvault/vaults"\n'
      || '| mv-expand vnetRule = properties.networkAcls.virtualNetworkRules\n'
      || '| extend subnetId = tostring(vnetRule.id)\n'
      || '| where subnetId in~ (\n'
      || :subnet_list || '\n'
      || ')\n'
      || '| summarize by id, name'
    INTO :kql;

  RETURN :kql;
END;
$$;

  2. Use the resource graph query from the output in Azure Resource Graph Explorer (https://learn.microsoft.com/en-us/azure/governance/resource-graph/first-query-portal) or the Azure CLI (https://learn.microsoft.com/en-us/azure/governance/resource-graph/first-query-azurecli) to find Key Vaults that have one or more subnet IDs allowlisted.

3. Make the change in Azure Network Security Perimeter

Azure Network Security Perimeter is the only way to allowlist traffic that uses Snowflake Network Identifiers to Azure Key Vault.

  1. Follow the Azure instructions (https://learn.microsoft.com/en-us/azure/private-link/create-network-security-perimeter-portal) to provision Azure Network Security Perimeter, if you haven’t already.
  2. Set the NSP to Transition mode (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-transition).
  3. Allowlist the Snowflake Network Identifiers in your inbound IP-based rules.
  4. Associate the Azure Network Security Perimeter with your Azure Key Vaults by following the Azure Key Vault instructions (https://learn.microsoft.com/en-us/azure/key-vault/general/network-security?tabs=azure-portal#network-security-perimeter).
  5. Optionally, configure Azure Monitor for Azure Network Security Perimeter by using this guide (https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/network-security-perimeter). You can verify that the NSP is using the appropriate allowlisting rules by using diagnostic logs from Azure Monitor (https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-diagnostic-logs).

Important

For storage accounts that are associated with an Azure Network Security Perimeter, for customer-managed keys (CMK) scenarios to work, ensure that the Azure Key Vault is accessible from within the perimeter to which the storage account is associated.

Validation

Validation using Azure Resource Graph queries

The following SQL script provides an Azure Resource Graph query that checks for Azure Storage and Azure Key Vault resources that have the Snowflake subnets and Snowflake Network Identifiers allowlisted. It also checks for an Azure Network Security Perimeter that’s provisioned and associated with the resources and that has the correct IP ranges.

For all Snowflake use cases, both the subnet ID and IP ranges must be allowlisted until further notice.

EXECUTE IMMEDIATE $$
DECLARE
  has_aa       BOOLEAN;
  subnet_ids   ARRAY;
  subnet_list  STRING;
  ip_list_fw   STRING;
  ip_list_nsp  STRING;
  kql          STRING;
BEGIN
  -- 1. Check whether ACCOUNTADMIN is available to the current user.
  SELECT ARRAY_CONTAINS('ACCOUNTADMIN'::VARIANT,
                        PARSE_JSON(CURRENT_AVAILABLE_ROLES()))
    INTO :has_aa;

  IF (NOT :has_aa) THEN
    RETURN 'You need the ACCOUNTADMIN role to run SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO() and SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES()';
  END IF;

  -- 2. Switch to ACCOUNTADMIN.
  USE ROLE ACCOUNTADMIN;

  SELECT PARSE_JSON(SYSTEM$GET_SNOWFLAKE_PLATFORM_INFO())
           :"snowflake-vnet-subnet-id"::ARRAY
    INTO :subnet_ids;

  SELECT LISTAGG('    "' || f.value::STRING || '"', ',\n')
                 WITHIN GROUP (ORDER BY f.value::STRING)
    INTO :subnet_list
    FROM TABLE(FLATTEN(input => :subnet_ids)) f;

  SELECT LISTAGG('    "'     || r.value:ipv4_prefix::STRING || '"', ',\n')
                 WITHIN GROUP (ORDER BY r.value:ipv4_prefix::STRING),
         LISTAGG('        "' || r.value:ipv4_prefix::STRING || '"', ',\n')
                 WITHIN GROUP (ORDER BY r.value:ipv4_prefix::STRING)
    INTO :ip_list_fw, :ip_list_nsp
    FROM TABLE(FLATTEN(input =>
           PARSE_JSON(REGEXP_REPLACE(SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES(), '//.*', '')))) r
   WHERE ARRAY_TO_STRING(r.value:usage::ARRAY, '|') ILIKE '%Network Identifier%';

  SELECT 'resources\n'
      || '| where type in~ ("microsoft.storage/storageaccounts", "microsoft.keyvault/vaults")\n'
      || '| extend resourceId   = tolower(id)\n'
      || '| extend resourceType = type\n'
      || '| extend hasSubnetId = toint(tostring(properties.networkAcls.virtualNetworkRules) has_any (\n'
      || :subnet_list || '\n'
      || '  ))\n'
      || '| extend hasPrefix = toint(tostring(properties.networkAcls.ipRules) has_any (\n'
      || :ip_list_fw || '\n'
      || '  ))\n'
      || '| project id, name, resourceType, resourceId, hasSubnetId, hasPrefix\n'
      || '| join kind=leftouter (\n'
      || '    networkresources\n'
      || '    | where type in~ (\n'
      || '        "microsoft.network/networksecurityperimeters/resourceassociations",\n'
      || '        "microsoft.network/networksecurityperimeters/profiles/accessrules"\n'
      || '      )\n'
      || '    | extend profileId = iff(\n'
      || '        type =~ "microsoft.network/networksecurityperimeters/resourceassociations",\n'
      || '        tolower(tostring(properties.profile.id)),\n'
      || '        tolower(tostring(split(id, "/accessRules")[0]))\n'
      || '      )\n'
      || '    | extend assocResourceId = tolower(tostring(properties.privateLinkResource.id))\n'
      || '    | extend ruleHasTargetIp = toint(tostring(properties.addressPrefixes) has_any (\n'
      || :ip_list_nsp || '\n'
      || '      ))\n'
      || '    | summarize resourceIds = make_set_if(assocResourceId, isnotempty(assocResourceId)),\n'
      || '                hasTargetIp = max(ruleHasTargetIp) by profileId\n'
      || '    | mv-expand resourceId = resourceIds to typeof(string)\n'
      || '    | where isnotempty(resourceId)\n'
      || '    | summarize hasNspTargetIp = max(hasTargetIp) by resourceId\n'
      || ') on resourceId\n'
      || '| extend hasNspTargetIp = coalesce(hasNspTargetIp, 0)\n'
      || '| where hasSubnetId > 0 or hasPrefix > 0 or hasNspTargetIp > 0\n'
      || '| project id, name, resourceType, hasSubnetId, hasPrefix, hasNspTargetIp'
    INTO :kql;

  RETURN :kql;
END;
$$;

The output of the Azure Resource Graph query is a table like this:

idnameresourceTypehasSubnetIdhasPrefixhasNspTargetIp
/subscriptions/.../resourceGroups/.../providers/Microsoft.KeyVault/vaults/...<kms-name>microsoft.keyvault/vaults101
/subscriptions/.../resourceGroups/.../providers/Microsoft.Storage/storageAccounts/...<storage-acct>microsoft.storage/storageaccounts110

For the final state, if hasSubnetId is 1 (true), then either or both of hasPrefix and hasNspTargetIp should also be 1 (true).

Validation using Snowflake functions

Note

This functionality is available after September 21, 2026.

After you update your Azure Storage firewall rules or Azure Key Vault virtual network rules, you can use Snowflake’s public validation functions to confirm that the change has been implemented correctly.

After you allowlist the Snowflake Network Identifiers, set the ENABLE_NETWORK_IDENTIFIER_ALLOWLISTING_VALIDATION session parameter at either the session level or the account level (available to ACCOUNTADMIN). For example:

ALTER SESSION SET ENABLE_NETWORK_IDENTIFIER_ALLOWLISTING_VALIDATION = true;

After the behavior change period completes, Snowflake Network Identifiers are always used for the validation functions, so setting this parameter won’t be required or possible.

After you set the parameter, use the following Snowflake system functions to list and validate your storage integrations, external volumes, and Key Vault integrations:

FeatureList function or queryValidation
Storage integrationsSHOW INTEGRATIONSSYSTEM$VALIDATE_STORAGE_INTEGRATION
External volumesSHOW EXTERNAL VOLUMESSYSTEM$VERIFY_EXTERNAL_VOLUME
Tri-Secret Secure with Azure Key Vault or CMKSYSTEM$GET_CMK_INFOSYSTEM$VERIFY_CMK_INFO

These validation checks exercise the Snowflake access path relevant to this change. A successful result indicates that Snowflake can reach the configured Azure Storage or Azure Key Vault resource by using the updated network configuration.

If validation fails, review the relevant firewall or Network Security Perimeter rules and confirm that the newly added Snowflake Network Identifiers have been allowlisted correctly.

If you have questions about this change, open a case with Snowflake Support and reference this behavior change.

Ref: 2391