このチュートリアルでは、Azure Virtual DesktopおよびAzure Kubernetes Service (AKS)ワークロードをデプロイするためのAzure エンクレーブ アーキテクチャを計画するのに役立ちます。 適切な計画により、最適なセキュリティ、ネットワークの分離、およびリソース編成が保証されます。
このチュートリアルでは、以下の内容を学習します。
- ワークロードの分離のためにエンクレーブ トポロジを計画する
- Azure Virtual Desktopと AKS のサブネットサイズ要件を計算する
- 必要なネットワーク エンドポイントと接続を特定する
- エンクレーブ間通信用のエンクレーブ接続を設計する
- ワークロード リソース グループを効果的に整理する
前提条件
このチュートリアルでは、次のチュートリアルの概念を理解していることを前提としています。
- チュートリアル 1-1: コミュニティをデプロイする
- チュートリアル 1-2: コミュニティ内にエンクレーブを作成する
- チュートリアル 1-3: エンクレーブ内にワークロードを作成する
- チュートリアル 1-4: サービス カタログを使用する
- チュートリアル 1-5: エンクレーブ エンドポイントと接続を作成する
- Azure Virtual Desktopの理解
- Azure Kubernetes Serviceの理解
アーキテクチャの概要
次の図は、アーキテクチャのチュートリアル 2-1 から 2-4 を示しています。 このアーキテクチャには、ファイアウォールを備えたコミュニティ ハブ、Azure Virtual Desktopワークロードと AKS ワークロード用の個別のエンクレーブ、および必要なエンドポイントと接続が含まれます。
主要な計画の決定
エンクレーブ トポロジ
Azure Virtual Desktopと AKS を別々のエンクレーブにデプロイするか、共有エンクレーブにデプロイするかを決定する必要があります。
| オプション | Benefits | 考慮事項 |
|---|---|---|
| 分離されたエンクレーブ | • ワークロードの種類間の最大分離 • 独立したネットワーク ポリシー • さまざまなコンプライアンス要件の管理が容易 • セキュリティ境界をクリアする |
• より複雑なエンクレーブ接続 • エンクレーブのその他のリソース • 重複する共有サービスの可能性 |
| One Enclave | • ネットワークの簡素化 • 共有共通サービス • 必要なエンクレーブ接続の数を減らします • 管理オーバーヘッドの削減 |
• ワークロード間の分離が少ない • 共有ネットワーク ポリシー |
| 共有サービス エンクレーブを使用したハイブリッド | • 一般的なリソースを共有しながらワークロードを分離する • Key Vault、ドメイン ネーム システム (DNS) などの一元化されたサービス • 両方のアプローチのベスト |
•最初に設定する最も複雑 • エンクレーブ接続を慎重に計画する必要があります |
推奨事項: 厳密なセキュリティ要件を持つ運用環境では、Azure Virtual Desktopと AKS に個別のエンクレーブを使用し、共有サービスと共通リソースには 3 つ目のエンクレーブを使用します。 このチュートリアル シリーズでは、個別のエンクレーブアプローチについて説明します。
Azure Virtual Desktopのサブネットのサイズ設定
Azure Virtual Desktopエンクレーブには少なくとも 2 つのサブネットが必要です。
| Subnet | Purpose | 推奨サイズ | 計算 |
|---|---|---|---|
| 管理サブネット | ホスト プール、ワークスペース、アプリケーション グループ、プライベート エンドポイント | /26 (64 IP アドレス) | 5 つの予約済みAzure IP + 管理リソース + 増加 |
| セッション ホスト用サブネット | Azure Virtual Desktop のセッション ホスト仮想マシン (VM) | VM 数に依存 | (Number of VMs + 5 reserved) + 20% growth |
セッション ホスト サブネットの計算例:
- 50 台のセッション ホストを計画済み
- 式：
(50 + 5) × 1.2 = 66 IPs needed - 推奨: 成長のために
/26(64 IP) または/25(128 IP)
Important
リソースのデプロイ後にサブネットのサイズを変更することはできません。 成長を計画する。
AKS のサブネットのサイズ設定
AKS には、エンクレーブ内に少なくとも 3 つのサブネットが必要です。
| Subnet | Purpose | 推奨サイズ | 計算 |
|---|---|---|---|
| ノード サブネット | AKS ワーカー ノード | ポッド数に依存 | (max nodes + 1) + ((max nodes + 1) × max pods per node) |
| API サーバーのサブネット | プライベート API サーバー エンドポイント | /28（16 IP アドレス） | API サーバー用の小さなサブネット |
| プライベート エンドポイント サブネット | AKS サービスのプライベート エンドポイント | /26 (64 IP アドレス) | さまざまな AKS サービスのプライベート エンドポイント |
ノード サブネットの計算例 (ノード あたり 30 ポッド、最大ノード数 3):
- 式：
(3 + 1) + ((3 + 1) × 30) = 4 + 120 = 124 IPs needed - 推奨:
/25(128 IP) 以上
Important
追加のノードを必要とするアップグレード操作を計画します。
ネットワークの要件
Azure Virtual Desktop に必要なエンドポイント
Azure Virtual Desktopでは、コミュニティ エンドポイント経由で次のエンドポイントに接続する必要があります。
| Purpose | [エンドポイント名] | Ports | プロトコル |
|---|---|---|---|
| Azure Virtual Desktop のコントロール プレーン | *.wvd.microsoft.com*.prod.warm.ingest.monitor.core.windows.net |
443 | HTTPS |
| Authentication | login.microsoftonline.comlogin.windows.net |
443 | HTTPS |
| Azure Resource Manager | management.azure.com |
443 | HTTPS |
| エージェントの更新 | mrsglobalstb2prod.blob.core.windows.netgcs.prod.monitoring.core.windows.net |
443 | HTTPS |
| ゲスト構成 | *.guestconfiguration.azure.com |
443 | HTTPS |
| Windows Update | *.prod.do.dsp.mp.microsoft.comwww.msftconnecttest.com |
443/80 | HTTPS/HTTP |
リファレンス: Azure Virtual Desktop必要な URL
AKS で必要なエンドポイント
AKS では、コミュニティ エンドポイント経由で次のエンドポイントに接続する必要があります。
| Purpose | [エンドポイント名] | Ports | プロトコル |
|---|---|---|---|
| コンテナー レジストリ | mcr.microsoft.com*.data.mcr.microsoft.com |
443 | HTTPS |
| クラスター管理 | *.hcp.<region>.azmk8s.io |
443 | HTTPS |
| Azure Resource Manager | management.azure.com |
443 | HTTPS |
| Authentication | login.microsoftonline.com |
443 | HTTPS |
| パッケージ リポジトリ | packages.microsoft.comacs-mirror.azureedge.net |
443 | HTTPS |
リファレンス: AKS で必要な送信ネットワーク規則
エンクレーブ間通信
個別のエンクレーブを使用する場合は、次の場合にエンクレーブ エンドポイントと接続が必要です。
| 情報源 | 行き先 | Purpose | Ports |
|---|---|---|---|
| Azure Virtual Desktop エンクレーブ | 共有サービス エンクレーブ | Key Vault、DNS、監視 | 443, 53 |
| AKS エンクレーブ | 共有サービス エンクレーブ | Key Vault、DNS、監視 | 443, 53 |
| Azure Virtual Desktop エンクレーブ | AKS エンクレーブ | 任意: 直接通信 | 要件に依存 |
リソースの編成
ワークロード リソース グループ
各ワークロードには、1 つ以上のリソース グループが必要です。 この組織について考えてみましょう。
Azure Virtual Desktop のワークロード リソース グループ:
-
rg-avd-controlplane- ホスト プール、ワークスペース、アプリケーション グループ -
rg-avd-sessionhosts- セッション ホスト VM と関連リソース -
rg-avd-storage- FSLogix のストレージ アカウント -
rg-avd-shared- Key Vault、マネージド ID などの共有リソース
AKS ワークロード リソース グループ:
-
rg-aks-cluster- AKS クラスター ユーザー リソース グループ -
rg-aks-nodes- AKS マネージド リソース グループ (自動的に作成) -
rg-aks-shared- Key Vault、マネージド ID などの共有リソース
共有サービス ワークロード リソース グループ (共有サービス エンクレーブを使用している場合):
-
rg-shared-security- Key Vault、マネージド ID、ディスク暗号化セット -
rg-shared-network- プライベート DNS ゾーン -
rg-shared-monitoring- ログ分析ワークスペース
一般的な依存関係の計画
Azure Virtual Desktopと AKS の両方に、次の一般的な依存関係が必要です。
| リソース | Purpose | 共有またはワークロードごと |
|---|---|---|
| ユーザー割り当てマネージドアイデンティティ | 暗号化キーにアクセスするための Key Vault | 共有またはワークロード単位で使用できます |
| Key Vault（キーボールト） | 暗号化キー、シークレット、証明書を格納する | 推奨: 共有 |
| カスタマー マネージド キー (CMK) | ディスクとデータを暗号化する | 共有またはワークロード単位で使用できます |
| ディスク暗号化セット | マネージド ディスクに CMK を適用する | ワークロードごと |
| プライベート DNS ゾーン | プライベート エンドポイントの DNS 解決 | エンクレーブ間で共有 |
| ログ分析ワークスペース | 一元的なログ記録と監視 | エンクレーブ間で共有 |
推奨事項: 共有サービス エンクレーブまたはワークロードに共通の依存関係をデプロイすることで、重複するリソースを削減します。
セキュリティに関する考慮事項
ネットワークの分離
- リソースの種類ごとに個別のサブネットを使用する
- サブネットにネットワーク セキュリティ グループ (NSG) 規則を適用する
- Azure PaaS サービスにプライベート エンドポイントを使用する
- ニーズに必要なエンドポイントへのコミュニティ エンドポイントを最小限に抑える
Encryption
- 保存されているすべてのデータに対してカスタマー マネージド キー (CMK) を有効にする
- VM ディスクにディスク暗号化セットを使用する
- AKS ノードのホストでの暗号化を有効にする
- すべてのキーをAzure Key Vaultに格納し、最小特権アクセス許可を割り当てる
アクセス制御
- リソースへのアクセスに Azure のロール割り当てを使用する
- 管理操作に Just-In-Time (JIT) アクセスを実装する
- 可能な場合は、サービス プリンシパルの代わりにマネージド ID を使用する
- すべてのロールの割り当てに最小特権の原則を適用する
モニタリング
- すべてのリソースで診断設定を有効にする
- セッション ホストの監視用に Azure Virtual Desktop Insights を構成する
- AKS 監視用に Container Insights を構成する
- すべてのログを一元化されたLog Analytics ワークスペースに送信する
次のステップ
アーキテクチャを計画した後、次のチュートリアルでは、ワークロードの Azure エンクレーブ環境を作成する手順について説明します。
