変更要約: AZ-140 第1章を新規作成（ドメイン1前半: ネットワーク要件評価/リバース接続/RDP Shortpath・Multipath/QoS(DSCP)、Azure Private Link for AVD(プライベートエンドポイント/プライベート DNS ゾーン)/接続トラブルシュート(DNS/UDR/FW/Azure Monitor)、ユーザーデータストレージ(FSLogix プロファイル/Azure Files Premium SMB/Azure NetApp Files/AD DS・Entra Domain Services 認証/IOPS・ログオンストーム/同一リージョン)）。
1.2Azure Private Link と接続のトラブルシュート
Azure Virtual Desktop 向けの Azure Private Link ソリューションの計画と実装、ネットワーク接続の監視とトラブルシュートを理解します。
既定の AVD 接続はインターネット経由（リバース接続）です。より厳格なネットワーク要件では、Azure Private Link でトラフィックを公衆インターネットに出さずプライベートに保ちます。
1.2.1AVD の Private Link
Azure Private Link for AVD は、クライアントとサービス（ワークスペース/ホストプール/フィード）の間を プライベートエンドポイント で結び、トラフィックを Microsoft バックボーン内に保ちます。これにより「インターネットを経由させない」「公開エンドポイントを無効化する」といったセキュリティ要件を満たせます。クライアント側のプライベート接続（オンプレからの ExpressRoute/VPN）と組み合わせ、エンドツーエンドでプライベートな AVD 接続を設計します。
1.2.2接続の監視とトラブルシュート
接続障害は層を切り分けます＝名前解決（DNS・Private Link ならプライベート DNS ゾーンが要）、経路（UDR/ファイアウォールで送信 443 がブロックされていないか）、サービス側（ホストプール/セッションホストの状態）。接続グラフ/接続の品質 や Azure Monitor のメトリクスで RTT や切断を確認し、原因を特定します。「Private Link なのに名前解決できない」＝プライベート DNS ゾーンの構成漏れが典型です。
決め手：「トラフィックを公衆網に出さずプライベートに」＝Azure Private Link for AVD（プライベートエンドポイント＋プライベート DNS ゾーン）。「接続の RTT/切断を確認」＝Azure Monitor/接続品質。RDP Shortpath（性能）とは別目的。
混同に注意：
①Private Link（プライベート接続）と RDP Shortpath（直接 UDP の性能）を取り違えない。
②Private Link はプライベート DNS ゾーンの構成が前提＝名前解決の失敗が典型障害。
③送信 443 が UDR/ファイアウォールでブロックされていないか確認する。
1.2.3この節のまとめ
- Azure Private Link for AVD＝プライベートエンドポイントでトラフィックを公衆網に出さずバックボーンに保つ
- Private Link はプライベート DNS ゾーンが前提＝名前解決失敗が典型障害
- 接続は DNS/経路(UDR・FW)/サービス状態で切り分け、Azure Monitor で RTT/切断を確認
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. AVD の接続トラフィックを公衆インターネットに出さず、プライベートに保ちたい。最適なのはどれですか？
Q2. AVD で Private Link を構成したのに、クライアントが名前解決に失敗する。最も疑うべき原因はどれですか？
Q3. Azure Private Link for AVD と RDP Shortpath の違いとして正しいのはどれですか？
Q4. AVD 接続のトラブルシュートで、送信トラフィックがブロックされていないか確認すべき対象はどれですか？
Q5. AVD 接続の RTT や切断を継続的に監視したい。最適なのはどれですか？