統合サービス ランディング ゾーン アクセラレータのネットワーク トポロジと接続に関する考慮事項
この記事では、Azure 統合サービス (AIS) ランディング ゾーン アクセラレータを使用しているときに適用できるネットワーク トポロジと接続に関する設計上の考慮事項と推奨事項について説明します。 ネットワークは、ランディング ゾーンのほぼすべての中心です。
このアーキテクチャのネットワーク トポロジと接続に関する考慮事項は、ホストされているワークロードの要件と、組織のセキュリティとコンプライアンスの要件によって異なります。
設計上の考慮事項
組織が次の場合は、Virtual WAN に基づくネットワーク トポロジを使用します。
複数の Azure リージョンにリソースをデプロイする予定であり、これらの Azure リージョン内の VNet と複数のオンプレミスの場所の間でグローバルに接続する必要がある。
ソフトウェアによる WAN (SD WAN) デプロイを通じて、またはネイティブ IPsec 終端に 30 個を超えるブランチ サイトを必要とする、大規模なブランチ ネットワークを直接 Azure に統合する必要がある。
サイト間 VPN を介して接続されたリモート ブランチ、ポイント対サイト VPN 経由を介して接続されたリモート ユーザーなど、VPN と ExpressRoute 間で推移的なルーティングが必要であり、DC に接続された ExpressRoute に Azure 経由で接続する必要があります。
大規模な相互接続の要件を満たすために Virtual WAN を使用します。 Microsoft がこのサービスを管理しているため、全体的なネットワークの複雑さを軽減し、組織のネットワークを最新化するのに役立ちます。
ハブアンドスポークのアーキテクチャに基づく従来の Azure ネットワーク トポロジは、次のような組織で使用します。
選択した Azure リージョンでのみリソースをデプロイする計画をしています。
グローバルに相互接続されたネットワークは不要です。
リージョンごとにいくつかのリモートまたはブランチの場所があり、30 未満の IP セキュリティ (IPsec) トンネルが必要です。
構成を完全に制御する必要があるか、Azure ネットワークの手動カスタム構成が必要である。
参照ネットワーク トポロジ
次のアーキテクチャ図は、AIS エンタープライズ デプロイの参照アーキテクチャを示しています。
IP アドレス指定を計画する
AIS のエンタープライズ デプロイには、プライベート エンドポイントと仮想ネットワークの使用を含める必要があります。 IP アドレス指定を計画するときは、次の設計上の考慮事項を考慮する必要があります。
一部の AIS では、専用のサブネットが必要です
特定のサブネットを特定のサービスに指定して、そのサービスのインスタンスをサブネット内に作成できます。 たとえば、サブネットをアプリ サービス プランに指定して、時間の経過とともにアプリを追加できます。
Azure VPN Gateway により、ネットワーク アドレス変換 (NAT) 機能を使用して、重複するオンプレミス サイトと重複する IP アドレス空間を接続できます。
[カスタム DNS]
ほとんどの AIS サービスでは、お客様は独自の DNS サーバーを使用するか、Azure DNS オファリングを介して、パブリック エンドポイントに独自の DNS 名を使用できます。 これらの構成はリソースごとに行われますが、サポートされているリソースは次のとおりです。
API Management では、カスタム ドメインがサポートされます。
関数アプリと Logic Apps では、App Service プランまたは App Service Environment によってホストされている場合、カスタム ドメインがサポートされます。
ストレージ アカウントでは、BLOB ストレージ エンドポイントのカスタム ドメインがサポートされます。
Data Factory、Service Bus、Event Grid では、カスタム ドメインはサポートされません。
プライベート DNS
Azure プライベート DNS は、仮想ネットワークのための信頼性が高く安全な DNS サービスとなります。 カスタムの DNS ソリューションを構成しなくても、Azure プライベート DNS によって、仮想ネットワークにおけるドメイン名の管理と解決が行われます。
仮想ネットワークからプライベート DNS ゾーンのレコードを解決するには、仮想ネットワークをゾーンにリンクする必要があります。 リンクされた仮想ネットワークはフル アクセス権を持ち、プライベート ゾーンに公開されているすべての DNS レコードを解決できます。
設計上の考慮事項
プライベート エンドポイントの IP アドレスをリソースの完全修飾ドメイン名 (FQDN) に解決するように、DNS 設定を正しく構成することが重要です。
既存の Microsoft Azure サービスには、パブリック エンドポイント用の DNS 構成が既に存在している場合があります。 プライベート エンドポイントを使用して接続するには、この構成をオーバーライドする必要があります。
暗号化と証明書の認証
ネットワーク設計で転送中のトラフィックや証明書ベースの認証の暗号化が必要な場合は、この暗号化/認証の実行場所と方法を検討する必要があります。 たとえば、TLS 終端を実行するサービスを特定する必要があります。
設計上の考慮事項
設計では、Azure サービス間のトラフィックを暗号化する必要がありますか? Azure Front Door で暗号化を終了してから、Azure バックボーンまたは VNet 内を通過しているときに暗号化を解除できますか?
複数の場所で暗号化を終了する必要がありますか?
複数の場所で認証を処理する必要がありますか? それとも外部要求に対して 1 回で実行できますか?
設計の推奨事項
エンタープライズ ハブアンドスポーク設計を使用する場合、インターネットベースの要求のエントリ ポイントとして Azure Front Door を使用することを検討してください。
外部 TLS ベースの要求の終了ポイントとして Azure Application Gateway を使用するか、証明書認証や SSL 終了の API Management を使用することを検討してください。
オンプレミスのリソースへの接続性
多くのエンタープライズ統合シナリオでは、オンプレミス システムを Azure に接続する必要があります。 この接続を提供するには、推奨されるモデルを検討することが重要です。
設計上の考慮事項
Azure ExpressRoute は、オンプレミスの場所から Azure のサービスとしてのインフラストラクチャ (IaaS) およびサービスとしてのプラットフォーム (PaaS) リソースへの専用プライベート接続を提供します。
Azure VPN Gateway は、オンプレミスの場所から Azure サービスとしてのインフラストラクチャ (IaaS) 仮想ネットワーク リソースへのパブリック インターネットを使用したサイト間 (S2S) 共有接続を提供します。
Azure ExpressRoute と Azure VPN Gateway は、異なる機能、コスト、パフォーマンスを備えています。
ExpressRoute または VPN Gateway が実用的でない場合、オンプレミス データ ゲートウェイ (OPDG) または Azure ハイブリッド接続を使用できます。OPDG/ハイブリッド接続はどちらもリレー サービスの例で、Service Bus を使用してオンプレミス ネットワークから送信された接続を行い、Azure からの要求を受信します。このときに、外部ファイアウォール/ネットワーク内のポートを開く必要はありません。
OPDG では、サポートされる 1 分あたりの要求数 (調整制限) が制限されており、特定のデータ サイズ制限があり、限られた Azure リソース (Logic Apps、Power BI、Power Apps、Power Automate、Analysis Services) でのみ機能します。
ハイブリッド接続は App Services (Function Apps または Web Apps) と連携し、独自の調整とサイズ設定の制限があります。
Azure Relay ハイブリッド接続は、App Services または OPDG の外部のリレーを可能にする Service Bus の重要な部分です。
設計の推奨事項
オンプレミス ネットワークを Azure に接続するためのプライマリ接続チャネルとして、Azure ExpressRoute を使用します。
帯域幅とパフォーマンスの要件に基づいて、ExpressRoute と VPN Gateway またはその両方に適切な SKU を使用していることを確認します。
ブランチまたはリモートの場所を Azure に接続するには、Azure VPN Gateway を使用します。
ExpressRoute または VPN Gateway を使用でない場合や、スループット制限が問題にならない場合、サポート Azure リソース (Logic Apps、Function Apps など) を使用している場合は、OPDG やハイブリッド接続を使用します。
AIS PaaS サービスへの接続
Azure AIS PaaS サービスは通常、パブリック エンドポイントを介してアクセスされます。 Azure プラットフォームには、それらのエンドポイントをセキュリティで保護する機能や、完全にプライベートにする機能が用意されています。
これらのエンドポイントのセキュリティ保護を実現するには、プライベート エンドポイントを使用します。
ターゲット リソースへのすべてのインターネット トラフィックをブロックするには、プライベート エンドポイントを使用します。
VNet リソースへの特定のサブリソースをセキュリティで保護する場合は、プライベート エンドポイントを使用します。
VNet リソースへの特定のストレージ アカウントをセキュリティで保護する場合は、プライベート エンドポイントを使用できます。
Azure Private Link を使用すると、お使いの仮想ネットワーク内のプライベート エンドポイント経由で Azure AIS サービス (Service Bus やAPI Management など) と Azure でホストされている顧客所有のサービスやパートナー サービスにアクセスできます。
Private Link を使用すると、お客様の仮想ネットワークとサービス間のトラフィックは Microsoft の バックボーン ネットワークを通過するため、お客様のサービスをパブリック インターネットに公開する必要がなくなります。 お使いの仮想ネットワークに独自のプライベート リンク サービスを作成して顧客に提供することができます。 Azure Private Link を使用した設定と消費は、Azure PaaS サービス、顧客所有サービス、共有パートナー サービス間で一貫しています。
設計上の考慮事項
仮想ネットワーク インジェクションでは、サポートされるサービスに対する専用のプライベート デプロイが提供されます。 管理プレーンのトラフィックは、依然としてパブリック IP アドレスを通して流れます。
Azure Private Link では、プライベート IP アドレスを使用して、Azure PaaS インスタンス、または Azure Load Balancer Standard レベルの内側にあるカスタム サービスのための専用アクセスが提供されます。
エンタープライズのお客様の多くには PaaS サービスに対するパブリック エンドポイントに関する問題があり、適切に軽減する必要があります。
設計の推奨事項
サポートされている Azure サービスに対する仮想ネットワーク インジェクションを使用して、仮想ネットワーク内からそれらを使用できるようにします。
仮想ネットワークに挿入された Azure PaaS サービスでは、サービス固有のパブリック IP アドレスを使用して管理プレーンの操作がまだ実行されます。 サービスが正しく動作するためには、接続が保証されている必要があります。
プライベート ピアリングで ExpressRoute を使用して、オンプレミスから Azure PaaS サービスにアクセスします。 専用の Azure サービスに対する仮想ネットワーク インジェクション、または使用可能な共有 Azure サービスに対する Azure Private Link を使用します。
仮想ネットワーク インジェクションまたは Private Link を使用できない場合にオンプレミスから Azure PaaS サービスにアクセスするには、Microsoft ピアリングで ExpressRoute を使用します。これにより、パブリック インターネットの通過を回避できます。
Microsoft ピアリングで ExpressRoute を使用して、オンプレミスから Azure PaaS サービスにアクセスしても、PaaS サービスのパブリック エンドポイントへのアクセスの妨げにはなりません。 必要に応じて個別に構成し、制限する必要があります。
すべてのサブネットにおいて既定で仮想ネットワーク サービス エンドポイントを有効にしないでください。
AIS PaaS サービスへのパブリック アクセスを無効にします。
API Management のネットワーク設計
設計上の考慮事項
API に外部からアクセスできるか、内部からか、あるいは両方のハイブリッドかを決定します。
内部 API Management ゲートウェイをメイン エンドポイントとして使用するか、または Azure Application Gateway や Azure Front Door などの Web Application Firewall (WAF) サービスを使用するかを決定します。
複数のゲートウェイをデプロイする必要があるかどうかを判断し、それらの負荷分散方法を決定します (たとえば、API Management ゲートウェイの前に Application Gateway を使用します)。
オンプレミス環境とマルチクラウド環境のどちらへ接続する必要があるかを決定します。
設計の推奨事項
API Management インスタンスを VNet にデプロイして、ネットワーク内のバックエンド サービスへのアクセスを許可します。
API Management インスタンスが内部モードで VNet にデプロイされるときにAPI Management への外部アクセスには、Application Gateway を使用します。
API Management インスタンスに対してプライベート エンドポイントを使用すると、プライベート ネットワーク内のクライアントが Azure Private Link を介して安全にインスタンスにアクセスできるようになります。
ストレージ アカウントのネットワーク設計
Azure Storage は、Azure Logic Apps と Azure Functions のストレージ ソリューションとして使用されます。
設計の推奨事項
最適なパフォーマンスを得るには、ロジック アプリ/関数アプリで同じリージョンのストレージ アカウントを使用する必要があります。これにより、待機時間が短縮されます。
Azure Storage アカウントのプライベート エンドポイントを使用すると、仮想ネットワーク (VNet) 上のクライアントはプライベート リンクを介してデータに安全にアクセスできるようになります。
各テーブル、キュー、BLOB ストレージ サービスごとに異なるプライベート エンドポイントを作成する必要があります。
App Service Environment のネットワーク設定
App Service Environment (ASE) は、Web アプリ、関数アプリ、Logic Apps (Standard) を実行するための専用の分離された環境です。 VNet にデプロイされ、多数の App Service プランが含まれています。それぞれのプランは、アプリ サービスをホストするために使用されます。
設計上の考慮事項
ASE は、VNet 内の 1 つのサブネットにデプロイされます。 ASE は仮想 IP アドレス (VIP) を使用してデプロイできます。これにより、外部接続でパブリックに表示される IP アドレスを使用でき、パブリック DNS レコードに追加できます。
ASE 内のアプリケーションは、ネットワーク アクセス規則に応じて、Virtual Network 内の他のすべてのリソースにアクセスできます。 他の VNet 内のリソースへのアクセスは、仮想ネットワーク ピアリングを使用して実現できます。
ASE 内のアプリケーションは、VNet に属するように構成する必要はありません。ASE へのデプロイにより、自動的に VNet に属します。 つまり、リソースごとにネットワーク アクセスを構成する代わりに、ASE レベルで一度で構成できます。
設計の推奨事項
- 可能な限り ASE v3 を使用します。これにより、ネットワークの柔軟性を最大限に高めると同時に、ASE 内の個々のリソースに必要な構成を減らすことができます。 ASE v3 では、ゾーン冗長もサポートされています。
App Service プランのネットワーク設計
マルチテナント環境内の App Services は、プライベート エンドポイントまたはパブリック エンドポイントを使用してデプロイできます。 プライベート エンドポイントを使用してデプロイすると、App Service の公開は削除されます。 App Service のプライベート エンドポイントにもインターネット経由で到達できるようにする必要がある場合は、App Gateway を使用して App Service を公開することを検討してください。
送信 VNet 統合のためにサブネットを慎重に計画し、必要な IP アドレスの数を検討します。 VNet 統合には、専用サブネットが必要です。 サブネットのサイズを計画するときは、Azure によって各サブネットに 5 つの IP アドレスが予約 されていることにご注意ください。 さらに、プラン インスタンスごとに、統合サブネットから 1 つのアドレスが使用されます。 アプリを 4 つのインスタンスにスケールする場合は、4 つのアドレスが使用されます。 サイズをスケールアップまたはスケールダウンすると、必要なアドレス空間が短期間に 2 倍になります。 これは、特定のサブネットでサポートされる実際の使用可能なインスタンスに影響します。
App Service からオンプレミスのプライベートまたは IP 制限付きサービスに接続する必要がある場合は、次の点を考慮してください。
マルチテナント環境で実行する場合、App Service 呼び出しはさまざまな IP アドレスから発信される可能性があり、ネットワーク要件を満たすには VNet 統合が必要になる場合があります。
API Management (APIM) などのサービスは、ネットワーク境界間の呼び出しをプロキシするために使用でき、必要に応じて静的 IP を提供できます。
設計の推奨事項
- 割り当てた後はサブネット サイズを変更できないため、アプリが到達する可能性のあるスケールに対応できるだけの十分な大きさを持つサブネットを使用してください。 サブネット容量に関する問題を回避するには、VNet 統合にサフィックス /26 (64 個のアドレス) を使用する必要があります。
Azure Data Factory のネットワーク設計
設計上の考慮事項
Data Factory をオンプレミス ネットワーク内にあるデータ ソースに接続する場合や、特に許可されていない限りはすべての Azure サービスからのアクセスをブロックするように構成されている Azure サービスに接続する場合は、ターゲット データ ソースへのネットワーク アクセスを提供する仮想ネットワークに Data Factory を統合することを検討する必要があります。
Data Factory では、統合ランタイムと呼ばれる個別の環境が採用されています。 既定の Data Factory ランタイムである Azure 統合ランタイムは VNet に関連付けられていないため、最も制限の厳しいファイアウォールで保護されているデータ ソースへの接続には使用できません。 これらのランタイムのうちどのランタイムが要件を最もよく満たすかを検討します。
マネージド VNet の起動には時間がかかりますが、通常の Azure ランタイムはほぼ瞬時に利用できます。 パイプラインのスケジュール設定とデバッグの両方を行うときに、この点に注意する必要があります。
VNet 統合ランタイムを使用する SSIS ランタイムの起動には、最大で 30 分かかります。
セルフホステッド統合ランタイムでは、コピー アクティビティのみを実行できます。このアクティビティでは、あるソースから別のソースにそのままデータをコピーします。 データへの変換を実行する場合、Data Factory のデータ フローを使用して変換を実行することはできません。
マネージド プライベート エンドポイントは、Azure Data Factory Managed Virtual Network に作成され、Azure リソース (一般に ADF のデータ リソース) へのプライベート リンクを確立するプライベート エンドポイントです。 これらのプライベート エンドポイントは、Azure Data Factory によって自動的に管理されます。
プライベート エンドポイント は、セルフホステッド統合ランタイムが Data Factory に接続する場合にのみ使用できます。
Logic Apps (Standard) のネットワーク設計 - VNet 統合アプリ
設計上の考慮事項
ロジック アプリへの受信トラフィックは、プライベート エンドポイントを経由します。 Logic Apps ネットワーク設計を計画するときの「プライベート エンドポイントを経由する受信トラフィックに関する考慮事項」のドキュメントをご覧ください。
ロジック アプリからの送信トラフィックは、VNet を通過します。 Logic Apps ネットワーク設計を計画するときの「仮想ネットワーク統合を経由する送信トラフィックに関する考慮事項」をご覧ください。
Service Bus のネットワーク設計
設計上の考慮事項
プライベート リンク リソースに解決するために、プライベート DNS ゾーンまたは独自の DNS サーバー (DNS 転送あり) を使用していますか?
IP フィルタリングと VNet は、Service Bus の Premium SKU レベルでのみサポートされます。 Premium レベルが実用的でない場合は、名前空間へのアクセスをロックダウンする主な方法として SAS トークンを使用することについてご確認ください。
設計の推奨事項
パブリック ネットワーク アクセスは、サポートされているすべてのプロトコル (AMQP や HTTPS など) に適用される IP フィルタリングを使用して無効にする必要があります。
この名前空間へのトラフィックは、(IP フィルタリングを使用して) パブリック ネットワーク アクセスを制限することによって、プライベート エンドポイント経由でのみ制限する必要があります。
Service Bus 用に予約された専用サブネットにプライベート エンドポイントを配置します。
プライベート エンドポイントのプライベート DNS ゾーンを使用して DNS レコードを追加します。 統合設計の問題を防ぐために、Azure 内の信頼されたサービスが名前空間に直接アクセスできるようにします (これにより、ファイアウォールをバイパスします)。
Function Apps のネットワーク設計
設計上の考慮事項
- プライベート リンク リソースに解決するために、プライベート DNS ゾーンまたは独自の DNS サーバー (DNS 転送あり) を使用していますか?
設計の推奨事項
パブリック ネットワーク アクセスを無効にする必要があります。
この名前空間へのトラフィックは、プライベート エンドポイント経由でのみ制限する必要があります。
Functions 用に予約された専用サブネットにプライベート エンドポイントを配置します。
プライベート エンドポイントのプライベート DNS ゾーンを使用して DNS レコードを追加します。
Azure Key Vault のネットワーク設計
設計の推奨事項
パブリック ネットワーク アクセスを無効にする必要があります。
VNet のみを使用してアクセスを制限するためのプライベート エンドポイントを作成します。
Key Vault 用に予約された専用サブネットにプライベート エンドポイントを配置します。
プライベート エンドポイントのプライベート DNS ゾーンを使用して DNS レコードを追加します。
Event Grid のネットワーク設計
設計上の考慮事項
- プライベート リンク リソースに解決するために、プライベート DNS ゾーンまたは独自の DNS サーバー (DNS 転送あり) を使用していますか?
設計の推奨事項
パブリック ネットワーク アクセスは、IP フィルタリングを使用して無効にする必要があります。
トピックとドメインへのトラフィックは、プライベート エンドポイント経由でのみ制限する必要があります。
Event Grid 用に予約された専用サブネットにプライベート エンドポイントを配置します。
プライベート エンドポイントのプライベート DNS ゾーンを使用して DNS レコードを追加します。
Event Hubs のネットワーク設計
設計上の考慮事項
- ネットワーク アクセスの制限は、Event Hubs の Basic SKU レベルでは機能しません
設計の推奨事項
パブリック ネットワーク アクセスは、IP フィルタリングを使用して無効にする必要があります。
サービス エンドポイントを使用してパブリック ネットワーク アクセスを無効にする必要があります。VNet に仮想ネットワーク サービス エンドポイントを作成し、仮想ネットワーク規則を使用してこれを Event Hubs 名前空間にバインドします
[信頼されたサービス] オプションを有効にして、選択した Azure リソースが名前空間にアクセスできるようにします。
次のステップ
重要な設計領域を確認し、アーキテクチャの完全な考慮事項と推奨事項を作成します。