Forum Discussion
Post ProdigyMicrosoft Best Practice for Power BI, On-premises Data Gateway, and Snowflake Across Vendor and Cust
Microsoft Best Practice for Power BI, On-premises Data Gateway, and Snowflake Across Vendor and Customer Organizations
Hi Community,
I would appreciate guidance on the Microsoft-recommended architecture for the following enterprise scenario.
Current Environment
Customer: Large enterprise organization with thousands of Power BI users.
Vendor: Report development partner.
Snowflake Account: Owned and managed by the vendor.
Power BI Tenant, Workspaces, and Reports: Owned by the customer.
Report Development: The vendor develops Power BI reports and publishes them to the customer's Power BI Service.
Current Challenge
The Snowflake account is protected by a network policy, allowing connections only from approved public IP addresses.
The customer's Power BI datasets require an On-premises Data Gateway to connect to Snowflake.
However, the gateway's public IP address has not yet been made available for Snowflake whitelisting, which has delayed the implementation for several months.
Because of this, the customer has asked whether the vendor should manage more of the Power BI infrastructure to reduce operational dependencies.
Options Being Considered
Option 1
Continue with the existing architecture:
Customer owns the Power BI tenant.
Customer manages the gateway.
Resolve the issue by whitelisting the gateway's public IP address in Snowflake.
Option 2
The vendor hosts and manages the Windows server running the On-premises Data Gateway.
The gateway is registered in the customer's Power BI tenant.
Reports continue to be published to the customer's Power BI workspaces.
Option 3
The vendor hosts:
Power BI tenant
Gateway
Reports
Customer users access reports through Microsoft Entra B2B collaboration (or another supported approach).
Additional Context
The customer already has a mature enterprise Power BI environment with:
Thousands of users
Multiple enterprise gateway clusters
Centralized administration
Established governance and security processes
The vendor is primarily responsible for report development and currently does not operate an enterprise-scale Power BI environment.
Questions
From Microsoft's enterprise architecture perspective, which option is considered the recommended approach for a production environment?
Is Option 2 fully supported by Microsoft?
Can an On-premises Data Gateway be installed on infrastructure managed by the vendor while being registered in the customer's Power BI tenant?
Are there any limitations or unsupported scenarios?
Would Microsoft recommend moving production Power BI ownership from the customer to the vendor solely to avoid a gateway/network connectivity issue?
If Option 2 is supported, what are the recommended implementation steps and best practices?
Has anyone implemented a similar architecture in production? If so, what challenges or lessons learned would you share?
Our goal is to follow Microsoft's recommended enterprise architecture and best practices rather than implement a temporary workaround.
Thank you in advance for your guidance.
One thing worth stepping back on: this is really a network whitelist problem, and Options 2 and 3 are big architectural changes to get around a single firewall rule. I'd be careful about re-platforming to dodge one IP entry.
The blocker is that the gateway's outbound public IP isn't whitelisted in Snowflake. That's Option 1, and it's the right one. Keep ownership with the customer, who already has the mature tenant, gateway clusters and governance. The months of delay is coordination (getting a static egress IP approved and added to the policy), not a technical limit. Put the gateway behind a stable outbound IP so the entry doesn't drift, and you're basically done.
Option 2 is technically supported. A gateway can run on vendor infrastructure and register to the customer's tenant by signing in with a tenant account, Microsoft doesn't mind where the box physically lives. But it doesn't remove the whitelist requirement, and it hands the vendor operational and security ownership of a machine that holds a live connection into the customer's tenant plus Snowflake credentials. The one real upside: since the vendor owns Snowflake, a vendor-hosted gateway turns the whitelist into a single vendor-internal change instead of cross-org back-and-forth. If that coordination is what's actually cost you months, that's the lever, but it's a lot of change for that one gain.
Option 3 I'd rule out. Moving production tenant ownership and going B2B to solve a connectivity issue throws away the customer's existing governance for no proportional benefit. Microsoft wouldn't steer you there for this.
So I'd aim for Option 1 with a static egress IP nailed down, and only consider Option 2 if the blocker turns out to be organizational rather than technical, since moving the gateway to the vendor side collapses the cross-org coordination.
3 Replies
- DataTako
Resolver IV
One thing worth stepping back on: this is really a network whitelist problem, and Options 2 and 3 are big architectural changes to get around a single firewall rule. I'd be careful about re-platforming to dodge one IP entry.
The blocker is that the gateway's outbound public IP isn't whitelisted in Snowflake. That's Option 1, and it's the right one. Keep ownership with the customer, who already has the mature tenant, gateway clusters and governance. The months of delay is coordination (getting a static egress IP approved and added to the policy), not a technical limit. Put the gateway behind a stable outbound IP so the entry doesn't drift, and you're basically done.
Option 2 is technically supported. A gateway can run on vendor infrastructure and register to the customer's tenant by signing in with a tenant account, Microsoft doesn't mind where the box physically lives. But it doesn't remove the whitelist requirement, and it hands the vendor operational and security ownership of a machine that holds a live connection into the customer's tenant plus Snowflake credentials. The one real upside: since the vendor owns Snowflake, a vendor-hosted gateway turns the whitelist into a single vendor-internal change instead of cross-org back-and-forth. If that coordination is what's actually cost you months, that's the lever, but it's a lot of change for that one gain.
Option 3 I'd rule out. Moving production tenant ownership and going B2B to solve a connectivity issue throws away the customer's existing governance for no proportional benefit. Microsoft wouldn't steer you there for this.
So I'd aim for Option 1 with a static egress IP nailed down, and only consider Option 2 if the blocker turns out to be organizational rather than technical, since moving the gateway to the vendor side collapses the cross-org coordination.
- MohamedFowzan1
Super User
Hi manoj_0911
Given the customer's existing Power BI environment (enterprise gateway clusters, governance, centralized administration, and thousands of users), I'd lean towards Option 1 as the long-term architecture. It aligns with keeping the customer in control of their own Power BI platform, with the current issue being resolved by whitelisting the gateway's public IP in Snowflake.Option 2 is also a valid approach as far as I'm aware. The On-premises Data Gateway doesn't have to be installed on infrastructure owned by the customer, it can run on a server managed by the vendor as long as it can communicate with both the data source and the customer's Power BI tenant, and the customer retains ownership and administration of the gateway.
I personally wouldn't recommend Option 3 purely to work around a network connectivity issue. Moving an enterprise Power BI platform to a vendor introduces much broader governance, security, licensing, and operational considerations that seem disproportionate to solving a gateway IP whitelist issue.
From an enterprise architecture perspective I'd treat the gateway connectivity as an infrastructure issue rather than a reason to change platform ownership.
v-abhinavmuCommunity Support
Hi manoj_0911,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to DataTako & MohamedFowzan1 for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
