はじめに
AVDは閉域にできないと言われています。
何故できないのかを私なりに整理してみました。
結論は「Azureだけでは閉域化できない。」
「しかし、閉域化の方法が全くないわけではない。」です。
誤っている点などあればコメントいただけますと嬉しいです。
１. AVDの構成要素
AVDの基本的な構成は以下です。
- コントロールプレーン
- Entra ID
- SessionHost（仮想マシン）
本来はユーザプロファイル用のストレージサービス等も必要ですが今回は割愛します。また、閉域をテーマにしているのでExpressRouteを記載しています。
２. クライアント接続シーケンス
まずは一般的なAVD接続シーケンスを確認してみます。
クライアントからAVDへ接続するには大きく12のステップがあります。
※Learnはこちら
1～6の通信
AVD接続の際、最初にIDとPASSを入力して認証するかと思いますが、その際の通信です。
ここまででアプリケーション内にアイコンが出来上がります。
ここまでの通信ではあくまで認証フェーズなので、仮にアプリケーショングループ (DAG) へのユーザー割り当て操作をしていない場合でも問題なく処理されます。その場合、「SessionDesktop」アイコンが表示されません。
7～12の通信
アイコンをたたくと以下の通信が発生します。
ここまできてAVDに接続完了です。
３. 接続シーケンスの中身を閉域視点で確認する
Entraとの通信
例えば2番でEntraによるユーザ認証があります。
Entra（Entra ID）との通信は閉域ではないです。
ExpressRouteのMicrosoft Peeringであれば閉域にできますが、AVDを使う際は多くの場合M365を使用するかと思います。M365向け通信はMicrosoft Peeringを使用する際承認が必要であり、承認されるかどうかは何とも言えません。
Microsoft ピアリングのLearnはこちら：Microsoft ピアリング
Azure Front Doorとの通信
7番のFront Doorとの通信についても閉域になりません。
Azure Front DoorはExpressRouteを使用した閉域接続をサポートしていないとLearnにて明言されています。
サポート対象外:
CDN
Azure Front Door
Multifactor Authentication Server (レガシ)
Traffic Manager
Logic Apps
Intune
４. FQDN
次にFQDNを確認します。
※Learnはこちら
大きくは2グループあります。
A. クライアントからの通信（FQDN 12個）
B. セッションホストからの通信（FQDN 22個）
どちらも閉域ではない通信になります
本題とは異なりますが、Learn記載のFQDNはワイルドカードを使用しているため、正確にFQDNを把握するにはイベントビューアから確認する必要があります。
５. PrivateLink
AVDはPrivateLinkがあるので閉域化可能なのではという話があります。
確かにPrivateLinkはあるのですが、必要な通信(FQDN)のうち
「*.wvd.microsoft.com」←こちらのみ閉域にできます。
個数で言うと以下の通りです
- クライアントからの通信 1/12個
- セッションホストからの通信 1/22個
「*.wvd.microsoft.com」はコントロールプレーンへの通信が閉域になります。
他の通信は閉域ではない通信になります。
Learnはこちら：Azure Private Link with Azure Virtual Desktop
クライアント接続シーケンス
PrivateLink使用時のクライアント接続シーケンスはこちら
※プライベート ルートからのクライアント接続のみを許可している場合
本題とは異なりますがAVDのPrivateLinkを使用するとユーザが作成したワークスペース固有のFQDNに対してDNSクエリを実行します。固有のFQDNとなるため、Azure Firewallと組み合わせると外部テナントAVDへのアクセスを防げます。
６. RDP Shortpath
RDP Shortpath使えばいいのでは？と思われるかたもいるかもしれません。
確かに画面転送をプライベートネットワークで行うことが可能です。
しかし、最初にEntraへの認証を行う必要があるので閉域になりません。
また、Private Linkと違い閉域からのアクセスを強制できません。(パブリックルートからAVDへアクセス可能)
Learnはこちら：Azure Virtual Desktop の RDP Shortpath
７. Azure Virtual Desktop on Azure Local
昔はAzure Stack HCIという名前でした。
オンプレミスにしちゃえば閉域になるのではと思われるかもしれません。
しかし、このサービスはセッションホストがオンプレになるイメージです。
RDP Shortpathを使うことができますが、やはりEntraとの通信が必要となるため閉域ではありません。
Learnはこちら：Azure Virtual Desktop on Azure Local
８. Citrix Cloud
他の方法では閉域にできないと記載しましたが、この方法であれば閉域にできます。
Azure内部にCitrix専用のVM(Cloud Connector)をたてて、従来のAVDコントロールプレーンのような役割のCitrixサービスへ接続することで閉域にできます。
※Citrix社との契約が必要になります
なお、コストや運用面などを考慮した上で採用検討することをおすすめします。
公式ドキュメント上での確証を得ることはできていません。
CitrixのCloud Connectorの要件にADサーバがあればOKとあることから、今までネックだったEntraを含めたコントロールプレーンへのアクセスをCloud Connector（ＶＭ）経由にできるため閉域にできると思っています。
Cloud Connectorの接続要件：システムおよび接続要件
分かりやすいのはくらう道さんです。
９. VMware Horizon Cloud Service
Horizon Cloud with AVD というサービスが昔あり、Citrix同様閉域化できていたと言われていました。
しかし、サービス終了に伴いこの方法は出来なくなりました。
後継サービスが「VMware Horizon Cloud Service next-gen」です。
しかし、こちらはEntraへアクセスする必要があり閉域化は無理です。
現在確認するとLearnでは以下のように紹介されていました。
Omnissa Horizon Cloud on Microsoft Azure は、Azure Virtual Desktop を拡張することで、Azure での仮想デスクトップとアプリケーションの配信を簡略化する Omnissa サービスです。
(何故Omnissaになったのか等は「VMware」「Broadcom」「Omnissa」等で調べるとでてきます）
Omnissaのドキュメントはこちら：Horizon Cloud Service - next-gen Architecture
こちらは昔公式ドキュメント上でインターネットアクセス必須という文章を見かけた記憶があるのですが、あまり深追いしておらず再度見つけられていません。
こちらもくらう道さんが分かりやすいです。
まとめ
Azureだけでは閉域化できません。
閉域を目指す場合はCitrix Cloudを検討する必要があります。
補足
AVDの通信が閉域にできたとして、Azure管理するために”Azure portalへ接続する通信はどうするのか？”など使用するサービスをトータルで検討することをおすすめします。
また、「閉域化」に求めるものを明確にするとよいかもしれません。
-
ケース１：インターネットを使いたくない
⇒パブリックIPなしでセキュアに接続する方法もあるがそれではダメなのか？ -
ケース２：専用線で接続したい
⇒HTTPS等で暗号化されていてたとしても専用線じゃないとダメなのか？ -
ケース３：閉域接続したい
⇒ExpressRouteを使用する場合、VNetから先の通信も閉域接続が必要か？
⇒Microsoft Peeringまで必要か？
などなど
Microsoft PeeringのLearnはこちら：Microsoft ピアリング
参考文献
■ブログ
■Learn
■Citrix Cloud
■VMware(Omnissa)