Designing Power Automate Network-Level Isolation: Configuring Virtual Network Data Gateways, Private Endpoints, and Managed Connector Egress for Zero-Trust Enterprise Environments

Introduction

Your Power Automate flows reach into Azure SQL databases, SharePoint Online, on-premises ERP systems, and dozens of other data sources throughout the day. In a default configuration, every one of those connections traverses the public internet — authenticated, yes, but exposed to the same network surface that attackers probe constantly. For most SaaS workloads, that's an acceptable trade-off. For a healthcare organization synchronizing patient records, a bank reconciling financial transactions, or a defense contractor moving controlled unclassified information, it is not acceptable at all. The question isn't whether your credentials are strong; the question is whether your data ever travels across a network segment you don't own.

Zero-trust networking for Power Automate means more than requiring MFA at sign-in. It means controlling where flows connect from, which network paths data travels through, which connectors are permitted to egress, and how you verify every hop between the Microsoft cloud and your private infrastructure. Microsoft has built several interlocking mechanisms to make this possible: Virtual Network Data Gateways, which inject your flows directly into a subnet you control; Private Endpoints on Azure services, which pull those services off the public internet entirely; and Managed Connector Egress policies, which constrain which connectors can make outbound calls and from what network context. Used together, they give you a security posture your compliance auditors will actually accept.

By the end of this lesson, you'll be able to design and implement a complete network isolation architecture for production Power Automate environments. You won't just know the feature names — you'll understand why each mechanism exists, what it can and can't protect, and how they fit together into a coherent zero-trust strategy.

What you'll learn:

• How Virtual Network Data Gateways differ architecturally from traditional on-premises gateways and when each is appropriate
• How to provision a VNet Data Gateway, inject it into a subnet, and configure it for high availability
• How to place private endpoints on Azure SQL, Azure Storage, Event Hubs, and Key Vault so connector traffic never touches the public internet
• How Managed Connector Egress policies work and how to enforce them through the Power Platform Admin Center and DLP policy layers
• How to validate and audit your network isolation configuration, including common misconfiguration patterns that create silent security gaps

Prerequisites

You should be comfortable with:

• Power Platform environment administration and DLP policy authoring (if you need a refresher, see Configuring Data Loss Prevention Policies for Enterprise Cloud Flows)
• Azure Virtual Networks, subnets, NSGs, and basic Azure networking concepts
• Power Automate solution-aware flows and connection references — particularly how connections are scoped to environments (covered in Securing Power Automate Flows in Production: Managing Credentials, Connection References, and Data Loss Prevention Policies)
• Azure RBAC, resource groups, and the Azure portal at an intermediate level

The Architecture Problem: Where Does Your Flow's Traffic Actually Go?

Before configuring anything, you need a clear mental model of the network paths that exist today.

When a cloud flow executes, the flow runtime runs inside Microsoft's managed infrastructure — specifically, within the Power Platform backend services hosted in one of Microsoft's Azure regions. When that flow invokes a connector action (say, "Get rows" against Azure SQL), the connector makes an outbound HTTPS call from Microsoft's infrastructure. The destination could be your Azure SQL server's public endpoint, an on-premises SQL Server reachable through an on-premises data gateway, or — once you've implemented what this article covers — a private endpoint inside your own VNet.

Three distinct traffic paths exist and each has a different security profile:

Public egress to public endpoints. The connector calls your Azure SQL public endpoint over the internet. Authentication protects the data in transit, but the endpoint is publicly reachable. Any compromised credential, any misconfigured firewall rule, any future vulnerability in TLS negotiation represents a threat surface.

On-premises gateway relay. The traditional on-premises data gateway runs an agent inside your network that maintains an outbound relay connection to Azure Service Bus. Connector traffic is routed through that relay. This keeps your firewall ports closed but means traffic traverses Azure's public relay service and requires an agent VM you must patch and operate.

VNet-injected gateway. A Virtual Network Data Gateway runs as a managed Microsoft service injected into a subnet you own. Traffic from the flow runtime enters your VNet through that injection point and reaches your resources over private network paths. This is the modern zero-trust approach.

Understanding this distinction matters because organizations frequently deploy the VNet gateway but leave the public endpoint open "just in case." That defeats the entire architecture.

Virtual Network Data Gateway: Architecture Deep Dive

The VNet Data Gateway is a managed service, which means Microsoft operates the compute — you don't run a VM. Instead, you delegate a subnet to the service, and Microsoft spins up gateway instances within that delegation. This delegation model has specific requirements that catch people off-guard.

Subnet Requirements and Delegation

The subnet you provide must be delegated to Microsoft.PowerPlatform/vnetaccesslinks. This delegation is exclusive: once you delegate a subnet to this service, no other resources can be deployed into it. Plan accordingly — don't try to share this subnet with your AKS node pools or application VMs.

Microsoft recommends a /24 subnet for production workloads, though you can use a /26 (64 addresses) for lower-volume environments. The gateway service consumes IP addresses as it scales horizontally to handle concurrent flow executions, and you cannot predict peak demand precisely. Undersizing your subnet is a common mistake that manifests as connection failures during high-concurrency periods.

The VNet itself must be in the same Azure region as your Power Platform environment. Cross-region VNet gateway configurations are not supported, which has real architectural implications: if your Power Platform environment is in East US and your primary VNet is in West Europe, you need a local VNet (possibly connected to your hub via peering) in East US.

Your subnet also needs to reach the Power Platform service endpoints. Even though the gateway is managed, it still needs outbound access to Power Platform control plane services. Specifically, you must allow outbound HTTPS (port 443) to *.powerquery.microsoft.com and *.analysis.windows.net. If your subnet routes all traffic through a firewall (a common hub-spoke pattern), make sure these FQDN rules are in place before testing.

Provisioning a VNet Data Gateway

The provisioning experience lives in the Power Platform Admin Center, not the Azure portal, even though you're configuring something that touches Azure networking. This cross-portal workflow confuses almost everyone the first time.

Navigate to the Power Platform Admin Center, select Data (preview) from the left navigation, then Virtual Network data gateways. Select New to create a gateway.

You'll provide:

• Subscription: the Azure subscription containing your target VNet
• Resource group: the resource group containing the VNet
• VNet: the virtual network itself
• Subnet: the delegated subnet (the portal will warn you if it isn't properly delegated)
• Region: must match both your Power Platform environment region and the VNet region
• Gateway name: a descriptive name — include environment and region in the name (e.g., vnetgw-prod-eastus-01)

After creation, the gateway appears in the Power Platform Admin Center and in the Azure portal under the VNet as a vnetaccesslink resource. It takes a few minutes to provision. During this time, Microsoft is allocating managed compute instances within your delegated subnet.

Associating the Gateway with an Environment

Creating the gateway is only half the work. You must then associate it with a specific Power Platform environment. In the Power Platform Admin Center, navigate to the environment's settings, select Gateways, and assign the VNet gateway to that environment.

Once associated, connectors that support VNet gateways will show the gateway as an option when configuring connections. This is where another subtlety emerges: not every connector supports VNet Data Gateways. The connectors that do include SQL Server, Azure SQL, Azure Blob Storage, Azure Data Lake Storage Gen2, Azure Event Hubs, Azure Service Bus, and several others. Connectors that don't support VNet gateways will continue to use public egress regardless of your configuration.

Run the following PowerShell to list which gateways are associated with a given environment (requires the Power Platform CLI):

# Requires Microsoft.PowerApps.Administration.PowerShell module
Import-Module Microsoft.PowerApps.Administration.PowerShell

Add-PowerAppsAccount

# List all gateways visible to the current admin
Get-AdminPowerAppGateway | Where-Object { 
    $_.GatewayType -eq "Resource" 
} | Select-Object DisplayName, Status, GatewayId, EnvironmentName

This gives you a baseline inventory. If a gateway shows Status: Offline, check subnet delegation and NSG rules first.

High Availability Configuration

A single VNet gateway instance creates a single point of failure. Microsoft automatically scales the managed instances horizontally, but you should create multiple gateways in different subnets — ideally in availability zones — and group them into a cluster for active-active load balancing.

Gateway clusters are configured in the Power Platform Admin Center. You create a primary gateway, then create additional gateway members and add them to the same cluster. All members must use the same region and must be in subnets within the same VNet (or peered VNets that can route between them).

For a production-grade architecture, create two gateways in separate subnets routed to different availability zones within your VNet. Name them vnetgw-prod-eastus-01 and vnetgw-prod-eastus-02, and group them under a cluster named vnetgw-prod-eastus-cluster. Connections reference the cluster, not individual gateways, so failover is transparent.

Private Endpoints: Removing Public Network Exposure from Azure Services

A VNet Data Gateway routes your flow's connector traffic into your VNet, but that traffic still needs somewhere to go. If your Azure SQL server has a public endpoint enabled, the gateway's egress will reach SQL over the public internet (since that's where the SQL endpoint resolves). You need private endpoints to bring the Azure services themselves into your private network.

A private endpoint is an Azure resource that gives an Azure service a private IP address within your VNet. When you create a private endpoint for an Azure SQL server, DNS queries for yourserver.database.windows.net from within your VNet resolve to the private IP — not the public one. Traffic never leaves the Microsoft backbone network.

Setting Up Private Endpoints for Azure SQL

In the Azure portal, navigate to your Azure SQL server, select Networking from the left menu, and choose the Private access tab. Select Create a private endpoint.

You'll configure:

• Resource group and region: use the same resource group as your data resources, same region as your VNet gateway
• Name: pe-sql-prod-eastus-01 (include the service, environment, and region for clarity)
• Resource: your SQL server
• Target sub-resource: sqlServer
• Virtual network and subnet: place the private endpoint in a separate subnet from your gateway — a dedicated private endpoints subnet (e.g., snet-privateendpoints) is cleaner operationally
• Private DNS integration: enable automatic integration with Azure Private DNS Zones (privatelink.database.windows.net)

The private DNS zone integration is critical. Without it, you need to manually manage DNS records. When the endpoint is created, Azure creates an A record in the private DNS zone that maps your SQL server's FQDN to the private IP. Any resource in a VNet linked to that DNS zone — including your VNet gateway's subnet — will resolve to the private address.

After creating the private endpoint, go back to the SQL server's networking settings and disable public network access. This is the step most organizations skip. Disabling public access means that even if an attacker obtains valid credentials, they cannot connect to the SQL server from outside your VNet. Connection attempts from public endpoints are rejected at the network layer before authentication even occurs.

# Disable public access on Azure SQL Server using Azure CLI
az sql server update \
  --resource-group rg-prod-data \
  --name sql-prod-eastus-01 \
  --enable-public-network false

# Verify the change
az sql server show \
  --resource-group rg-prod-data \
  --name sql-prod-eastus-01 \
  --query "publicNetworkAccess" \
  --output tsv
# Expected: Disabled

Private Endpoints for Azure Key Vault

If your flows retrieve secrets from Key Vault — and they should, as described in Integrating Power Automate with Azure Key Vault and Managed Identities — Key Vault must also be behind a private endpoint. The process is identical: create a private endpoint with sub-resource vault, integrate with the privatelink.vaultcore.azure.net DNS zone, and disable public access on the Key Vault after the endpoint is healthy.

Test that the private endpoint resolves correctly from within your network:

# From a VM or Azure Bastion session within the connected VNet
nslookup myvault.vault.azure.net

# Expected output should show resolution through the privatelink CNAME:
# myvault.vault.azure.net -> myvault.privatelink.vaultcore.azure.net -> 10.x.x.x
# The 10.x.x.x address confirms private resolution is working

If you see a public IP in the nslookup output, the DNS zone isn't linked to your VNet correctly. Check that the private DNS zone has a VNet link for your VNet — this is the most common misconfiguration.

Private Endpoints for Azure Event Hubs and Service Bus

Event-driven flows using Azure Event Hubs or Service Bus as triggers — a pattern discussed in depth in Implementing Event-Driven Automation with Power Automate and Azure Service Bus — also need private endpoints if those services contain sensitive data.

For Event Hubs namespaces, the private endpoint sub-resource is namespace. For Service Bus namespaces, it's also namespace. The private DNS zones are privatelink.servicebus.windows.net for both (Event Hubs and Service Bus share the same underlying namespace technology).

One subtlety: Power Automate's trigger mechanism for Service Bus and Event Hubs involves Microsoft's polling infrastructure checking for new messages. Even though the connector action runs through your VNet gateway, the trigger check may originate from Microsoft's infrastructure rather than your VNet. Test this carefully — you may find that even with a VNet gateway configured, trigger polling still requires the namespace to have at minimum a specific IP allowlist that includes Microsoft's connector infrastructure IP ranges, or you need to use the HTTP trigger pattern with a relay to avoid this entirely.

Private DNS Zone Architecture for Hub-Spoke Networks

Most enterprise Azure architectures use a hub-spoke topology where DNS resolution is centralized in the hub VNet through Azure Private DNS Resolver or custom DNS servers. In this pattern, you cannot simply link private DNS zones to each spoke VNet — you link them to the hub VNet and configure the hub's DNS server (or Private DNS Resolver) to forward queries to Azure DNS (168.63.129.16) for private zone resolution.

Your VNet gateway's subnet must route DNS queries through this centralized resolver. If the gateway subnet uses Azure's default DNS (168.63.129.16 directly) but the private DNS zones are only linked to the hub, the gateway won't resolve private endpoints correctly.

Validate your DNS forwarding chain by deploying a test VM in the gateway subnet (temporarily) and running the nslookup tests above. If resolution fails from the gateway subnet but works from the hub, your DNS forwarding conditional rules need to include the privatelink.* FQDN suffixes.

Managed Connector Egress Policies

Even with a VNet gateway and private endpoints in place, you have a gap: connectors that don't support VNet gateways will continue to egress from Microsoft's shared infrastructure. This is where Managed Connector Egress policies come in — they let you control which connectors are permitted to make outbound connections at all.

Understanding Egress Policy Scope

Egress policies operate at the Power Platform environment level and complement your DLP policies. Where DLP policies control data movement between connectors (which connectors can coexist in the same flow), egress policies control network-level access — which connectors can establish outbound connections and under what network conditions.

These policies are configured through the Power Platform Admin Center under Environments → [Environment Name] → Policies → Network policies, or through the Power Platform Admin Center API for programmatic management.

The key policy types are:

Allow all connectors (default): No egress restriction. Connectors use whatever network path they normally would.

Allow only connectors that support VNet: Restricts the environment to only allow connectors that can be routed through a VNet Data Gateway. Connectors that don't support VNet gateways are blocked from running in this environment.

Custom allowlist: Specific connectors are permitted while others are blocked.

Configuring Egress Policies via the Admin API

The Power Platform Admin Center UI for egress policies is functional but limited for at-scale management. For enterprise environments, use the Admin API directly:

# Set a network isolation policy on an environment
# Requires Power Platform Administrator role

$environmentId = "your-environment-id-here"
$apiVersion = "2022-03-01-preview"
$adminBaseUrl = "https://api.bap.microsoft.com"

# Get current isolation policy
$getUri = "$adminBaseUrl/providers/Microsoft.BusinessAppPlatform/scopes/admin/environments/$environmentId/governancePolicies/networkIsolation?api-version=$apiVersion"

$currentPolicy = Invoke-PowerPlatformApiRequest -Method GET -Uri $getUri

# Update to require VNet gateway for supported connectors
$policyBody = @{
    properties = @{
        isolationMode = "AllowedOutboundConnectors"
        allowedConnectors = @(
            "shared_sql",              # SQL Server connector
            "shared_azureblob",        # Azure Blob Storage
            "shared_azuredatalake",    # Azure Data Lake
            "shared_eventhubs",        # Azure Event Hubs
            "shared_servicebus"        # Azure Service Bus
        )
        vnetDataGatewayRequired = $true
    }
} | ConvertTo-Json -Depth 5

$putUri = "$adminBaseUrl/providers/Microsoft.BusinessAppPlatform/scopes/admin/environments/$environmentId/governancePolicies/networkIsolation?api-version=$apiVersion"

Invoke-PowerPlatformApiRequest -Method PUT -Uri $putUri -Body $policyBody

This configuration says: only the listed connectors are permitted in this environment, and those connectors must use a VNet Data Gateway. Any flow attempting to use a connector not on the allowlist — or attempting to use an allowlisted connector without routing through the VNet gateway — will fail at runtime with a policy violation error.

Combining Egress Policies with DLP

Egress policies and DLP policies are complementary, not redundant. Think of DLP as controlling what data can flow between which connectors, and egress policies as controlling which network path that data travels. You need both layers for genuine zero-trust coverage.

A practical layered approach for a regulated environment:

1. DLP policy: Place all business data connectors (SQL, SharePoint, Blob, Event Hubs) in the Business data group. Place consumer-grade connectors in Non-Business or block them entirely. This prevents data from flowing between, say, your production SQL database and a personal Dropbox account.

2. Egress policy: Restrict the environment to VNet-capable connectors only, with VNet gateway required. This ensures that the business-group connectors that are permitted can only connect through your controlled network path.

3. Private endpoints: Disable public access on all Azure services used by those connectors. Even if somehow a connection bypassed the egress policy, it would hit a dead end because the Azure service's public endpoint is closed.

Defense in depth at every layer.

DNS and Certificate Considerations for Zero-Trust Connector Traffic

Once you route connector traffic through your VNet, you also take on responsibility for ensuring that DNS resolution and TLS certificate validation work correctly for all the private endpoints your connectors need to reach.

Split-Horizon DNS

A common advanced pattern is split-horizon DNS, where the same FQDN resolves to different IP addresses depending on where the query originates. Clients on the public internet resolve sql-prod-eastus-01.database.windows.net to the public endpoint IP. Clients inside your VNet (including your gateway) resolve it to the private endpoint IP (e.g., 10.10.4.5).

Azure Private DNS Zones implement this naturally — they only respond to queries from VNets linked to the zone. You don't need separate DNS servers or complex configuration. But if you have an on-premises network connected to Azure via ExpressRoute or VPN, and you want on-premises clients to also use private endpoints, you need to configure your on-premises DNS to forward queries for privatelink.database.windows.net to Azure's DNS. This is typically done through Azure Private DNS Resolver with inbound endpoints that accept queries from on-premises.

TLS Inspection and the Gateway

Some enterprises route all egress traffic through a firewall appliance that performs TLS inspection. This works by terminating the TLS connection at the firewall, inspecting the decrypted traffic, and re-encrypting it with the firewall's certificate.

TLS inspection creates problems with the VNet Data Gateway if the gateway's connection to Microsoft's control plane encounters an untrusted certificate injected by the firewall. You'll typically see SSL_ERROR_RX_RECORD_TOO_LONG or certificate validation failures in gateway diagnostics. The solution is to either exclude the gateway's control-plane FQDNs from TLS inspection (*.powerquery.microsoft.com, *.analysis.windows.net), or to push your firewall's CA certificate into the trusted root store — but since the VNet gateway is a managed service and you don't control its trust store, exclusion is the only practical option.

Auditing and Validating Your Network Isolation Configuration

Building the architecture is one thing; proving it works is another. Your compliance team will want evidence that traffic is actually flowing through the private path, not just that the configuration appears correct.

Network Watcher Flow Logs

Enable NSG flow logs on your gateway subnet's NSG. These logs capture every network flow through the NSG, including source IP, destination IP, port, and allow/deny decision. Store them in a storage account with private endpoint access, and route them to a Log Analytics workspace for querying.

// Query NSG flow logs to verify gateway traffic patterns
// Run in Log Analytics Workspace associated with your NSG flow logs

AzureNetworkAnalytics_CL
| where TimeGenerated > ago(24h)
| where SubType_s == "FlowLog"
| where NSGList_s contains "nsg-vnetgateway-subnet"
| project 
    TimeGenerated,
    SourceIP = SrcIP_s,
    DestinationIP = DestIP_s,
    DestPort = DestPort_d,
    FlowDirection = FlowDirection_s,
    AllowedDenied = AllowedInFlows_d
| where DestPort == 1433  // SQL Server port
| summarize 
    ConnectionCount = count(),
    UniqueDestinations = dcount(DestinationIP)
  by bin(TimeGenerated, 1h), FlowDirection
| order by TimeGenerated desc

If you see SQL connections (port 1433) with destination IPs in your private endpoint range (e.g., 10.10.4.x), traffic is flowing through the private path. If you see destination IPs in Azure's public SQL ranges, something is wrong.

Verifying No Public Endpoint Access

A simple validation test: temporarily connect to your Azure SQL server from outside your VNet using the correct credentials. If your private endpoint and public access disable are correctly configured, the connection should fail with a network connectivity error, not an authentication error. An authentication error means the public endpoint is still reachable.

# Test script to verify Azure SQL is unreachable from public internet
# Run this from a machine OUTSIDE your VNet (e.g., your laptop)
import pyodbc

connection_string = (
    "Driver={ODBC Driver 17 for SQL Server};"
    "Server=sql-prod-eastus-01.database.windows.net,1433;"
    "Database=ProdDB;"
    "Authentication=ActiveDirectoryInteractive;"
    "Encrypt=yes;"
    "TrustServerCertificate=no;"
    "Connection Timeout=10;"
)

try:
    conn = pyodbc.connect(connection_string)
    print("FAIL: Connection succeeded - public endpoint is still accessible!")
    conn.close()
except pyodbc.Error as e:
    error_code = e.args[0]
    if "08001" in str(error_code) or "TCP Provider" in str(e):
        print("PASS: Connection failed at network level - public endpoint is blocked")
    else:
        print(f"UNEXPECTED: {e}")
        # Auth failure means endpoint is reachable but credentials wrong
        # Network failure means endpoint is properly blocked

Power Platform Admin Center Audit Logs

Every gateway connection and environment policy change is recorded in the Microsoft 365 audit log. Query these logs through the Security and Compliance Center or through the Management Activity API to detect unauthorized gateway configuration changes:

# Search for VNet gateway configuration events in audit log
Search-UnifiedAuditLog `
    -StartDate (Get-Date).AddDays(-7) `
    -EndDate (Get-Date) `
    -RecordType PowerPlatformAdministration `
    -Operations @(
        "CreateGateway",
        "DeleteGateway",
        "UpdateGateway",
        "AddGatewayClusterMember",
        "UpdateNetworkIsolationPolicy"
    ) `
    -ResultSize 100 | 
    Select-Object CreationDate, UserIds, Operations, AuditData | 
    Format-Table -AutoSize

Include these audit events in your Building a Power Automate Monitoring and Alerting System alerting framework — specifically, alert on gateway deletions and egress policy changes in production environments.

Hands-On Exercise: Building an End-to-End Isolated Flow

Let's put everything together with a realistic scenario. You're building a flow that reads sensitive financial records from Azure SQL (behind a private endpoint), enriches them with reference data from Azure Blob Storage (also private), and then publishes results to an Azure Service Bus topic for downstream consumers. Nothing should traverse the public internet.

Step 1: Prepare the VNet.

Create or identify a VNet in your Azure subscription in the same region as your Power Platform environment. Add two subnets:

• snet-vnetgateway: /24, delegated to Microsoft.PowerPlatform/vnetaccesslinks
• snet-privateendpoints: /26, no delegation

Add NSGs to both subnets. The gateway subnet NSG should deny all inbound from internet and allow outbound 443 to PowerPlatformInfra and AzureCloud service tags.

Step 2: Create private endpoints.

Create private endpoints for:

• Azure SQL server → sub-resource sqlServer → DNS zone privatelink.database.windows.net
• Azure Storage account → sub-resource blob → DNS zone privatelink.blob.core.windows.net
• Service Bus namespace → sub-resource namespace → DNS zone privatelink.servicebus.windows.net

All in snet-privateendpoints. All DNS zones linked to your VNet.

After creating each endpoint, disable public network access on the respective Azure service.

Step 3: Create the VNet Data Gateway.

In Power Platform Admin Center → Data → Virtual Network data gateways → New:

• Select your subscription, VNet, and snet-vnetgateway subnet
• Name: vnetgw-prod-eastus-01

Wait for provisioning to complete (usually 3-5 minutes). Assign it to your production Power Platform environment.

Step 4: Create connections using the VNet gateway.

In Power Automate, go to Data → Connections → New connection → SQL Server. Configure the connection with your SQL server's FQDN and credentials. In the gateway section, select your VNet gateway cluster rather than "Connect directly (cloud services)."

Repeat for Azure Blob Storage and Azure Service Bus connections, selecting the VNet gateway in each.

Step 5: Build and test the flow.

Build a scheduled flow that:

1. Uses SQL Server "Execute a SQL query" to retrieve records from your private SQL database
2. Uses Azure Blob Storage "Get blob content" to retrieve a reference data file
3. Applies your business logic
4. Uses Service Bus "Send message" to publish results

Run the flow manually and examine the run history. Each action should succeed. Verify in your NSG flow logs that the connections show private IP destinations.

Step 6: Apply the egress policy.

In Power Platform Admin Center, navigate to the environment's network policies and configure:

• Isolation mode: Allow only connectors that support VNet gateways
• VNet gateway required: Yes

Test the flow again — it should still succeed because all three connectors (SQL, Blob, Service Bus) are VNet-capable. Now create a test flow using the HTTP connector (which doesn't support VNet gateways) — it should fail with a policy violation, confirming the egress policy is active.

Common Mistakes & Troubleshooting

Mistake 1: Gateway is Online but Connections Time Out

Symptom: The gateway shows "Online" in the Admin Center but flow actions using the gateway connection return timeout errors.

Cause: Usually NSG rules blocking outbound traffic from the gateway subnet. The gateway needs 443 to Power Platform control plane endpoints. If your subnet routes through Azure Firewall, check that FQDN application rules for *.powerquery.microsoft.com exist and are hitting the "Allow" rule in firewall logs.

Fix: Add an Azure Firewall application rule:

• Rule collection priority: 100
• Rule name: allow-powerplatform-gateway
• Source: gateway subnet CIDR
• Protocol: HTTPS:443
• FQDNs: *.powerquery.microsoft.com, *.analysis.windows.net, *.servicebus.windows.net

Mistake 2: Private Endpoint Created but DNS Still Resolves to Public IP

Symptom: nslookup from within the VNet returns a public IP for your Azure SQL FQDN.

Cause: The private DNS zone isn't linked to your VNet, or your subnet is using a custom DNS server that doesn't forward to Azure DNS.

Fix: In the Azure portal, open the private DNS zone privatelink.database.windows.net → Virtual network links → Add link → select your VNet. If you have a custom DNS server, add a conditional forwarder for privatelink.database.windows.net pointing to 168.63.129.16 (Azure DNS).

Mistake 3: Egress Policy Breaks Existing Flows Silently

Symptom: After enabling egress policy, some flows fail with generic errors rather than clear policy violation messages.

Cause: The flow uses a connector not in the allowlist, but the error message from the connector doesn't clearly indicate a policy block.

Fix: Before enabling egress policies, use the CoE Toolkit's connector analytics to audit every connector in use across the environment. Export this list, compare against VNet-compatible connectors, and plan remediation for any gaps. Consider using a staging environment to test the policy impact before applying to production — a practice aligned with the Environment Strategy for Power Platform discussed in that lesson.

Mistake 4: Flow Trigger Stops Firing After Network Isolation

Symptom: After enabling VNet gateway and disabling public endpoints on Service Bus, the flow no longer triggers on new messages even though the action-based connections work fine.

Cause: Trigger polling for some connectors originates from Microsoft's shared infrastructure, not through the VNet gateway. Disabling public access blocks the polling infrastructure.

Fix: Add the PowerPlatformInfra service tag to your Service Bus namespace's network rules (even with private endpoint enabled, you can add IP-based firewall exceptions). Alternatively, refactor the trigger to use an HTTP request trigger combined with a relay mechanism that runs within your VNet.

Mistake 5: Multiple Environments Sharing One Gateway Subnet

Symptom: Gateway performance degrades during peak hours across all environments.

Cause: Multiple Power Platform environments assigned to the same VNet gateway cluster. Gateway instances compete for the fixed IP space in the subnet.

Fix: Deploy separate gateway clusters for separate environments (dev, test, prod). Each environment gets its own delegated subnet and gateway cluster. This isolates noisy-neighbor effects and provides clearer blast radius for any gateway-level incidents. Since this is a networking resource, treat it like any other production infrastructure — separate it by tier.

Summary & Next Steps

Network-level isolation for Power Automate isn't a single feature — it's a three-layer architecture that you have to design and validate end-to-end. The VNet Data Gateway controls where your connector traffic originates from in the network. Private endpoints control where it terminates, removing Azure services from the public internet entirely. Egress policies control which connectors are even permitted to establish connections, creating a network-level enforcement layer that complements your DLP policies.

The key principles to carry forward:

• Disabling the public endpoint matters. A private endpoint without disabling public access is defense in depth theater — the private path exists but the public path remains open.
• DNS is the silent dependency. The most common failure mode in private endpoint deployments is DNS misconfiguration. Test name resolution explicitly from the gateway subnet, not just from other VNet resources.
• Egress policies and DLP are complementary. DLP governs data movement between connectors; egress policies govern network paths. You need both.
• Validate, don't just configure. Use NSG flow logs and deliberate negative tests (attempting public connections that should fail) to confirm your architecture is actually working as intended.

From here, several adjacent topics will round out your enterprise security architecture. Implementing Connection References in Power Automate Solutions explains how to manage the credential layer on top of the network layer you've just built — specifically how connection references propagate through solution deployments without exposing credentials. For compute-heavy operations that your flows hand off to Azure Functions running inside your VNet, see Integrating Power Automate with Azure Functions for Compute-Heavy Workloads — those Functions can be VNet-integrated as well, maintaining your private network boundary end-to-end.

On-premises workloads that haven't yet migrated to Azure are a separate but related concern. On-Premises Data Gateway Clusters: High Availability and Load Balancing for Enterprise Flows covers how to secure and scale the traditional gateway for systems that must stay on-premises, and how it complements the VNet gateway for hybrid architectures.

The network isolation architecture you've built here is a significant security control, but it's one layer of a full zero-trust implementation. Pair it with managed identity authentication (so connector credentials themselves are never static secrets), DLP policies that constrain data movement at the logical layer, and audit logging that gives you visibility into everything happening inside the boundary you've just constructed.