Power Platform の Azure Virtual Network サポート (サブネット委任) がパブリックプレビューとなっています。この機能を使うことで　Power Platform から Azure の仮想ネットワークに閉じた環境へ接続できるようになります。
以前からオンプレミスデータゲートウェイを利用することで Azure 上の仮想ネットワーク上のリソースへの接続も実現できていましたが、Azure VM で構成する必要があり、Azure 用のマネージドコネクタが使えない等の制限がありました。

この機能を利用することで Power Platform に仮想ネットワークのサブネットを委任できるようになり、オンプレミスデータゲートウェイを利用せずに、Azure の仮想ネットワーク上のリソース (仮想マシン、プライベートエンドポイント、ロードバランサー等) にアクセスできます。
設定手順や留意点等をまとめてみましたのでご利用の際はご一読いただければ幸いです。

Power Platform からの Azure へのアクセス経路

Power Platform から Azure へ接続するシナリオは様々なので、要件に応じて接続方法と利用するサービスを選ぶ必要があります。
以下によくある接続シナリオをまとめてみました。

接続サービス	ネットワーク	サポートされる主な Power Platform のサービス
なし	パブリック	すべて
API Management	パブリック	Power Automate, Power Apps
オンプレミスデータゲートウェイ	プライベート (Azure からのアウトバウンド通信のみ)	Power Automate, Power Apps, Power BI
仮想ネットワークデータゲートウェイ	プライベート (Azure からのアウトバウンド通信のみ)	Power BI
Azure VNet サポート (サブネット委任)	プライベート	Power Automate, Power Apps

Virtual Network サポートの構成図

以下のような構成で動作確認を行っています。20240412 時点ではなぜか私の環境では、日本で作成した環境がうまく動かなかったため、US の仮想ネットワークと Power Platform の環境を利用しています。

考慮事項

Azure の仮想ネットワークはペアリージョンも必要になる。日本であれば JapanEast, JapanWest、米国であれば EastUS, WestUS の両方のリージョンで作った仮想ネットワークが必要になる。　※テスト/開発用途の場合、ペアリージョンは利用せず、1 つの仮想ネットワークで 2 つのサブネットを構成することも可能な模様。
パブリックのエンドポイントに接続する場合は、Azure Firewall や Nat Gateway を使いアウトバウンド接続をできるようにしておく必要あり。
一部のコネクタのみのサポート。サポートされているコネクタの一覧はこちら。
サポートされていないコネクタを利用した場合はサブネットを経由せず、通常のネットワーク経路になる模様。
Power Platfrom の環境単位でサブネット委任が反映されるため、既存の環境への適用は注意が必要。
ライセンス体系は未定

Virtual Network サポートの設定手順

事前準備

構成図のように仮想ネットワーク、サブネットをそれぞれ作成しておく ※サブネット委任用のサブネットは /24 以上で作成
接続確認用に Azure OpenAI Service, Azure Storage, Azure SQL Database を作成しておく
それぞれの PaaS でプライベートエンドポイントと Private DNS Zone を作成し、サブネット委任用の仮想ネットワークに Private DNS ゾーンをリンクしておく
Azure サブスクリプションの管理者権限 (所有者、共同作成者等) で Microsoft.PowerPlatform のリソースプロバイダーを登録しておく

1. 権限の付与

作業するユーザーに Azure, Power Platfrom 用の権限を付与します。両方の権限が必要となるため同一ユーザーでの作業が望ましいです。

サービス	必要な権限	備考
Azure リソースプロバイダーの登録	管理者権限 (所有者、共同作成者等)	事前準備で実施
Azure サブネットの設定、ポリシーの作成	ネットワーク共同作成者, "Microsoft.Resources/deployments/validate/action", "Microsoft.PowerPlatform/enterprisePolicies/write", "Microsoft.PowerPlatform/enterprisePolicies/read"	カスタムロールを使わない場合、"共同作成者" でも可
Power Platfrom	Power Plaftform 管理者

Azure 側の権限 (Azure Portal から設定) ※カスタムロールを使用しない場合の例

Power Platform 側の権限 (Azure Portal の Entra ID から設定)

2. Azure 側の設定

2-1. クライアント端末の準備

Windows 端末で Azure Powershell と Power Platform の Powershell を使えるようにしておきます。

以下の Git のファイル群を Git Clone または Zip でダウンロードして端末に保存します。
https://github.com/microsoft/PowerApps-Samples

ダウンロードした Zip を任意の場所に解凍します。

2-2. リソースプロバイダーの登録

サブスクリプションの管理者権限があるユーザーで Azure Portal にログインし、サブスクリプションのリソースプロバイダーの画面で "Microsoft.PowerPlatform" を選択し、登録をクリックします。

2-3. サブネットの委任設定

ネットワーク共同作成者があるユーザーで Azure Portal にログインし、EastUS に作成した仮想ネットワークのサブネット設定を開き、"サブネットをサービスに委任" で "Microsoft.PowerPlatform/enterprisePolicies" を選択し保存します。同様の設定を、WestUS に作成した作成した仮想ネットワークでも実施します。

以下の公開情報ではスクリプトを使ってますが、上記手順でも設定可能です。

2-4. Enterprise Policy の作成

Powershell でダウロードしたフォルダ内の "powershell\enterprisePolicies\SubnetInjection" のフォルダに移動します。

cd C:\xxxx\xxxx\PowerApps-Samples-master\powershell\enterprisePolicies\SubnetInjection

仮想ネットワークがあるサブスクリプションを指定します。

Update-AzConfig -DefaultSubscriptionForLogin cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630

Enterprise Policy を作成するためのスクリプト (CreateSubnetInjectionEnterprisePolicy.ps1) を実行します。

項目	設定値	備考
subscriptionId	仮想ネットワークがあるサブスクリプション ID
resourceGroup	ポリシーを配置するリソースグループ
enterprisePolicyName	ポリシー名
enterprisePolicylocation	ポリシーを配置する国	例: japan,unitedstates
primaryVnetId	VNet の ID (プライマリ)	例 : EastUS の VNet
primarySubnetName	サブネット委任用のサブネット名 (プライマリ)
secondaryVnetId	VNet の ID (セカンダリ)	例 : WestUS の VNet
secondarySubnetName	サブネット委任用のサブネット名 (セカンダリ)

.\CreateSubnetInjectionEnterprisePolicy.ps1

cmdlet CreateSubnetInjectionEnterprisePolicy at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
subscriptionId: cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630
resourceGroup: rg-spoke-ppsubnet-1
enterprisePolicyName: vnet-pptest-entpolicy-001
enterprisePolicylocation: unitedstates
primaryVnetId: /subscriptions/cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630/resourceGroups/rg-spoke-ppsubnet-1/providers/Microsoft.Network/virtualNetworks/vnet-eus-pptest-001
primarySubnetName: PP-EUS-Subnet
secondaryVnetId: /subscriptions/cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630/resourceGroups/rg-spoke-ppsubnet-1/providers/Microsoft.Network/virtualNetworks/vnet-wus-pptest-001
secondarySubnetName: PP-WUS-Subnet

[オプション] Powershell 実行時に以下のようなエラーが出た場合、Powershell の実行ポリシーを変更する必要があります。

xxx is not digitally signed. You cannot run this script on the current system.

上記のエラーが出た場合、以下のコマンドにて Powershell の実行ポリシーを変更します。

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

スクリプトが成功すると以下のように出力されます。
出力結果の "ResourceId" を後ほど使うためメモしておきます。

Logging In...
Logged In...
Creating Enterprise policy...
Subnet Injection Enterprise policy created
Policy created
{
    "ResourceId":  "/subscriptions/cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630/resourceGroups/rg-spoke-ppsubnet-1/providers/Microsoft.PowerPlatform/enterprisePolicies/vnet-pptest-entpolicy-001",
    "Id":  "/subscriptions/cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630/resourceGroups/rg-spoke-ppsubnet-1/providers/Microsoft.PowerPlatform/enterprisePolicies/vnet-pptest-entpolicy-001",
    "Identity":  null,
    "Kind":  "NetworkInjection",
    "Location":  "unitedstates",
    "ManagedBy":  null,
    "ResourceName":  "vnet-pptest-entpolicy-001",
    "Name":  "vnet-pptest-entpolicy-001",
~~省略~~
    "CreatedTime":  null,
    "ChangedTime":  null,
    "ETag":  null
}

3.Power Platform 側の設定

3-1. 環境の作成

サブネット委任の設定は Power Platform の "環境" 単位で行われますので、検証用に新しく環境を作成します。
Power Platform 管理センターに同じユーザーでログインし、[環境] -> [新規] をクリックし、[名前]、[地域]、[種類] 等を適宜設定し、保存します。

作成した環境を選択し、"環境 ID" をメモしておきます。

3-2. サブネット委任の設定実施

サブネット委任を設定するための (NewSubnetInjection.ps1) を実行します。

environmentId は先ほどメモした、"環境ID"、policyArmId は先ほどメモした "ResourceId" です。

.\NewSubnetInjection.ps1

cmdlet NewSubnetInjection at command pipeline position 1
Supply values for the following parameters:
environmentId: 825cb1e0-xxxx-xxxx-b407-7a99fbd6e21a
policyArmId: /subscriptions/cdf800d0-xxxx-xxxx-xxxx-2d72a5e63630/resourceGroups/rg-spoke-ppsubnet-1/providers/Microsoft.PowerPlatform/enterprisePolicies/vnet-pptest-entpolicy-001
Logging In...
WARNING: The names of some imported commands from the module 'Microsoft.PowerApps.AuthModule' include unapproved verbs
that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again
 with the Verbose parameter. For a list of approved verbs, type Get-Verb.
Logged In...
Environment reterieved

Enterprise Policy reterieved

Linking of vnet policy started for environement 825cb1e0-7787-ee40-b407-7a99fbd6e21a
Do you want to poll the linking operation (y/n)

Polling the link operation every 5 seconds.
Operation finished with state Succeeded

Power Platform 管理センターから該当の環境を開き、最近の操作にて "New Network Injection Policy" の状態が "成功" となっていることを確認します。

動作確認

Private Endpoint 経由で接続

Azure SQL Database

SQL Database 用の接続を Microsoft Entra 認証にて作成します。(事前に SQL Server 側で認証設定済み)

以下のような簡易なフローを作り、パブリックアクセスが無効となっている SQL Database からテーブルを取得します。

参考：SQL Server 側のネットワーク設定

プライベートエンドポイントは設定済み

サンプル DB 内のテーブルを取得できました。

カスタムコネクタ + Azure OpenAI Service

Power Automate, Power Apps と組わせて利用するシナリオが多い OpenAI Service への接続をカスタムコネクタで実施してみます。

以下のようなシンプルなカスタムコネクタを作成し、Azure OpenAI Service に接続します。

パブリックアクセスは無効にされている環境ですが、OpenAI Service から応答が正しく返ってきました。

サービスエンドポイント経由で接続

Azure Queue Storage

Azure Storage はグローバルのサービスエンドポイントの利用がサポートされているので Azure Storage へのサービスエンドポイントでのアクセスも試してみます。

Storage アカウントを作成し、サブネット委任が設定されている二つのサブネットをストレージのファイアウォールで許可します。

テスト用にキューにサンプルデータを入れておきます。

サービスエンドポイント経由でデータを取得することができました。

NSG

対象のサブネットに NSG を設定し、通信制御を試してみます。試しにアウトバウンド通信をすべて拒否します。

SQL Server に接続できなくなりましたので NSG の設定は効いているようです。

複数環境から同じサブネットを共有

以下のような文言が公開情報に記載があることから、複数の Power Platform の環境から同じサブネットを共有して利用することはサポートされていそうです。
試しに動作確認もしてみましたが、問題なく利用できました。

同じサブネットを複数の環境に委任するには、そのサブネット内でさらに多くの IP アドレスが必要です。

その他のネットワーク構成 (Hub & Spoke + Azure Firewall)

Hub VNet にサブネットを追加する構成も可能だと思いますが、既存環境の場合、Hub VNet の拡張が難しかったり、共有基盤である Hub に手を入れたくないといった要件もあると思いましたので、以下のような構成で Spoke VNet としてサブネット委任用の VNet を追加して接続を試してみましたが、問題なく利用可能でした。UDR も問題なく動作しているようです。

サブネット委任が設定されたアドバイス空間から SQL Server のプライベートエンドポイントへの通信が Azure Firewall のログとしても記録されていました。