Power Platform に ExpressRoute を使用することを決定したら、次のステップでは展開を計画します。 この記事では、前提条件と考慮事項に関するガイダンスを提供します。
ExpressRoute を使用するための前提条件
ExpressRoute には特定の前提条件が必要です。 これらの計画を怠ると、予期しないコストが発生したり、プロジェクトが中断されたり、他のサービスの運用に影響を与えたりする可能性があります。
接続プロバイダーが設定する物理的な接続。 ExpressRoute は物理的な接続自体を提供しません。 代わりに、接続プロバイダーによって設定される必要がある確立された物理接続を介してプライベート接続を提供します。 ExpressRoute パートナーとの物理的接続は、いくつかの方法で確立することができます。 詳細情報については、ExpressRoute のドキュメントとご利用の地域のパートナー リストをご確認ください。.
Azure サブスクリプション。 このサブスクリプションの ExpressRoute サーキットのプロビジョニング、構成、請求。
展開の計画
計画の一環として、以下の要素を考慮してください:
地理: 地理的にどこで接続する必要があるかを理解します。
費用: 接続プロバイダーは、プライベート接続の確立に対する課金をします。 必要な接続の種類や数によって費用は大きく異なります。
設定時間: 場合によっては、物理的なハードウェアの設定が必要になる場合もあります。 この作業にかかる時間を実装スケジュールに組み込みます。
構成スキルとリソース: 構成の複雑性のほとんどは、ネットワーク内の内部ルーティングの設定に起因します。 この作業を行うには、熟練した人材を確保してください。
ExpressRoute を介した Power Platform トラフィックのルーティング構成を計画する
ご利用のプロバイダまたは接続プロバイダは、接続タイプに応じて、ExpressRoute を介した Power Platform トラフィックのルーティングを構成します。 Power Platform トラフィックのルーティングを計画する場合、その接続が処理するトラフィックのタイプと Power Platform との接続を考慮してください。これは、ご利用のサービスや機能によって異なります。
ExpressRoute 接続はデータセンター間のものですが、ネットワーク接続は主にユーザーのクライアント デバイスから発信されます。 これらのデバイスは、多くの場合、ブランチ オフィスなどのワイド エリア ネットワーク (WAN) に分散されています。 接続は、クライアント デバイスから WAN を経由してデータセンターに向かい、そこから ExpressRoute 回線を経由してルーティングされます。
この構成は慎重に行う必要があります。 WAN の設定は次のいずれかに従ってください:
- ネットワーク サブネットを経由するルートが ExpressRoute 用に構成されている、または
- フェイルオーバー回線は、公衆インターネット接続よりも優先して Power Platform が選択されます。
ネットワーク内のどのサブネットをメインとフォールバックの BGP (Border Gateway Protocol) セッション接続のターゲットにするかを特定することが重要です。 Power Platform のプレフィックスがそのルートを優先することを確認してください。 両エンドでサービスを特別に構成する必要はありません。 この構成は、接続を介して IP サブネットまたはプレフィックスをアドバタイズすることによって行われます。 要求が開始されると、ルーティング アルゴリズムは、そのダイレクト BGP 接続を、ExpressRoute 回線に接続されたサブネットへのトラフィックの優先ルートと見なし、トラフィックをのように転送します。
分散ユーザーベース用の ExpressRoute の構成
ExpressRouteは、ご利用の環境から Microsoft のネットワークへ、プライベートな専用接続と予測可能な接続を提供するように設計されています。 接続プロバイダーから Microsoft へ専用かつ直接接続することにより、接続プロバイダーのネットワークを通じて共有する接続で、他のトラフィックと競合する可能性が低くなります。 この品質の接続を実現するために ExpressRoute の使用は必須ではありませんが、接続品質を確保するのに役立ちます。
たとえば、次の例では支店のユーザーが WAN 経由で会社のデータセンターから ExpressRoute に接続します。
国/地域全体にあるブランチ オフィスなど、ユーザーが高度に分散している場合、ネットワーク トラフィックは、地理的に離れた複数の場所から効率的に接続する必要があります。 一般的なパターンは、次のイメージに示すように、トラフィックを WAN 経由で ExpressRoute に接続されたローカル ネットワークにルーティングするものです。
ExpressRoute は、クライアント デバイスと ExpressRoute 間の接続が不十分、飽和状態、または非効率であることを解決できません。 Microsoft のグローバル ネットワークに直接接続できる ExpressRoute Direct の使用を検討してください。
困難な WAN 接続に直面した場合は、ブランチ オフィスからローカル インターネット ブレイクアウトを確立すると役立つ場合があります。 このアプローチでは、低速の WAN 接続を回避し、接続プロバイダーのリーチを利用して、クラウドサービスへのより直接的な接続を実現します。
次の図のように、複数の場所から ExpressRoute 回線を設定することができ、さらにローカルのインターネット ブレイクアウトを介して個々の支店の場所にも接続できます。
WAN 接続の問題を軽減するために、各支店から ExpressRoute 接続を設定できます。 ただし、多くの場所で接続を設定すると、コストがかかり、維持が複雑になります。 より実用的な代替手段があります。
WAN を介して支店を中央データセンターに接続し、中央データセンターから ExpressRoute 接続を設定できます。
帯域幅を追加するか、ルーティングを改善することで、WAN 接続を最適化できます。
すべての支店とデータセンターを同じ IP 仮想プライベートネットワーク (VPN) で接続し、IP VPN サービス プロバイダが ExpressRoute の拠点で Microsoft に接続することができます。
広い地域に分散しているネットワークでは、ExpressRoute に接続された複数のハブを持つことで、各ユーザーにローカル接続ポイントを提供しながら、必要な ExpressRoute の接続数を最小限に抑えることができます。 各 ExpressRoute サーキットを介して一意のパブリック IP が公開されていることを確認してください。 各サブネットは別個のものである必要があり、ExpressRoute の接続数と同数のパブリック対応のサブネットが必要です。
このアプローチは、異なるオペレーション エリアが地理的に大きく異なる場所にある場合や、エリア間のネットワーク接続が制限されており、エリアごとに Microsoft へのより直接的な接続を確立できる場合に有効です。
地域が異なれば、プライバシー要件も異なる場合があります。 ExpressRoute を使用している場合でも、すべてのリージョンで ExpressRoute を使用する必要はありません。 インターネットを直接経由する接続もあれば、次の画像のように ExpressRoute を使用する接続もあります。
ExpressRoute (標準) は、特定の地域で接続を提供します。 単一の ExpressRoute 接続ポイントから複数の地域へのアクセスを提供するには、ExpressRoute Premium が必要です。 たとえば、米国を拠点とするオフィスと欧州を拠点とするオフィスがあり、すべて単一の Power Platform 環境を使用しているとします。 Power Platform テナントが米国で展開されている場合、欧州の ExpressRoute のサーキットには Premium バージョンが必要です。 Power Platform のテナントがヨーロッパにある場合、米国のサーキットは Premium でなければなりません。
非対称ルーティングの回避
注意すべき課題の 1 つは、非対称ルーティングです。 非対称ルーティングでは、ネットワークのルーティング構成によってインターネット経由で直接 Microsoft データセンターにトラフィックが送信されますが、リターン トラフィックは ExpressRoute 回線を介してルーティングされます。 この不一致は、対応するリクエスト パケットを送信せずに応答パケットを受信するため、ファイアウォールがトラフィックを拒否するトリガーとなる可能性があります。
非対称ルーティングは、クライアントのローカル ネットワークが、Microsoft クラウド サービスへの最も効率的なルーティングは、WAN を経由したプライベートな ExpressRoute サーキットではなく、パブリック インターネットを経由したものであると判断した場合に発生する可能性があります。 クライアント IP アドレスがパブリック IP アドレスである場合、またはネットワークアドレス変換 (NAT) マッピングによって ExpressRoute を介してアドバタイズされるパブリック IP アドレスに変換される場合、そのアドレスに戻る最も効率的なルートは、ExpressRoute 上の BGP セッションを経由するルートである可能性があります。 この状況を回避するには、インターネット エッジと ExpressRoute エッジで異なる NAT IP を使用します。 明確なソース アドレスがあれば、リターン トラフィックは明確に同じエッジに戻ってきます。
非対称ルーティングは、同じ顧客に対して複数の ExpressRoute 回線が構成されており、アウトバウンド トラフィックが 1 つの回線を経由し、リターン トラフィックが別の回線を経由する場合にも発生します。 ファイアウォール チェックにより、リターン パス上のトラフィックがブロックされる場合があります。 アウトバウンド パスとインバウンド パスで異なる ExpressRoute サーキットを横断する非対称ルーティングを回避するには、各サーキットで一意のパブリック IP が公開されている必要があります。
Power Platform から/への外部接続
各拠点から Power Platform に接続する場合、接続にはマイクロソフトとプライベートの 2 種類のピアリングがあります。 次の図に示すように、同じ ExpressRoute 回線で両方のピアリング タイプがサポートされます。
Power Platform サービスと外部ネットワークの間には、さまざまな接続タイプが存在します。 例えば、サーバー側同期期を使用した Exchange Web サービス接続では、ExpressRoute を使用して、マイクロソフトのネットワークから顧客のネットワークにネットワーク トラフィックを渡します。 HTTPS クライアントは、顧客ネットワークから Microsoft ネットワークへのアクセスに ExpressRoute 接続を使用します。 Web サービスの接続には、マイクロソフトのネットワークへのインバウンドとアウトバウンドの両方のトラフィックに ExpressRoute を使用します。
アウトバウンド トラフィック (Power Platform サービスからのトラフィック)
いくつかのタイプのアウトバウンド トラフィックは、Power Platform サービスから顧客サービスに直接渡すことができます。 顧客サービスは、パブリック DNS を通じて Power Platform サービスが解決できるパブリック IP アドレスを持つ、パブリック アドレスとして機能するものでなければなりません。 また、この IP アドレスは、ExpressRoute を通じて Microsoft にアドバタイズされる必要があり、これにより、Power Platform サービスの内部ネットワーク ルーティングは、その ExpressRoute 接続を通じてトラフィックをルーティングすることを認識します。
Power Platform サービスでは、どのサービス インスタンスやお客様の組織がどの IP アドレスにリクエストを出せるかを指定することはできません。 そのため、企業ネットワークに入ってくるリクエストは、インターネットからのものと同様にあつかいい、セキュリティを確保することが重要です。
次の表は、Power Platform サービスからのアウトバウンドのトラフィックを示しています。
| 内容 | トラフィックの種類と方向 | ピアリング タイプ | 目的 |
|---|---|---|---|
| Web サービス | Power Platform サービスからの HTTPS アウトバウンド | Microsoft ピアリング ExpressRoute で設定されたサブネット内のパブリック IP アドレスで Web サービスを公開します。 |
カスタム プラグインやワークフロー活動では、外部サービスに Web サービス要求を送信できます |
| Exchange 統合: ハイブリッド モード | Power Platform サービスからの HTTPS アウトバウンド | Microsoft ピアリング ExpressRoute で設定されたサブネット内のパブリック IP アドレスで Web サービスを公開します。 |
ハイブリッド展開 (Power Platform サービス、オンプレミスの Exchange) におけるサーバー側同期からの Exchange Web Services リクエスト |
| コネクタ | Power Platform サービスからの HTTPS インバウンド | Microsoft ピアリング | オンプレミスのデータゲートウェイを使用したコネクターを通じて、Azure API Management を通じた Power Platform サービスからのリクエスト |
| Azure Relay | Power Platform サービスからの HTTPS アウトバウンド | Microsoft ピアリング ExpressRoute で設定されたサブネット内のパブリック IP アドレスで Web サービスを公開します。 |
Power Automate クラウド フローとデスクトップ フロー間のダイレクト接続 |
インバウンド トラフィック (Power Platform サービスへのトラフィック)
次の表は、顧客ネットワークから Power Platform サービスへのインバウンド トラフィックについて説明したものです。
| プロパティ | トラフィックの種類と方向 | ピアリング タイプ | 目的 |
|---|---|---|---|
| クライアントの接続性 | Power Platform サービスへの HTTPS インバウンド | Microsoft ピアリング Azure Content Delivery Network が提供する静的コンテンツに使用する直接インターネット接続 |
Power Platform サービスの UI に対するクライアントの要望 |
| Web サービス | Power Platform サービスへの HTTPS インバウンド | Microsoft ピアリング | 標準またはカスタム クライアント アプリケーションから、Web サービス API (SOAP、Web API) を通じた Power Platform サービスへのリクエスト |
| コネクタ | Power Platform サービスへの HTTPS インバウンド | Microsoft ピアリング | オンプレミスのデータ ゲートウェイを使用したコネクターによる API 管理を通じて、Power Platform サービスに応答を返します |
Power Platform サービスの内部クラウド接続
次の表では、Power Platform サービスが Microsoft 365 および Azure でホストされている他の Microsoft オンラインサービスをどのように使用し、統合するかについて説明します。
| プロパティ | トラフィックの種類と方向 | パーパス |
|---|---|---|
| Exchange の統合 | Microsoft 365 への HTTPS アウトバウンド | サーバー側同期から Exchange Online への Web サービス リクエストの交換 |
| SharePoint 統合 | Microsoft 365 への HTTPS アウトバウンド | Power Platform サービスから SharePoint Online への SharePoint Web サービス リクエスト |
| Service Bus | Azure Service Bus への HTTPS アウトバウンド | 標準的なイベント登録、またはカスタム プラグインやワークフロー アクティビティから、Azure Service Bus にイベントをプッシュします |
| データの同期 | Azure からの HTTPS インバウンド | 検索/オフライン/顧客インサイトを含む、データサービスの同期のためのインバウンド変更追跡要求 |
| 認証 | Microsoft Entra への HTTPS アウトバウンド | ほとんどの認証はパッシブ リダイレクトとクレーム トークンで行われますが、一部のデータは Microsoft Entra ID と直接同期されます。 |
| データフロー | Azure Data Lake Storage への HTTPS アウトバウンド | 分析機能を提供し、分析から得られる分析情報に加えて、Power Platform サービスやその他のソースからのデータを組み込んだビッグ データ ソリューションへのアクセスを可能にします。 |
| コネクタ | Azure サービスとしてのプラットフォーム (PaaS) サービスへの HTTPS アウトバウンド | さまざまな Azure PaaS サービスへの接続 |
| Desktop flows | Azure Relay への HTTPS 送信 | Power Automate クラウド フローと Power Automate デスクトップで作成されたデスクトップ フロー間の直接接続性 |
Microsoft は、Microsoft または顧客の Azure サブスクリプションでホストされているこれらのサービス間の接続を処理します。 ExpressRoute は、これらのサービスとの接続には適用されません。
イベントがサービス バスにプッシュされる場合、Power Platform サービスと Azure との接続は内部で処理されます。 これとは別に、顧客はサービス バスにリクエストを出して情報を取得できますが、これはマイクロソフトのピアリングを介して管理できます。
Power Platform サービスとの間の顧客のパブリック クラウド接続、およびプライベート クラウド接続
Power Platform サービスでは、パブリックまたはプライベートの Azure リソースと直接統合することもできます:
- 外部ソースから、Microsoft Dataverse Web サービス API を使用します。
- 行われた Web サービス要求を使用して、外部ソースに送信します。
- コネクタを使用して、外部ソースに接続します。
次の表は、ExpressRoute を介して Power Platform サービスとの間でルーティング可能なトラフィックのタイプを示しています。
| プロパティ | トラフィックの種類と方向 | ピアリング タイプ | パーパス |
|---|---|---|---|
| ポータル | Azure への HTTPS インバウンド | コンテンツ配信ネットワーク (CDN) を使用する静的コンテンツを除いた、データセンター内部。 ExpressRoute は CDN をサポートしていないため、静的コンテンツはパブリック インターネット上を移動します。 | 公開サービスをホストします。 社内の従業員がこれらのリソースにアクセスできる場合、トラフィックは公共のインターネットではなく ExpressRoute を経由することをお勧めします。 |
| 学習パス | Azure への HTTPS インバウンド | CDN を使用する。 ExpressRoute は CDN をサポートしていないため、コンテンツはパブリック インターネット上を移動します。 | 個人的な顧客データを含まないため、公共性の高いサービスでホストされています。 予測可能性を高めるには、このトラフィックを ExpressRoute でルーティングするとよいでしょう。 |
| Service Bus | Azure Service Bus への HTTPS インバウンド | データセンターの内部 | 標準的なイベント登録、またはカスタム プラグインやワークフロー アクティビティによって Azure Service Bus に配置されたイベントをプルします |
| Web サービス要求 | Azure サービスとしてのインフラストラクチャ (IaaS) または PaaS からのインバウンド | データセンターの内部 | 顧客は Azure でカスタム アプリケーションをホストし、Power Platform Web サービスにリクエストすることができます。 |
| Web サービス要求 | Azure IaaS/PaaS へのアウトバウンド | データセンターの内部 | 顧客は、Azure のホストされたサービスを要求するカスタム プラグインとワークフローのアクティビティを実装できます。 |
| データフロー | Azure Data Lake Storage へのデータ接続 | データセンターの内部 | 分析機能を提供し、Power Platform サービスやその他のソースからのデータを組み込んだビッグデータ ソリューションにアクセスできるようになります。 |
| Azure Data Lake | Azure Data Lake Storage へのデータ接続 | データセンターの内部 | 分析機能を提供し、Power Platform サービスやその他のソースからのデータを組み込んだビッグ データ ソリューションと、分析から得られる分析情報へのアクセスを可能にします。 |
| Azure SQL | Azure SQL サービスへのデータ接続 | データセンターの内部 | Export to Data Warehouseなどの機能により、レポートやレプリケーション目的で Microsoft Dataverse データのレプリカを保持する Azure SQL インスタンスの使用が増加します。 ExpressRoute を介してこれらのリソースへの接続を保護する価値があるかもしれません。 |
その他のパブリック サービスは、Azure の機能がより多く使用されるにつれて、内部的にデータセンターに接続される可能性があります。