Power Platform has become the centerpiece for low-code digital transformation but as solutions scale and handle more sensitive data, network security and controlled connectivity become crucial.

Traditionally, the On-Premises Data Gateway has been the go-to method for accessing data securely behind firewalls. However, Microsoft has introduced Virtual Network (VNet) Integration for Power Platform as a fully cloud-native, secure, and scalable alternative.

This guide walks you through everything you need to know: what VNet integration is, how to set it up, and why it may (or may not) replace your data gateways. We’ll also share tips, limitations, and best practices so you can confidently design modern enterprise-grade architectures.

What Is Power Platform VNet Integration?

Virtual Network Integration allows your Power Platform environments to connect to data sources secured within an Azure Virtual Network, without needing to install or manage an on-premises data gateway.

This includes:

• Azure SQL Databases with private endpoints

• Azure Storage or Data Lake services in a private VNet

• Third-party APIs hosted behind Azure Application Gateway or private VMs

Note: VNet integration is not for on-premises data access. It’s designed for Azure-resident data, where you’ve locked access behind private networking.

VNet integration is ideal when:

• Your data sources are secured using private endpoints.
• You want to eliminate reliance on a self-hosted gateway.
• You operate in a Zero Trust network environment.
• You’re consolidating into a cloud-native, Azure-first architecture.

Supported Services & Scenarios

VNet integration is currently supported only for specific services. Power BI datasets still require a traditional gateway when accessing private data.

How to Set Up VNet Integration

Let’s walk through the setup using the new experience in the Power Platform Admin Center.

Prerequisites

• Azure Subscription with permissions to create VNet and subnets
• Power Platform Environment (Production or Sandbox)
• Private Endpoints for your target data sources (e.g., Azure SQL, Storage)
• A supported region for VNet connectivity

Enable VNet Integration in the Admin Center

• Navigate to Power Platform Admin Center  
• Select Environments → Choose your target environment
• Go to Settings → Networking
• Under Virtual Network Configuration, click + Configure

If you’re using the old experience, it will prompt a migration to the new experience.

Choose or Create the VNet

• Select an existing Azure Virtual Network or create a new one from Azure Portal.
• The selected subnet should be empty (no NSGs, no UDRs that block traffic).
• Microsoft will provision a Managed Private Endpoint within this subnet.

Tip: Avoid assigning custom NSGs or Route Tables unless explicitly needed.

Link the Private Endpoint Data Sources

To allow Power Platform to connect:

• Add Private Endpoints to your Azure SQL, Data Lake, Blob, etc.
• Approve the Private Endpoint connections in Azure.
• Ensure DNS resolution is handled (via Azure DNS or private zones).

Wait for Provisioning

The provisioning process may take 30–90 minutes, during which Microsoft:

• Deploys a Managed VNet in your Azure subscription
• Links your environment to the subnet
• Sets up Managed Private Endpoints to supported Azure services

Once done, you’ll see the VNet status as Connected in the Admin Center.

Best Practices

• Use Separate Subnets for Power Platform: Avoid mixing VMs, App Services, and Power Platform in the same subnet.
• Automate with ARM/Bicep: Use infrastructure as code to consistently configure VNet and Private Endpoints across environments.
• DNS Matters: If your DNS isn’t resolving to private endpoints, Power Platform won’t connect. Use Azure Private DNS Zones to avoid this.
• Monitor with Azure Monitor + Defender for Cloud: Capture traffic, detect anomalies, and confirm private endpoint usage.

How Is Security Handled?

According to Microsoft’s whitepaper, VNet integration adds multiple layers of protection:

• Private connectivity: Traffic never leaves Microsoft’s backbone.
• Isolated runtime: Apps and dataflows run inside a secure, customer-specific managed VNet.
• Azure policy support: Apply NSGs and route filters with care.
• No need for IP whitelisting: Unlike gateways, you don’t need to allow outbound IPs.

Best Practice: Combine VNet integration with Data Loss Prevention (DLP) Policies to restrict connector usage and enhance data governance.

When Should You Use VNet Integration?

Use VNet Integration If:

• Your data lives in Azure services (SQL, Storage, Lake)
• You’ve restricted them using Private Endpoints
• You want zero maintenance and high security

Stick with On-Premises Gateway If:

• You’re accessing on-premises systems
• You rely on custom connectors or local APIs
• Your data sources aren’t behind Azure Private Endpoints

Summary: Should You Switch?

Power Platform VNet Integration is the way forward for cloud-native, secure, and scalable data access in Azure. It’s not a full replacement for the on-prem gateway but it is the better choice when:

• You’re building in Azure

• Your architecture aligns with Zero Trust

• You want to avoid managing gateways

For hybrid organizations, both options can co-exist. You might still need on-premises gateways for legacy data, while using VNet integration for Azure-based workloads.

Hope you had a good read!

Signing Out,

Dela