This is best Fabric, Power BI, SQL and AI community event. How do we know? The last event sold out! Save €200 with code FABCMTY200.
Register nowA new Data Days event is coming soon! This time we’re going bigger than ever. Fabric, Power BI, SQL, AI and more. Don't miss out.
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 May 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 |
|---|---|
| 14 | |
| 10 | |
| 10 | |
| 7 | |
| 7 |
| User | Count |
|---|---|
| 35 | |
| 28 | |
| 26 | |
| 22 | |
| 16 |