This time we’re going bigger than ever. Fabric, Power BI, SQL, AI and more. We're covering it all. You won't want to miss it.
Learn moreLevel up your Power BI skills this month - build one visual each week and tell better stories with data! Get started
Request for Historical Power BI Service Tag IP Ranges (Last 12 Months)
We are troubleshooting connectivity between Power BI Service and Snowflake and need to understand IP range stability.
Request:
Historical Service Tag data for “PowerBI” (or AzureCloud) for the past 12 months
Specifically for regions:
East US 2
North Central US
Purpose:
To validate whether outbound IP ranges used by Power BI Service have changed over time
To assess firewall whitelisting strategy
If historical data is not available, please confirm:
Whether Power BI outbound IP ranges are expected to change frequently
Recommended best practice for firewall whitelisting (Service Tags vs static IPs vs gateway)
Solved! Go to Solution.
Microsoft does not publish a historical archive of the PowerBI service tag, only the current weekly JSON snapshot is available, so getting 12 months of past data after the fact is not possible. The IPs in that tag are explicitly subject to change and do drift, which is exactly why pinning them in a firewall is discouraged.
For Power BI Service connecting to Snowflake, the better pattern is to control the egress yourself rather than chasing the service IPs. A VNet or on-prem data gateway makes traffic exit from a single fixed IP that you can whitelist cleanly. If your firewall supports Azure Service Tags directly (Azure Firewall, NSG), reference the PowerBI tag rather than extracted IPs so it auto-updates. Snowflake Private Link with a VNet data gateway is the cleanest long term answer because it removes the service tag question entirely.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best,
Shai Karmani
Microsoft does not publish a historical archive of the PowerBI service tag, only the current weekly JSON snapshot is available, so getting 12 months of past data after the fact is not possible. The IPs in that tag are explicitly subject to change and do drift, which is exactly why pinning them in a firewall is discouraged.
For Power BI Service connecting to Snowflake, the better pattern is to control the egress yourself rather than chasing the service IPs. A VNet or on-prem data gateway makes traffic exit from a single fixed IP that you can whitelist cleanly. If your firewall supports Azure Service Tags directly (Azure Firewall, NSG), reference the PowerBI tag rather than extracted IPs so it auto-updates. Snowflake Private Link with a VNet data gateway is the cleanest long term answer because it removes the service tag question entirely.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best,
Shai Karmani
Check out the April 2026 Power BI update to learn about new features.
Sign up to receive a private message when registration opens and key events begin.
If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.
| User | Count |
|---|---|
| 11 | |
| 9 | |
| 9 | |
| 7 | |
| 7 |
| User | Count |
|---|---|
| 48 | |
| 27 | |
| 24 | |
| 24 | |
| 22 |