Architecture of Azure VNet support for Power Platform

Did you know Azure VNet support for Power Platform? This new feature was released in 2024 and uses Azure subnet delegation to integrate Power Platform with your Azure Virtual Network without exposing it on the public internet. Of course, the network connection is limited to the specific users in the Power Platform environment.

Virtual Network support overview

virtual network support whitepaper

In this blog, I'll share some architectures and tips about how to connect privately to On-premises or Azure from Power Platform. Additionally, subnet delegation supports Dataverse, however I'll only focus on connectors for Automate or Apps in this blog as those are the most frequent scenarios.

What is the benefit of using subnet delegation?

Once we enable this feature, we can connect to Azure virtual networks via private IP addresses. Before this feature was released, on-premises data gateway was the alternative way connecting to on-premises or Azure internally. However, there are some concerns detailed below when using on-premises data gateway.

• There are limitations such as payload size or request size. Link
• Users must configure and manage the cluster of multiple servers of on-premises data gateway.
• We are limited to SQL and custom connectors connecting to Azure. Subnet delegation supports SQL, Custom, Azure Queues, Key Vault, BLOB Storage. etc. Link
• Entra ID authentication is not supported.
• When we create a new connection of custom connector with on-premises data gateway, the user must have administrator privilege. Link
  • "The gateway must be shared with the Admin permission level to be used by custom connectors."

Below is the difference of architecture between subnet delegation and on-premises data gateway.

• On-premises data gatewa

• Subnet delegation

How to set up Virtual Network support for Power Platform

Please reference this document.

Set up Virtual Network support for Power Platform

There are some requirements listed below.

• Managed Environment.
• At least two /24 address spaces.
• Supported regions (Link) If your Power Platform region is the United States, your Virtual Network and subnets must be in the eastus and westus Azure regions.

Sample architectures

These are sample architectures utilizing subnet delegation.

From Azure VNet to Internet

• Connect to Internet via Azure NAT Gateway
  • This is region redundant.
  • There is no traffic log.
  • Source IP addresses are static.

• Connect to Internet via Azure Firewall in a region
  • This is not region redundant.
  • Azure Firewall controls network traffic.
  • We can view traffic logs on Azure Firewall.
  • Source IP address is static.

• Connect to Internet via Azure Firewall in each region
  • This is region redundant.
  • Azure Firewall controls network traffic.
  • We can view traffic logs on Azure Firewall.
  • Source IP addresses are static.

From Azure VNet to On-premises

• This is not region redundant.
• Azure Firewall is optional.

From Azure VNet to Azure resources

• Set up all private endpoints in each region
  • This is region redundant.
  • There is no traffic log.
  • You are required to divide the resource group and Private DNS Zones because its resource name will be same.

• Set up all private endpoints in a region and use VNet peering
  • This is not region redundant.
  • There is no traffic log.
  • You must be careful to not utilize overlapping or duplicate address space.

• Uses service endpoint
  • This is region redundant.
  • There is no traffic log.
  • For Azure SQL Database, virtual networks must be in the same region as the Azure SQL Database so for our example, this architecture is not supported. (Link) Please check and confirm your desired architecture is supported prior to beginning deployment.

• Hub & Spoke with Azure Firewall
  • This is not region redundant.
  • Azure Firewall controls network traffic.
  • We can view traffic logs on Azure Firewall.

Name resolution

Subnet delegation supports custom DNS on Azure Virtual Networks so we can use any of the below DNS options.

• Azure provided DNS (168.63.129.16). This is default setting.
• Azure private DNS zones.
• DNS Server on Azure or on-premises. Forwarder is optional.

If you would like to use custom DNS on Azure Virtual Network, please reference this document. Change DNS servers of a virtual network using the Azure portal

Network traffic control

Subnet delegation supports to use NSG or Azure Firewall (NVA) to control outbound traffic from the subnets.

Network traffic log

Azure services using subnet delegation such as AppService don't support NSG flow log. Incompatible services

"App services deployed under an Azure App Service plan don't support NSG flow logs. To learn more, see How virtual network integration works."

Private endpoint is also not supported by NSG and VNet flow logs.

Private endpoint traffic

"Traffic can't be recorded at the private endpoint itself. "

That's why I recommend you use Azure Firewall if traffic logs from the virtual network are required.

How to minimize the number of IP addresses

Some Azure environments are connected to on-premises and sometimes the number of IPv4 Addresses are not enough in them but Azure VNet support requires at least two /24 address spaces. For such users, I recommend that you use Azure Firewall with SNAT. You can mask the private IP address for subnet delegation, so you don't need to worry about the number of IP addresses. In this scenario, you need to disable 'Use Remote Gateway' on the VNet peering to not advertise the address spaces.

Azure Firewall SNAT private IP address ranges

Virtual network peering