TL

Cloud Service

Azure Virtual Desktop (AVD)

Azure 上で Windows のデスクトップとアプリを仮想化し、どこからでも安全に配信するフルマネージドの仮想デスクトップ基盤。AWS WorkSpaces / AppStream に相当。

基礎セキュリティ運用上の優秀性
最終更新: 2026-06-14公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.クラウド上に Windows デスクトップとアプリを配信する VDI / DaaS サービス。
  • 2.Windows 11 / 10 のマルチセッションで1台の VM を複数ユーザーで共有しコスト削減。
  • 3.管理プレーンは Microsoft 提供で、課金対象はセッションホストの VM とストレージが中心。

解決する課題

PC を物理的に配らずに、Windows のデスクトップやアプリをクラウドから安全に届けたい場面で使います。リモートワーク・派遣社員・BYOD(私物端末)・在外拠点などで、データを端末に残さずに業務環境を提供できます。

  • 端末を選ばず、どこからでも同じ Windows 環境にアクセスしたい
  • 業務データやアプリを端末ではなくクラウド側に集約し、情報漏えいを防ぎたい
  • 一時的に人数が増減するプロジェクトや繁忙期に、デスクトップを素早く増減したい
  • レガシーな業務アプリを個別配布せず、必要なユーザーにだけ公開したい
  • オンプレの VDI(仮想デスクトップ基盤)の運用・更新負荷を減らしたい

主要概念と用語

  • セッションホスト: 実際に Windows が動く VM。ユーザーはここにリモート接続する。複数台をまとめてホストプールに登録する
  • ホストプール: 同一構成のセッションホストの集合。後述の個人割り当てとプール(共有)割り当てを選ぶ
  • 個人(パーソナル)ホストプール: 1ユーザーに1 VM を専有で割り当てる方式。状態を保持したい開発者などに向く
  • プール(プールド)ホストプール: 複数ユーザーが VM 群を共有する方式。マルチセッションでコスト効率が高い
  • Windows マルチセッション: Windows 11 / 10 のエディションで、1台の VM に複数ユーザーが同時サインインできる AVD 専用の機能
  • アプリケーショングループ: ユーザーに公開する単位。デスクトップ(フルデスクトップ)と RemoteApp(アプリ単体配信)の2種類
  • ワークスペース: 複数のアプリケーショングループをまとめ、ユーザー側のクライアントに見せる入れ物
  • FSLogix プロファイルコンテナ: ユーザープロファイルを VHD/VHDX として外部ストレージに保持し、どのセッションホストにログインしても同じ環境を再現する仕組み
  • コントロールプレーン(管理プレーン): 接続のブローカー・ゲートウェイ・診断などを Microsoft がマネージドで提供する部分

仕様・制限・クォータ

  • セッションホストは通常の Azure VM として動くため、VM サイズ・vCPU クォータ・リージョンの上限がそのまま効く
  • ユーザーの ID は Microsoft Entra ID を基盤とし、用途に応じて Entra ID 参加、Active Directory Domain Services、Microsoft Entra Domain Services と組み合わせる
  • 1ホストプールに登録できるセッションホスト数や、1 VM あたりの同時セッション数には実用上の上限があり、VM のサイズと割り当てモードで変わる
  • マルチセッションは Windows の特定のエディション / イメージでのみ利用でき、個人割り当てでは通常のクライアント OS も使える
  • 管理プレーンは Microsoft 提供のため、ブローカーやゲートウェイのインフラ管理は不要

内部の仕組み

AVD は「Microsoft が管理するコントロールプレーン」と「利用者が管理するセッションホスト」に役割が分かれています。ユーザーはクライアントから接続要求を出し、Microsoft 側のブローカーが空いているセッションホストへ振り分け、ゲートウェイ経由で RDP 接続が確立されます。VM 本体・ディスク・プロファイル用ストレージは利用者のサブスクリプション内に置かれます。

  • ユーザーはまず Entra ID で認証し、ワークスペースに公開されたデスクトップ / RemoteApp の一覧を受け取る
  • ブローカーがロードバランシング(幅優先または深さ優先)でセッションホストを選び、接続を仲介する
  • リバース接続を使うため、セッションホスト側で受信用のパブリックポートを開ける必要がない
  • ログイン時に FSLogix がプロファイルコンテナをマウントし、どのホストでも同じデスクトップ状態を再現する
管理範囲の境目

ブローカー・ゲートウェイ・診断などの管理プレーンは Microsoft が運用します。利用者が責任を持つのはセッションホストの VM・OS・アプリ・プロファイルストレージ・ネットワークです。ここが PaaS と IaaS の中間という AVD の特徴です。

設計パターン / ベストプラクティス

  • コスト重視はプール + マルチセッション: タスクワーカーなど共有可能な利用者は、Windows マルチセッションで1 VM に複数人を収容する
  • 状態保持が必要なら個人割り当て: 開発者やローカルにツールを入れる利用者には、1人1 VM の個人ホストプールを使う
  • プロファイルは FSLogix で外出し: プロファイルを Azure Files / Azure NetApp Files に置き、ログイン先 VM が変わっても環境を維持する
  • イメージは Azure Compute Gallery で標準化: アプリ導入済みのゴールデンイメージを版管理し、セッションホストを再構築しやすくする
  • 自動スケールで夜間は縮小: スケーリングプランで業務時間帯だけホストを起動し、閑散時間は割り当て解除して費用を抑える
  • アクセスは条件付きアクセスで制御: 端末の状態や場所に応じて多要素認証を強制する

運用・監視

  • Azure Monitor / Log Analytics(AVD インサイト)で、接続時間・ログイン失敗・セッションホストの負荷・利用パターンを可視化する
  • セッションホストは通常の VM と同様、更新プログラム適用・イメージ更新・スケーリングを運用対象とする。ドレインモードで新規接続を止めてから更新する
  • ログインが遅い・プロファイルが壊れるときは、FSLogix のストレージ性能(IOPS / レイテンシ)とコンテナの破損、ストレージ容量を確認する
  • 接続できないときは、ID 認証(Entra ID / AD)、ネットワーク経路、必要な FQDN への送信通信、セッションホストの空き容量を切り分ける
  • スケーリングプランのタグや除外設定を使い、自動で割り当て解除されると困るホストを保護する

コスト

AVD のライセンスは、対象の Microsoft 365 / Windows Enterprise などのライセンスを持つユーザーには追加料金がかからない形が基本で、実際の費用の中心はセッションホストの VM とストレージです。

  • VM 課金は通常の Azure VM と同じ。停止(割り当て解除)すればコンピューティング課金が止まる
  • マルチセッションで1 VM に複数人を収容すると、ユーザー1人あたりの VM 費用を大きく下げられる
  • スケーリングプランで稼働時間を絞ることが最大の節約ポイント。夜間・週末に縮小する
  • プロファイル用ストレージ(Azure Files / NetApp Files)の容量・性能ティアもコストに効く
  • 予測可能なベース負荷の VM には予約インスタンスや Savings Plan を併用する
止め忘れに注意

プールドでも個人割り当てでも、起動したままのセッションホストは VM 課金が継続します。スケーリングプランや自動シャットダウンを設定し、誰も使わない時間帯に割り当て解除されるようにしましょう。

セキュリティ

  • データを端末に残さない: 画面情報だけを転送するため、私物端末や社外からのアクセスでもローカルに業務データが残りにくい
  • Entra ID + 条件付きアクセスで、多要素認証・端末準拠・場所ベースのアクセス制御を強制する
  • リバース接続によりセッションホストの受信ポートを開けずに済み、攻撃面を縮小できる
  • セッションホストは VM なので、Microsoft Defender for Cloud / Endpoint による保護やパッチ適用、ディスクの暗号化を行う
  • RBAC で、ホストプール作成・ユーザー割り当て・運用などの権限を分離する
  • 画面キャプチャ保護やクリップボード・ドライブリダイレクトの制御で、持ち出し経路を制限する
アンチパターン

セッションホストにパブリック IP を付けて RDP の 3389 番ポートを直接インターネットに開放するのは NG です。AVD はリバース接続で受信ポートが不要なため、不用意な公開は総当たり攻撃の的になります。ID 認証と条件付きアクセスで入口を固めましょう。

Well-Architected の観点

  • セキュリティ: データを端末に残さない構成、Entra ID + 条件付きアクセス、リバース接続による攻撃面の縮小、セッションホストへの Defender 適用が中核
  • オペレーショナルエクセレンス: 管理プレーンは Microsoft 任せにし、利用者はイメージ標準化・自動スケール・AVD インサイトによる監視に集中する
  • コスト最適化: マルチセッションでの集約と、スケーリングプランによる稼働時間の最小化が効く
  • 信頼性: セッションホストを可用性ゾーンに分散し、プロファイルストレージの冗長性を確保する

試験で問われるポイント

頻出
  • AVD はクラウドの仮想デスクトップ / DaaS であり、AWS WorkSpaces に相当する(アプリ単体配信は AWS AppStream に近い)
  • コントロールプレーン(ブローカー・ゲートウェイ)は Microsoft 管理セッションホスト VM は利用者管理という責任分界
  • Windows マルチセッションは AVD の特徴で、1 VM に複数ユーザーが同時サインインしてコストを下げる
  • 個人割り当て=1人1 VM、プール割り当て=複数人で VM を共有、という使い分け
  • FSLogix プロファイルコンテナで、どのセッションホストでも同じプロファイルを再現する
  • ID 基盤は Microsoft Entra ID。多要素認証は条件付きアクセスで強制する
  • 費用の中心はセッションホスト VM とストレージで、スケーリングプランで稼働を絞るのが節約の要

関連サービス・比較

クラウド上で Windows 環境を配信するサービスとして、AWS の WorkSpaces / AppStream と対応します。フルデスクトップを配るか、アプリ単体を配るかで近いサービスが変わります。

観点Azure Virtual DesktopAWS WorkSpacesAWS AppStream 2.0
主な提供形態デスクトップとアプリ単体の両方デスクトップ中心アプリ単体配信中心
共有モデルマルチセッションで1VMを共有可原則1ユーザー1インスタンスセッション単位でアプリを配信
ID 基盤Microsoft Entra ID / ADAWS Directory Service / ADAWS Directory Service / AD
プロファイル維持FSLogix コンテナ永続デスクトップホームフォルダ連携
主な用途Windows 業務環境の集約個人専有のデスクトップ特定アプリの配信
対応関係のまとめ

フルデスクトップを配るなら AVD ≒ AWS WorkSpaces、特定アプリだけを配るなら AVD の RemoteApp ≒ AWS AppStream 2.0。AVD はマルチセッションで1台に複数人を収容できる点が、原則1ユーザー1インスタンスの WorkSpaces との大きな違いです。

ハンズオン / CLI例

# リソースグループを作成
az group create --name avd-rg --location japaneast

# プールド(共有)ホストプールを作成(幅優先ロードバランシング)
az desktopvirtualization hostpool create \
  --resource-group avd-rg \
  --name avd-pool \
  --location japaneast \
  --host-pool-type Pooled \
  --load-balancer-type BreadthFirst \
  --max-session-limit 10 \
  --preferred-app-group-type Desktop

# デスクトップ用アプリケーショングループを作成
az desktopvirtualization applicationgroup create \
  --resource-group avd-rg \
  --name avd-desktop-ag \
  --location japaneast \
  --host-pool-arm-path "/subscriptions/<sub-id>/resourceGroups/avd-rg/providers/Microsoft.DesktopVirtualization/hostPools/avd-pool" \
  --application-group-type Desktop

# ワークスペースを作成し、アプリケーショングループを関連付け
az desktopvirtualization workspace create \
  --resource-group avd-rg \
  --name avd-workspace \
  --location japaneast \
  --application-group-references "/subscriptions/<sub-id>/resourceGroups/avd-rg/providers/Microsoft.DesktopVirtualization/applicationGroups/avd-desktop-ag"

Azure Service

Azure Virtual Desktop (AVD)を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

エンドユーザー / VDI

比較で見る軸

クラウド: Azure / カテゴリ: エンドユーザー / VDI / 難易度: basic

導入後に効く点

Windows 11 / 10 のマルチセッションで1台の VM を複数ユーザーで共有しコスト削減。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
エンドユーザー / VDI
難易度
basic
関連資格
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「エンドユーザー / VDI / security」に近いか確認する。
  • 強みである「クラウド上に Windows デスクトップとアプリを配信する VDI / DaaS サービス。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

エンドユーザー / VDIsecurityoperational