Blog written by Ali Sharafi, Principal Consultant.
When designing a Microsoft Fabric solution, one of the early architecture decisions is how Fabric will connect to private data sources. The source might be an on-premises SQL Server, an Azure SQL database behind a private endpoint, an AWS-hosted database, or another system sitting inside a secured network.
This is where the choice between Microsoft Fabric VNet Data Gateway and On-Premises Data Gateway becomes important. At first, it may look like a gateway decision, but in reality, it is a network architecture decision.
The main question is not: “Which gateway is better?” The better question is: “How will Fabric privately reach the source system?”
The common misunderstanding
A common misunderstanding is that VNet Data Gateway is only for Azure data sources. That is too narrow.
Yes, VNet Data Gateway is commonly used for Azure services such as Azure SQL, ADLS Gen2, or other resources protected by private endpoints. But the use case can be broader.
If an on-premises server or AWS-hosted database can be reached through an Azure Virtual Network, for example through VPN, ExpressRoute, site-to-site connectivity, correct routing and DNS, then VNet Data Gateway may also be a valid option.
So the decision should not be based only on whether the source is “on-premises” or “cloud”. It should be based on the private network path.
What is the On-Premises Data Gateway?
The On-Premises Data Gateway is software installed on a Windows server or VM. That machine sits in a network where it can reach the source system.
In this pattern, the gateway server becomes the controlled bridge between Microsoft Fabric or Power BI and the private data source. This option is common when an organisation already has existing gateway infrastructure, or when extending the source network into Azure is not preferred.
The trade-off is that the customer needs to manage the gateway server, including patching, upgrades, monitoring, high availability, firewall rules and performance sizing.
The key question is: Can the gateway machine reach the source?
What is the VNet Data Gateway?
The VNet Data Gateway works differently. Instead of installing gateway software on a customer-managed Windows server, the gateway is associated with an Azure Virtual Network.
This makes it useful when Microsoft Fabric or Power BI needs to reach data sources through an Azure-based private network path. That source may be Azure-native, such as Azure SQL or ADLS behind private endpoints.
But it may also be an on-premises SQL Server or AWS-hosted database, provided the Azure VNet can reach that source through private connectivity, routing and DNS.
This option is useful when the organisation already has Azure networking in place and wants to avoid managing a traditional gateway server.
The key question is: Can the Azure VNet reach the source privately?
Quick comparison
On-Premises Data Gateway
Best when Fabric needs to connect through a customer-managed Windows server or VM that can reach the source system.
Typical use cases include on-premises SQL Server, file shares, legacy systems, private databases, or cloud-hosted sources reachable from the gateway machine.
The main cost is infrastructure and operations: VM/server, patching, monitoring, upgrades and support.
Key question: Can the gateway machine reach the source?
VNet Data Gateway
Best when Fabric needs to connect through an Azure VNet private network path.
Typical use cases include Azure SQL/private endpoints, ADLS with public access disabled, on-premises sources connected to Azure through VPN/ExpressRoute, or AWS sources connected to Azure through site-to-site VPN.
The main cost is Fabric or Power BI capacity consumption.
Key question: Can the Azure VNet reach the source?
Cost perspective
The cost comparison is important because the two options do not show cost in the same way.
The On-Premises Data Gateway usually does not have a separate gateway licence cost, but it does require infrastructure. That means the cost may come from the Windows server or VM, monitoring, patching, gateway upgrades, high availability setup, support and network maintenance.
With VNet Data Gateway, there may be no separate gateway VM to manage, but that does not mean it has no cost impact. VNet Data Gateway uses Fabric or Power BI capacity, so the cost appears differently.
A simple way to explain it is:
On-Premises Data Gateway shifts the cost to infrastructure and operations. VNet Data Gateway shifts the cost to Fabric or Power BI capacity consumption.
So if an organisation already has Fabric capacity, VNet Data Gateway may avoid the need for a separate gateway VM. However, it should still be considered in capacity planning, especially for larger workloads or frequent refresh and ingestion patterns.
Example: AWS database connected to Fabric
Imagine a database is hosted in AWS. At first, someone may assume this requires an On-Premises Data Gateway because the database is not in Azure.
But that is not always true.
If the AWS network is connected to Azure through site-to-site VPN, and the Azure VNet can reach the AWS database using the correct routing, firewall rules and DNS, then VNet Data Gateway may be a suitable option.
In this case, the key point is not that the database is in AWS. The key point is that Fabric can reach it through an Azure VNet private network path.
Example: On-premises SQL Server and Fabric Mirroring
The same thinking can apply to an on-premises SQL Server.
If the server is reachable from Azure through VPN or ExpressRoute, VNet Data Gateway may be considered, especially for scenarios such as Fabric Mirroring or private data ingestion.
Again, the decision is not only about where the server physically sits. The decision is about whether Fabric has a secure and supported private path to reach it.
Simple decision guide
Do not start by asking: “Is the source on-premises or cloud?”
Start by asking: “How will Microsoft Fabric privately reach the source?”
If the answer is “through a customer-managed Windows server or VM close to the source,” then the On-Premises Data Gateway may be the better fit.
If the answer is “through an Azure VNet that can route to the source,” then the VNet Data Gateway may be the better fit.
FAQ
Is VNet Data Gateway only for Azure data sources?
No. VNet Data Gateway is commonly used with Azure private endpoints and Azure network-secured resources, but it can also be used when other private sources are reachable through an Azure VNet path.
That can include on-premises or AWS-hosted sources, depending on the network design.
Does VNet Data Gateway replace the On-Premises Data Gateway?
No. They support different connectivity patterns.
The On-Premises Data Gateway is centred around a customer-managed gateway machine. The VNet Data Gateway is centred around an Azure VNet private network path.
The right choice depends on source location, routing, DNS, security requirements, workload, operational ownership and cost model.
Is VNet Data Gateway free if we already have Fabric capacity?
Not exactly. It may remove the need for a separate gateway VM, but it still consumes Fabric or Power BI capacity.
So it should still be considered in capacity planning.
Which gateway is cheaper?
There is no single answer.
The On-Premises Data Gateway may be cheaper if the organisation already has suitable server infrastructure and support processes. The VNet Data Gateway may reduce operational overhead, but the impact moves into Fabric or Power BI capacity consumption.
A practical way to compare them is:
On-Premises Data Gateway cost appears in infrastructure and operations. VNet Data Gateway cost appears in capacity usage.
Final thought
The gateway decision should be made early in a Microsoft Fabric architecture. If it is left too late, teams can end up with unnecessary firewall exceptions, failed refreshes, performance issues, capacity concerns or rework in the pipeline design.
For me, the main lesson is simple: choosing between Microsoft Fabric VNet Data Gateway and On-Premises Data Gateway is not just about the gateway.
It is about the source location, private network path, security model, operational ownership and cost model.
In Fabric architecture, connectivity should be designed before the pipelines are built.
