Virtual network data gateway for Dynamics 365

Dynamics 365 and Power Platform often need to reach data sitting in private networks — Azure SQL Databases with private endpoints only, on-prem databases via ExpressRoute, services behind firewalls. Traditionally, this required the on-premises data gateway — a Windows service installed in the customer environment. The virtual network data gateway is a managed alternative: fully Microsoft-hosted, deployed into the customer's Azure virtual network, no Windows server to maintain.

The on-premises gateway recap.

• A Windows service installed in customer infrastructure.
• Polls Microsoft cloud for work.
• Bridges Power Platform / Dynamics requests to private data.
• Customer-managed — patching, scaling, monitoring.
• Available for over a decade; mature; widely used.

The virtual network data gateway.

• Managed by Microsoft — no Windows server to install or patch.
• Deployed into customer's Azure virtual network — a subnet hosts the gateway.
• Accesses resources inside the VNet — Azure SQL with private endpoint, Azure Function, etc.
• Connects to Microsoft cloud through standard mechanisms.

The headline benefit: customer's data stays inside their VNet; Microsoft's compute reaches in temporarily to fetch what's needed.

Architecture.

Power Platform / Dynamics 365
        |
        v
Microsoft cloud (gateway service)
        |
        v
Customer Azure VNet
   subnet for gateway
        |
        v
Customer private resources

The gateway is provisioned in the customer's VNet but operated by Microsoft. The customer controls the VNet, the NSG rules, the resources it accesses; Microsoft operates the gateway runtime.

Configuration.

1. Customer Azure subscription has a VNet with appropriate routing.
2. A subnet is dedicated for the gateway.
3. Subnet is delegated to Microsoft.PowerPlatform/vnetaccesslinks.
4. In Power Platform admin, the gateway is created referencing the VNet/subnet.
5. Data sources in the VNet are added to the gateway's connections.
6. Power Apps, flows, and Power BI reports use the gateway to reach the private resources.

The setup is mostly Azure VNet plumbing plus a Power Platform reference.

Use cases.

• Azure SQL with private endpoint — public access disabled; gateway reaches via private endpoint.
• Azure Function with VNet integration — internal logic accessible to Power Automate.
• Private Azure Storage — files in storage accounts without public access.
• Azure Cosmos DB private — private endpoints.
• Custom Azure-hosted APIs — internal services accessible only inside VNet.
• On-prem via ExpressRoute — if VNet is connected to on-prem via ExpressRoute, gateway reaches on-prem resources too.

Comparison with on-premises gateway.

| Aspect | On-prem gateway | VNet gateway | |---|---|---| | Hosting | Customer Windows server | Microsoft managed | | Patching | Customer | Microsoft | | Scaling | Manual / replica | Auto | | HA | Cluster of installs | Built-in | | Data path | Through customer infrastructure | Through Azure | | Use case | On-prem databases | Azure VNet resources |

VNet gateway is the modern path for Azure-resident private resources; on-prem gateway remains for true on-prem data.

Authentication and authorisation.

• Power Platform / Dynamics user authenticates to Power Platform.
• Gateway authenticates to data source (SQL credentials, managed identity, OAuth).
• Identity flow depends on connector — some support pass-through, some require fixed credentials.

For SQL access, the cleanest pattern is managed identity for the gateway connecting to SQL.

Performance.

• Throughput — comparable to direct connections.
• Latency — slight added latency from cross-region or VNet routing.
• Connection pooling — gateway maintains connection pools.

For high-volume queries, gateway performance is reasonable; bulk data movement still benefits from ADF or other dedicated tools.

Networking specifics.

• NSG rules — control what the gateway subnet can reach.
• Private endpoints — point to specific resources without public routing.
• DNS — Azure Private DNS Zones for name resolution.
• Service endpoints — for some Azure services if needed.

VNet design matters; misconfigured networking gives confusing errors.

Monitoring.

• Connection health — visible in Power Platform admin.
• Query metrics — request counts, latency.
• Errors — connection failures logged.

The managed gateway has better observability than the on-prem alternative; Azure-native logs.

Common pitfalls.

• NSG too restrictive. Gateway can't reach target; cryptic errors.
• Wrong subnet delegation. Subnet not delegated to Power Platform service; gateway provisioning fails.
• Private endpoint DNS broken. Gateway resolves to public IP, doesn't find resource; private DNS zones needed.
• No high availability planning. Single gateway; outage affects all dependent flows.
• Connection limits. Many flows hitting the same gateway; throttling.
• Cost surprise. VNet gateway has hourly cost; budget.

Cost. VNet gateway is paid per gateway hour:

• Reasonable for moderate usage.
• Multiple gateways multiply cost.
• Compare to on-prem gateway (free, but Windows server cost).

For Azure-resident workloads, VNet gateway often wins on TCO once Windows server admin is included in on-prem gateway cost.

Migration from on-prem gateway.

• Add VNet gateway alongside.
• Reconfigure connections to use VNet gateway.
• Validate flows still work.
• Decommission on-prem gateway.

Migration is gradual; both can coexist during transition.

Strategic positioning. The VNet data gateway is Microsoft's path forward for Power Platform / Dynamics 365 private network access. For new deployments where data sits in Azure VNets, it's the default. For existing on-prem gateway deployments, evaluate moving to VNet gateway as Azure infrastructure modernises.

The benefit isn't transformative — connections work either way — but operational simplicity (no Windows servers, no patching, no clustering) compounds over time. For modern, Azure-centric data architectures, the VNet gateway removes a longstanding piece of customer-managed infrastructure. Worth adopting for new work; worth migrating to gradually for existing.