Connectivity patterns in Microsoft Fabric: A guide for data integration workloads

This blog post focuses on connectivity options for Microsoft Fabric workloads that use Data Factory runtime components, including Dataflow Gen2, Fabric Data Pipelines, Fabric Copy Job, Fabric Mirroring, Power BI semantic models, and Power BI paginated reports. The guidance and networking considerations described in this article apply to the above data integration scenarios of Fabric.

Workloads such as Notebooks, Spark Job Definitions (SJD), and other Spark-based experiences are not covered by this guidance. These workloads use the Fabric Managed Virtual Network (Managed VNet) for data access and therefore follow a different connectivity model and network architecture.

Enterprise data rarely lives in a single location. It is often distributed across public cloud services, Azure virtual networks, on-premises environments, and software-as-a-service applications. Microsoft Fabric must have a supported network path to each data source before workloads can access it. The appropriate connectivity option depends primarily on the source network location and whether Fabric must cross a private network boundary. This guide will help you determine when to use a VNet data gateway, an on-premises data gateway, or a direct cloud connection for data integration scenarios of Fabric.

A simple way to choose the right option is to start with one question set: Where does the data source live, and does Fabric need to cross a private network boundary to reach it?

Why gateway choice matters

The connectivity model determines how Fabric reaches data sources and can affect security, governance, operational overhead, and network architecture decisions. Before users can build semantic models, pipelines, reports, notebooks, or analytical experiences, the platform needs a reliable way to reach the data.

A gateway acts as an intermediary between a supported Fabric workload and a data source. It establishes the required connectivity path, relays supported queries or data requests and returns results to the calling service. The exact data movement and processing behavior depends on the Fabric workload, connector, connection mode, and gateway type. Gateways provide secure connectivity to private data sources through outbound-only communication and encrypted data transfer, eliminating the need to expose internal systems to the public internet.

In Microsoft Fabric, that connectivity decision can affect how securely Fabric reaches the source, whether infrastructure needs to be deployed or maintained, whether the connection can be shared across teams, and how well the pattern fits enterprise governance requirements. Selecting the right connectivity pattern early can help prevent architecture changes later. For example, a source protected by private endpoints may require a different approach than a publicly accessible SaaS application, while an on-premises SQL Server deployment often has different requirements than a cloud-to-cloud integration scenario.

Option 1: VNet data gateway

Use a VNet data gateway when a supported data source is reachable from an Azure virtual network and is not intended to be accessed through a public endpoint. The source might use a private endpoint, reside in a connected virtual network, or be reachable from Azure through an appropriately configured private network path, such as ExpressRoute.

VNet data gateway provides a Microsoft-managed connectivity option for supported data sources that are reachable through an Azure virtual network. Organizations can enable private connectivity without deploying or maintaining gateway virtual machines, making this a good option when you need private network access without managing additional infrastructure.

When to use it

• The data source is reachable from an Azure virtual network.
• The scenario requires private connectivity, such as access through a private endpoint or an ExpressRoute-connected network.
• Fabric workloads that need secure and scalable access to data sources enabling Dataflow Gen2, Data Pipelines, Copy Job, Mirroring, Semantic Models, and Paginated Reports to access enterprise data
• Your organization prefers Microsoft-managed gateway rather than deploying and maintaining gateway virtual machines.
• The required Fabric workload, connector, authentication method, and region are supported.
• The Azure virtual network has the required network configuration and available capacity.

Key benefits

• Microsoft-managed infrastructure: Microsoft operates the gateway infrastructure, reducing the need to deploy and maintain gateway virtual machines.
• Private network reachability: Supported Fabric workloads can connect to sources reachable from the Azure virtual network.
• Network isolation: Data sources can remain behind private network boundaries instead of requiring public endpoints.
• Hybrid reachability: Sources connected to the virtual network through supported network paths, including ExpressRoute, can be reachable without deploying the gateway directly in the on-premises environment.
• Capacity management: Supported scaling capabilities can help accommodate changing workload demands while reducing manual infrastructure management.
• Centralized connectivity: Administrators can configure and govern shared connections for supported workloads and users

Option 2: On-premises Data Gateway, standard mode

The on-premises data gateway is customer-managed software that runs on a supported machine in a network that can reach the data source. The gateway can be installed on an on-premises server or on a supported virtual machine, depending on the organization’s network design and operational requirements.

Standard mode supports shared connectivity across approved users, connections, and workloads. Your organization is responsible for deploying, updating, monitoring, and maintaining the gateway host.

When to use it

• The data source resides within an on-premises environment or a private network that is not directly accessible from Microsoft cloud services.
• You're able to provision and manage the required gateway infrastructure, including virtual machines, software updates, monitoring, and lifecycle maintenance.
• Multiple users or workloads need access, and the gateway should be centrally managed.
• You need enterprise-grade sharing and governance across Fabric, Power BI, Power Apps, Power Automate, Logic Apps, or Azure Analysis Services.

Key Benefits

• Securely access on-premises and private-network data sources from Microsoft Fabric.
• Reuse existing network, firewall, and security investments without exposing data sources to the public internet.
• Centrally manage and govern connectivity for multiple users, teams, and workloads.
• Support hybrid and multi-cloud integration scenarios from a single gateway platform.
• Improve reliability and scalability through gateway clustering and high-availability deployments.
• Accelerate Fabric adoption by leveraging existing infrastructure and operational processes.

Option 3: Cloud connection with no gateway

Use a cloud connection with no gateway when the source is already cloud-based and publicly accessible.

In this scenario, Fabric can connect directly to the service without traversing a private networking layer. Fabric can connect directly to the service using the supported connector and authentication method. This is often the simplest connectivity path. If the source is a public SaaS application, cloud API, or cloud data service that does not require access through a private network, then a gateway may not be needed.

When to use it

•  The source is fully cloud-based and publicly reachable.
•  There is no private endpoint or private network boundary.
•  Direct SaaS or cloud-to-cloud connectivity is supported.
•  You do not need gateway infrastructure or runtime management.

Common connectivity scenarios

The following examples illustrate common Microsoft Fabric connectivity patterns and can help simplify gateway selection. Depending on the network architecture, some on-premises data sources may be reachable through either On-premises Data Gateway or VNet data gateway.

• Azure SQL Database with a private endpoint: If Azure SQL Database is accessible only through a private endpoint or a virtual network, use a VNet data gateway. This allows Fabric workloads to securely access the data source without requiring public network access.
• Azure Storage account secured through virtual network rules: When a storage account is protected by Azure virtual network restrictions and cannot be accessed through a public endpoint, a VNet data gateway is typically the appropriate choice.
• On-premises data sources connected to Azure through ExpressRoute: Organizations often use Azure ExpressRoute to extend their on-premises network into Azure. When a supported data source remains on-premises but is reachable from an Azure virtual network through ExpressRoute, a VNet data gateway can provide private connectivity from Fabric without requiring customer-managed gateway infrastructure. This can simplify operations while maintaining private connectivity between Microsoft Fabric and the data source.
• SQL Server hosted in an on-premises datacenter: If the data source resides within a corporate datacenter or private network and is not reachable from Azure virtual networks, use On-premises Data Gateway (standard mode) to provide shared, enterprise-grade connectivity.
• Line-of-business applications hosted behind a corporate firewall: Applications such as SAP HANA, Oracle, or other supported data sources that are accessible only from the corporate network generally require On-premises Data Gateway (standard mode).
• Cloud services with public endpoints: For supported cloud services such as Salesforce, Azure SQL Database (public endpoint), Azure Data Lake Storage Gen2 (public endpoint), or other publicly accessible SaaS and PaaS offerings, Fabric can often connect directly without requiring a gateway.

Although these examples represent common deployment patterns, always verify connector support, authentication requirements, networking configuration, regional availability, and workload compatibility when designing your connectivity architecture.

Final takeaway

When planning Microsoft Fabric connectivity, start with the location of the data source and determine whether Fabric must traverse a private network boundary. That single decision typically determines whether a VNet data gateway, an On-premises Data Gateway, or a direct cloud connection is the appropriate choice.

• Use VNet data gateway when you need managed gateway to securely connect Microsoft Fabric workloads to data sources protected by Azure Virtual Networks, private endpoints, or on-premises environments that are connected to Azure through ExpressRoute.
• Use On-premises Data Gateway standard mode for self-hosted shared enterprise access to on-premises or private firewall sources.
• Use a cloud connection without a gateway when the supported cloud data source is reachable directly through its public endpoint and the scenario does not require a private network path.

By using this decision flow, teams can design cleaner, more secure, and easier-to-manage connectivity patterns for Microsoft Fabric.

Next steps

Use the decision flow in this article to identify the connectivity model that best aligns with your data source location, network architecture, and operational requirements. Before implementation, review the supported workloads, connectors, authentication methods, and regional availability for your specific scenario.

To learn more, explore:

• Microsoft Fabric documentation 
• VNet data gateway documentation 
• On-premises data gateway documentation 
• Microsoft Fabric security documentation 

By selecting the appropriate connectivity option early in your architecture design, you can simplify deployment, improve security, and reduce ongoing operational overhead while enabling reliable access to enterprise data. For additional guidance, review the Microsoft Fabric connectivity and gateway documentation to confirm support for your workloads, connectors, authentication methods, and regions.