Azure Virtual Desktop の構築（シリーズの第1回）

VDI とは
Azure Virtual Desktop とは
Windows 365 と AVD
ID の選択肢
まとめ
1. 共有:

VDI とは

VDI（Virtual Desktop Infrastructure）とは、ユーザーが作業に利用しているデスクトップ環境（Windows の画面）を、複数のユーザーに対して同時に、ネットワークを通じてさまざまなデバイスに配信して、ユーザーが自分の作業環境として利用できるようにするシステムです。

Windows Server ではリモートデスクトップサービス（ターミナルサービス）として従来から提供されていた機能ですが、最近ではデスクトップ環境の提供をクラウドから行う「クラウド VDI」が広く採用されています。

クラウド VDI のメリットは以下のようなものです。

初期投資が少ない
従量課金で利用できる
ユーザー数の増減に柔軟に対応できる
デスクトップ環境のパフォーマンスの増減に柔軟に対応できる
ハードウェア環境の保守・運用が不要

従来の VDI ではデスクトップ環境を動作させるオペレーティングシステムやサーバー、ネットワークなどのインフラストラクチャーから、ユーザーへのデスクトップ環境の配信を行うサービスまで、構築・運用・保守のすべてをユーザー組織が行う必要があり、初期投資や構築工数・運用や保守の工数が大きくなりがちです。

これに対してクラウド VDI ではインフラストラクチャーや VDI のためのシステムが用意されているので、ユーザーに配信するデスクトップ環境の作成やユーザーへのデスクトップ環境の割り当てなどより少ない初期作業で利用を開始でき、運用・保守する部分も少なくなります。またユーザー数や必要とされる処理能力を増減することができ、従量課金でコストを最適化することができます。

このようにクラウド VDI は従来のオンプレミスの VDI に比べて大きなメリットを持っています。

Microsoft では、一般的な企業・組織の従業員向けの VDI ソリューションとして、Windows 365（W365）と Azure Virtual Desktop（AVD）を提供しています。

Microsoft ではこれ以外に以下のようなクラウド VDI ソリューションも提供しています。

Windows Server VM でホストするリモートデスクトップサービス
Azure DevTest Labs（システム開発・テスト環境）
Azure Dev Box（開発者用デスクトップトップ環境）
Windows 365 Frontline（現場作業者用共用 PC 環境）

AVD の構築に必要な情報について、これから数回に分けて解説していきます。

Azure Virtual Desktop とは

Azure Virtual Desktop（AVD）は、Microsoft Azure 上で実行する Windows 環境を利用した VDI 構築サービスです。VDI を構築するためのさまざまな機能が用意されていますので、それを利用してユーザー組織が独自の VDI を構築できます。

また通常のデスクトップ環境を配信するだけでなく、特定のアプリケーションの画面のみを配信する RemoteApp も構築できます。

以下は AVD で構築する VDI 環境のアーキテクチャの一例です。「Virtual Desktop コントロールプレーン」の部分が VDI でデスクトップ環境や RemoteApp を配信するためのサービスです。

このサービスに関連付ける形で、デスクトップやアプリを実行する仮想マシン、ネットワーク、ストレージ、認証基盤を構築して、VDI 環境を作成します。

AVD には以下のようなメリットがあります。

実態に合わせた課金
業務時間帯や曜日、季節に合わせて稼働させる仮想マシンの数を増減できます。負荷や時間帯によって増減を自動化することも可能です。通常の勤務時間は従業員の人数分の仮想マシンを稼働させ、業務時間外は残業や臨時対応のための少数の仮想マシンのみ稼働させる、といったことが可能です。
これにより仮想マシンを使用実態に合わせて無駄なく利用でき、コストを最適化できます。

任意のマシンサイズが選択可能
Azure で提供されている仮想マシンのほとんどのシリーズ・サイズの仮想マシンから自由に選択して VDI 環境を構築できます。シリーズやサイズの混在も可能です。
VDI 環境で実行するワークロードや仮想マシンを同時に利用するユーザー数などに応じた、柔軟な選択が可能です。

柔軟なカスタマイズ性
仮想マシンで実行するオペレーティングシステムと追加のソフトウェアをカスタマイズできます。オペレーティングシステムに言語や表示の独自設定を行う、ミドルウェアやアプリケーションを追加するなどのカスタマイズを行ったイメージを作成して、そのイメージから仮想マシンを作成し、VDI 環境として提供できます。また仮想マシンを冗長構成にするなど、可用性を高める構成も可能です。

仮想アプリケーションの配布（Remote App）が可能
デスクトップ（Windows の画面）の配信だけでなく、特定のアプリケーションのウィンドウだけ配信する Remote App を利用できます。Remote App を使うと、ユーザーはクラウド上で実行されているアプリケーションを、あたかも自分のデバイスで実行されているかのように利用することができます。

Windows 10/11 マルチセッションが利用可能
通常のコンピューターで実行する Windows 10/11 は1デバイスに同時に１ユーザーしかサインインできません（シングルセッション）。これに対して AVD では Windows 10/11 の仮想マシンに同時に複数のユーザーがサインインできる「マルチセッション」が利用できます。
マルチセッションを利用すると、実際の利用者数より実行する仮想マシンの台数を少なくすることができるので、コストの削減が可能です。
※Windows 10/11 マルチセッションは AVD にだけ認められています。他のクラウドサービスでは利用できません。

オンプレミスのドメインに参加可能
Express Route や VPN 接続などの閉域網接続と併用することで、AVD の仮想マシンをオンプレミスの既存の Active Directory ドメインに参加させることができます。この構成にすると、AVD の仮想マシンをオンプレミスのクライアントコンピューターを同等に扱うことができます。もちろん VDI 環境からオンプレミスのリソース（ファイルサーバー、共用プリンター、AD 認証で利用するアプリケーションなど）へのアクセスが可能です。
※オンプレミスのドメインを Microsoft Entra ID（旧Azure AD）に同期させる必要があります

クローズドなクラウド VDI 環境
VDI 環境（デスクトップ環境＝仮想マシンや RemoteApp）に組織のネットワーク以外からアクセスできないクローズドなクラウド VDI 環境を構築できます。これは Express Route や VPN 接続などの閉域網接続と併用することで可能です。
ただしコントロールプレーン（仮想マシンへの接続を管理するサービス）へのアクセスはインターネット経由で行う必要があります。コントロールプレーンへの接続を含めた完全な閉域網接続が必要な場合は、追加のサービスである「Citrix Cloud for AVD」または「VMware Horizon Cloud Service」を利用することができます。

Windows 365 と AVD

前述のように Microsoft は AVD の他にクラウド VDI のサービスとして Windows 365 も提供しています。

この２つのサービスには以下のような違いがあります。

サービスのレイヤー
ADV は組織が VDI 環境を構築するための基盤となる機能（コントロールプレーンや仮想マシン、仮想ネットワーク、仮想マシンイメージのレポジトリなど）を提供する IaaS のサービスです。
Windows 365 は構築済みの VDI 環境を「クラウド PC」として提供する SaaS のサービスです。
課金方法
AVD の料金は、他の Azure の IaaS のサービスと同様、仮想マシンやネットワーク帯域、ストレージの使用量に対する従量制課金です。
Windows 365 の料金は、仮想マシンのサイズによって決まる月額固定料金です。
仮想ネットワーク
AVD では通常の Azure 仮想マシンと同様に、仮想ネットワークへの接続が必須です。
Windows 365 では、仮想ネットワークへの接続はオプションです。オンプレミスのネットワークとの直接の接続が必要である場合は、仮想ネットワークへの接続が必要です。

AVD ではさまざまな機能を組み合わせて VDI 環境を構築できるので、ユーザー組織による構成の自由度は高くなりますが環境構築のための作業が必要となり、直接管理・運用する範囲が多くなります。

Windows 365 では構成済みの VDI 環境が提供されますのである程度のカスタマイズは可能ですが、AVD に比べて自由度は低くなります。その代わりカスタマイズしなければ構築作業不要で利用でき、ユーザー組織が管理・運用する範囲は少なくなります。

料金に関しては、AVD は稼働する仮想マシンの数を時間帯や曜日・時期によって柔軟に変更できますので、月額固定の Windows 365 に比べてクラウドサービスの料金自体は低く抑えることができます。ただしその分ユーザー組織での運用コストが発生しますので、TOC で比較してどちらが低くなるかは、VDI の利用形態や組織の運用体制によって異なります。

ID の選択肢

AVD を利用するユーザーには Microsoft Entra ID アカウントが必要です。

AVD で提供される仮想マシンは Active Directory Domain Services（AD DS）または Microsoft Entra Domain Services を利用した Active Directory ドメインに参加することができます。Active Directory ドメイン参加済みの仮想マシンにサインインするには、ドメインアカウントが必要です。

仮想マシンを Active Directory ドメインに参加させる場合、その Active Directory ドメインは Microsoft Entra ID と同期している必要があります。仮想マシンをオンプレミスの AD DS に参加させる場合は、Entra ID Connect 同期または Entra ID クラウド同期によるアカウントの同期を行います。

これらの ID の要件をまとめると、以下の表のようになります。

	ID のシナリオ	仮想マシン	ユーザーアカウント
①	Microsoft Entra ID + AD DS	AD DS に参加	Microsoft Entra ID と AD DS、同期される
②	Microsoft Entra ID + AD DS	Microsoft Entra ID に参加済み	Microsoft Entra ID と AD DS、同期される
③	Microsoft Entra ID + Microsoft Entra Domain Services	Microsoft Entra Domain Services に参加済み	Microsoft Entra ID と Microsoft Entra Domain Services、同期される
④	Microsoft Entra ID + Microsoft Entra Domain Services + AD DS	Microsoft Entra Domain Services に参加済み	Microsoft Entra ID と AD DS、同期される
⑤	Microsoft Entra ID + Microsoft Entra Domain Services	Microsoft Entra ID に参加済み	Microsoft Entra ID と Microsoft Entra Domain Services、同期される
⑥	Microsoft Entra のみ	Microsoft Entra ID に参加済み	Microsoft Entra ID

それぞれのシナリオにより、オンプレミスと Azure の間のネットワーク構成も決まります。

ADV の構築後に ID のシナリオを変更することは困難なので、AVD を構築する際はまずユーザーの ID をどのように構成するかを決定することが重要です。

①のシナリオ
仮想マシンをオンプレミスの AD DS のドメインに参加させます。ユーザーは仮想マシンにドメインアカウントでサインインします。閉域網接続を通じて仮想マシンからオンプレミス内のリソースにドメインアカウントでアクセスできます。

①´：①のシナリオで Azure 側にもドメインコントローラーを置く場合
①のシナリオでは仮想マシンの認証のためのドメインコントローラーを Azure 内に置くこともできます。
※下図では Entra ID Connect はオンプレミスに置いていますが、Azure 内に設置することも可能です

②のシナリオ
仮想マシンは Entra ID に参加します。ユーザーはオンプレミスの AD DS から同期された Entra ID アカウントで仮想マシンにサインインします。

③のシナリオ
仮想マシンは Entra ID Domain Service のドメインに参加します。ユーザーは Entra ID から同期された Entra ID Domain Service のドメインアカウントで仮想マシンにサインインします。
オンプレミスの Active Directory ドメインが無くても、Azure 内でドメインアカウントでの認証やアクセス制御を行えます。

④のシナリオ
仮想マシンは Entra ID Domain Service のドメインに参加します。ユーザーは Entra ID との同期を経由してオンプレミスの AD DS から同期された Entra ID Domain Service のドメインアカウントで仮想マシンにサインインします。

④´：④のシナリオで、Entra ID Domain Service ドメインとオンプレミス AD DS ドメインの間に双方向信頼関係を作成できます。この場合、閉域網接続を通じて仮想マシンからオンプレミス内のリソースに Entra ID Domain Service ドメインアカウントでアクセスできます。