Introduction As enterprises increasingly adopt Power Platform, Power BI, and Microsoft Fabric to enable low‑code applications and self‑service analytics, secure access to private Azure data sources becomes a key architectural requirement. Most enterprise environments restrict public access to data using Private Endpoints, NSGs, and firewalls, which introduce challenges for cloud-based analytics services. Traditionally, organizations solved this using self‑hosted or on‑premises data gateways, but those approaches add infrastructure overhead, high availability complexity, patching responsibilities, and operational risk. To simplify this, Microsoft introduced the virtual network (VNet) data gateway — a cloud‑native, fully managed gateway that allows Power Platform and Power BI services to securely access private Azure resources without deploying or maintaining gateway servers. This post explains why enterprises should use the VNet data gateway, its architecture, and how it enables least management overhead with strong security controls.
What Is a VNet data gateway?
The VNet data gateway is a Microsoft‑managed gateway service that runs inside a delegated subnet of an Azure Virtual Network. It allows supported Microsoft cloud services—such as Power BI, Power Platform dataflows, and Microsoft Fabric workloads—to securely connect to data sources that are protected using private networking.
Key characteristics:
- No customer‑managed VM or container
- No OS, patching, or gateway software upgrades
- Gateway lifecycle fully managed by Microsoft
- Traffic stays on the Azure backbone network
- Works seamlessly with Private Endpoints
This makes it ideal for enterprise and regulated environments where security and operational efficiency are equally important.
Why Enterprises need VNet data gateway
- Eliminates gateway infrastructure management
Traditional gateways require:
- Virtual machines
- High availability setup
- OS patching and scaling
- Monitoring and troubleshooting
With the VNet data gateway:
- Microsoft manages compute lifecycle
- No VM or gateway software to maintain
- No HA or load balancer design needed
✅ Result: Significant reduction in operational and maintenance overhead for platform and infrastructure teams.
- Secure access to private Azure resources
Most enterprise Azure environments use:
- Private Endpoints
- NSGs and route tables
- Firewalls blocking public access
The VNet data gateway:
- Is injected into a delegated subnet in your VNet
- Uses private IP addressing
- Enforces NSG and UDR rules
- Communicates with Microsoft services over a Microsoft‑managed internal tunnel
✅ Result: Data sources remain fully private—no public endpoints or inbound ports required.
- Designed for Power Platform & Power BI at Scale
The gateway supports secure access for:
- Power BI semantic models
- Power BI paginated reports
- Microsoft Fabric Dataflow Gen2
- Fabric pipelines and copy jobs
Because it’s cloud‑native and centrally managed, the VNet data gateway scales well in large enterprises standardizing on Power Platform and Fabric.
High‑level architecture overview
At runtime, the VNet data gateway works as follows:
- A query is initiated from Power BI / Power Platform
- Query details and credentials are sent to the Microsoft Power Platform VNet service
- A containerized gateway instance is injected into the delegated subnet
- The gateway connects to the private data source using private networking
- Results are sent back to Power BI or Power Platform via a Microsoft‑managed internal tunnel
Key security highlights:
- No inbound connectivity
- No public IP exposure
- Traffic remains on Azure backbone
- Full enforcement of NSGs and routing rules
Key Enterprise benefits
- Least management overhead – no gateway servers
- Zero Trust aligned – private-only connectivity
- Fully managed by Microsoft
- Enterprise-grade security & governance
- Works with Azure Private Endpoint architectures
When to Use VNet Data Gateway
|
Scenario |
Recommendation |
|
Azure private PaaS services |
✅ VNet data gateway |
|
Private Endpoint–only access |
✅ VNet data gateway |
|
Zero Trust network model |
✅ VNet data gateway |
|
Minimal ops & maintenance |
✅ VNet data gateway |
|
On‑prem only, no Azure |
❌ Traditional gateway |
Step‑by‑step configuration: VNet data gateway (Enterprise setup)
High‑level flow (What you will configure)
- Register required Azure resource provider
- Prepare Azure Virtual Network and subnet
- Configure private connectivity to data source
- Create the VNet data gateway
- Create and bind data source connections
- Validate with Power BI / Power Platform workloads
Step 1: Register Microsoft.PowerPlatform resource provider
Why this step is required
The VNet data gateway is a Microsoft‑managed service that is injected into your Azure VNet. Azure must explicitly allow Power Platform to deploy managed infrastructure into your subscription.
Configuration steps
- Sign in to Azure portal
- Navigate to Subscriptions
- Select the subscription that hosts the target VNet
- Go to Resource providers
- Search for Microsoft.PowerPlatform
- Click Register
✅ Status must show Registered
This step enables subnet delegation to Power Platform services.
Step 2: Prepare the Azure Virtual Network
Why this step is required
The gateway runs inside your VNet. It must be placed in a dedicated, delegated subnet to maintain isolation and security boundaries.
Requirements
- VNet can be in any Azure region
- Subnet must be exclusive to VNet data gateway
- Subnet must have outbound connectivity to the data source
Configuration steps
- Go to Azure portal → virtual networks
- Select your existing VNet (or create one)
- Navigate to Subnets → + Subnet
- Configure:
- Subnet name: snet-vnet-datagateway
- Address range: /27 or larger (recommended)
-
- Subnet delegation:
Microsoft.PowerPlatform/vnetaccesslinks - Save the subnet
- Subnet delegation:
⚠️ Do not place any VMs, app gateway, or other workloads in this subnet.
Step 3: Configure private connectivity to the data source
Why this step is required
Enterprises typically block public access to PaaS services. The VNet data gateway is designed to work natively with private endpoints.
Example: Azure SQL / SQL Managed Instance
- Create Private Endpoint for the data service
- Attach it to the same VNet (can be different subnet)
- Create or link a Private DNS Zone, for example:
- privatelink.database.windows.net
- Link the Private DNS Zone to the VNet
- Ensure DNS resolution from the delegated subnet resolves to private IP
✅ This ensures all traffic remains private and internal.
Step 4: Create the VNet data gateway
Why this step is required
This is where the actual Microsoft‑managed gateway is logically created and associated with your VNet.
Configuration steps
You can do this from either Power BI Service or Power Platform Admin Center.
Using Power Platform Admin Center
- Select Data → Gateways
- Click + New → Virtual network data gateway
- Provide:
-
- Gateway name
-
- Azure subscription
-
- Resource group
-
- Virtual network
-
- Delegated subnet
-
- Click Create
📌 Notes:
- Gateway metadata is stored in Power BI tenant home region
- Gateway runtime executes in the VNet region
- No VM or scale settings are required
Step 5: Create and configure data source connections
Why this step is required
The gateway exists, but Power BI / Power Platform must know which data sources can be accessed via it.
Configuration steps (Power BI example)
- Go to Power BI Service
-
- Navigate to Settings → Manage connections and gateways
-
- Select the newly created VNet data gateway
-
- Click + New connection
-
- Provide:
-
-
- Data source type (Azure SQL, Storage, Databricks, etc.)
-
-
-
- Server / endpoint name (private DNS name)
-
-
-
- Authentication (SQL / Entra ID)
-
- Save the connection
- Assign users or security groups
✅ This step enables governance and access control.
Step 6: Use the gateway in Power BI / Power Platform
Power BI
- Open dataset or semantic model settings
- Under Gateway connection, select:
- Use a data gateway
- Choose the VNet data gateway
- Apply changes
- Refresh or run queries
Power Platform / Fabric
- Select the same connection when configuring:
- Dataflows Gen2
- Fabric pipelines
- Copy jobs
Step 7: Validate and test
Validation Checklist
✅ DNS resolves to private IP
✅ No public endpoint access enabled
✅ NSGs allow outbound traffic to data source
✅ Dataset refresh succeeds
✅ No gateway VM exists in subscription
Optional:
- Enable logging and auditing from Power BI / Fabric
- Monitor gateway health in Admin Center
Key Enterprise design guidance (Best practices)
- Use one gateway per environment tier (Prod / Non‑Prod)
- Use dedicated VNets for data access where possible
- Use Private Endpoint only (avoid service endpoints)
- Control access via AAD groups, not individuals
- Avoid mixing gateway subnet with other workloads
Conclusion: For enterprises looking to consume Power Platform, Power BI, and Microsoft Fabric securely while keeping operational overhead close to zero, the VNet data gateway is the recommended approach.
It removes gateway infrastructure complexity, strengthens security posture, and aligns perfectly with modern Azure landing zone and Zero Trust architectures.
Microsoft