AWS EUC本番運用 Vol1｜WorkSpaces×AppStream×DaaS

1. なぜ End User Computing本番運用 Vol1 か — EUC全体アーキテクチャ概観

AWS の End User Computing (EUC) ポートフォリオは、クラウド上でデスクトップ環境・アプリケーション・セキュアブラウザをエンドユーザーに安全に配信するマネージドサービス群の総称である。オンプレミス VDI (Virtual Desktop Infrastructure) を長年運用してきた情報システム部門やインフラエンジニアにとって、「物理サーバー管理からの解放」「テレワーク時代に即したデスクトップ配信」「ライセンス・コスト管理の合理化」は共通の課題であり、AWS EUC はこれらをひとつのクラウドネイティブなポートフォリオで解決する手段として機能している。

本記事は End User Computing 本番運用シリーズの第 1 弾として、AWS EUC ポートフォリオを構成する 3 つのコアサービスを体系的に解説し、本番環境での実践的な設計・運用判断に直結する知識を提供する。

1-1. AWS EUC 3 サービスの全体像

AWS の EUC ポートフォリオは現在、以下の 3 つのコアサービスで構成されている。

Amazon WorkSpaces (WorkSpaces Core)

永続または非永続のクラウドデスクトップを提供するサービス。ユーザーはフルデスクトップ環境 (Windows / Linux) にリモートクライアントまたはウェブブラウザ経由でアクセスできる。WorkSpaces Personal (永続デスクトップ) と WorkSpaces Pools (非永続デスクトップ) の 2 形態を持つ。§2 で詳述する。

Amazon WorkSpaces Web (Secure Browser)

エンドユーザーがフルデスクトップを持たなくても、企業内ウェブアプリケーションに安全にアクセスできるマネージド・セキュアブラウザサービス。SAML 2.0 IdP 連携・アクセス制御・セッション分離を組み合わせ、データを端末にダウンロードさせずに業務を完結させる「ゼロトラスト型ブラウザ接続」を実現する。§3 で詳述する。

Amazon AppStream 2.0 (WorkSpaces Applications)

個別のアプリケーションをクラウドサイドで実行し、ユーザーの端末にはストリームで画面を配信するサービス。フルデスクトップではなく「アプリケーション単位の配信」が特徴で、CAD・業務基幹アプリなどを端末スペックに依存せず配信できる。AWS ドキュメント上では “Amazon WorkSpaces Applications” への名称統合が進行中である。§4 で詳述する。

1-2. EUC アーキテクチャの 4 層定義

AWS EUC のアーキテクチャは、以下の 4 つの論理層で整理すると設計判断が明確になる。

この 4 層の切り分けが本記事全体を貫く設計軸であり、どのユーザー層に何を配信するかによって使うサービスと設計パターンが変わる。

1-3. なぜ今、AWS EUC の本番運用を体系化するか

オンプレ VDI の限界

従来の VMware Horizon / Citrix Virtual Apps & Desktops に代表されるオンプレ VDI は、ハイパーバイザー・ストレージ・ライセンスの三重コストと、急激なアクセス増への拡張速度の限界という構造的課題を抱えている。特に 2020 年以降のリモートワーク急拡大により、オンプレ VDI の容量計画とライセンス管理の複雑さが顕在化した。

AWS EUC が解決する 3 つの課題

1. スケーラビリティ課題: WorkSpaces は API / コンソール / Auto Scaling により、需要変動に応じたデスクトップ数の増減を数分単位で実現。物理サーバーの調達リードタイムは不要。

2. ライセンス管理課題: Windows ライセンスは月額固定の RDS SAL (Remote Desktop Services SAL) として WorkSpaces バンドルに内包される。個別 VDA ライセンス管理が不要になる (BYOL オプションを除く)。

3. セキュリティ課題: WorkSpaces Web によるセキュアブラウザ接続・AppStream 2.0 によるアプリ配信は、ユーザー端末にデータを持ち出させない設計が基本。エンドポイントのセキュリティ要件を大幅に緩和できる。

本番運用で詰まる罠

AWS EUC は導入のハードルが低い一方、本番運用で詰まる論点が集中している。バンドルの廃止スケジュール (Office 2016/2019 Plus は 2025 年 10 月廃止)・Pools 課金形態の誤選択・Directory Service の設計ミス・AppStream 2.0 の Fleet 選択ミスなど、運用フェーズで初めて顕在化するリスクが多い。本記事はこれらの論点を体系的に整理する。

1-4. 本記事のゴールと読者像

読者像

• オンプレ VDI 運用者: Citrix / VMware Horizon から AWS WorkSpaces への移行を検討しているインフラエンジニア・クラウドアーキテクト
• 情報システム部門: 社員向けデスクトップ・アプリ環境のクラウド化・コスト削減・テレワーク対応を推進する IT 担当者
• EUC 管理者: WorkSpaces / AppStream 2.0 を既に導入し、本番運用の最適化・コスト管理・セキュリティ設計を深めたいエンジニア

本記事で獲得できること

この記事を読み通すことで、以下の 4 つの設計判断能力を獲得できる。

• (a) WorkSpaces Personal (永続) と Pools (非永続) のバンドル・ディレクトリ・課金最適化の判断軸
• (b) WorkSpaces Web (Secure Browser) で SAML IdP 連携・アクセス制御・トラスト境界を本番設計する能力
• (c) AppStream 2.0 をアプリ配信層として WorkSpaces と使い分ける基準
• (d) DaaS として 3 サービスを使い分けるディレクトリ設計・コスト試算・監視運用・移行設計の確立

1-5. 本記事の構成

本記事は End User Computing 本番運用シリーズの Vol1 として、AWS EUC の全体像から個別サービスの本番設計まで体系的に解説する。オンプレ VDI からの移行・新規導入・既存環境の最適化いずれの局面にも対応する設計判断軸を提供することが、本記事の核心的な価値である。

1-6. AWS EUC の接続クライアントと統合アクセス

AWS EUC 3 サービスは、エンドユーザーの利用デバイスを幅広くサポートしている。運用設計においてクライアント要件を早期に確認しておくことが重要である。

AWS は EUC サービスへの「統合アクセス (Unified access to AWS End User Computing)」機能を提供しており、ユーザーはひとつのポータルから複数の EUC サービスにアクセスできる。エンドユーザーにとっての透明性を高め、IT 部門のオンボーディング・サポートコストを削減する効果がある。

クライアントの更新管理についても運用設計の対象となる。WorkSpaces クライアントは定期的な更新があり、管理者は組織の展開ポリシーに従ってクライアントバージョンを管理する。ウェブブラウザ経由のアクセスはクライアント更新管理を省略できるため、管理コストを優先する環境では有効な選択肢である。

2. Amazon WorkSpaces Core本番運用

Amazon WorkSpaces Core は、AWS が提供するクラウドデスクトップ (Cloud PC) サービスの基盤であり、エンドユーザーに Windows または Linux のフルデスクトップ環境を安全かつスケーラブルに配信する。WorkSpaces Core は大きく WorkSpaces Personal (永続) と WorkSpaces Pools (非永続) の 2 形態があり、ユースケースに応じた選択が本番運用コストと利便性を大きく左右する。

2-1. WorkSpaces Personal (永続) vs WorkSpaces Pools (非永続)

WorkSpaces Personal — 永続デスクトップ

WorkSpaces Personal は、ユーザー 1 人につき 1 台の仮想デスクトップが割り当てられ、ユーザーデータ・設定・インストール済みアプリケーションが永続的に保持されるモデルである。デスクトップは常に「そのユーザー専用」として稼働し、再起動しても以前の状態から続きを使える。

主なユースケース:
– ヘビーユーザー (エンジニア・デザイナー) の個人用開発環境
– 長時間セッションが前提の業務担当者
– ローカルインストールが必要な専用ソフトウェアを使う業務

WorkSpaces Pools — 非永続デスクトップ

WorkSpaces Pools は、ユーザーがセッションを開始するとプールから空きデスクトップが動的に割り当てられ、セッション終了後にデスクトップが初期化 (リセット) されるモデルである。ユーザーデータは永続化されない。永続化が必要な場合は Amazon FSx や S3 をホームフォルダとして設定する。

主なユースケース:
– シフト勤務や派遣スタッフなど、同一時間帯に全員がログインしない業務
– コールセンター・事務処理部門での大規模展開
– 端末にデータを残したくないセキュリティ要件が厳しい環境

2-2. 課金モデル — AlwaysOn vs AutoStop

WorkSpaces Personal / Pools どちらにも、以下の 2 つの課金モデルが存在する。

AlwaysOn (常時稼働・月額固定)

デスクトップが常時起動した状態を維持する課金モデル。ユーザーがログインしていなくても月額料金が発生し続ける。メリットは接続時のレスポンス速度 (起動待ちゼロ) と運用の単純さ。ヘビーユーザー・業務時間外も稼働が必要なユースケースに適する。

• 課金: 月額固定 (バンドルにより金額が異なる)
• 起動時間: 即時 (停止していないため待ち時間ゼロ)
• 推奨ケース: 週 40 時間以上稼働、常時オンが必要な業務

AutoStop (自動停止・接続時課金 + 停止時 hourly)

ユーザーがセッションを切断してから一定時間 (デフォルト 1 時間) 後にデスクトップが自動停止し、接続時にのみ時間課金が発生するモデル。停止状態でも低額の月額ベース課金が発生するが、AlwaysOn と比較してトータルコストを削減しやすい。ログイン回数が少ない業務や夜間・週末は全く使わない環境に適する。

• 課金: 接続時間 (hourly) + 停止時ストレージ等の月額 (低額)
• 起動時間: 1〜3 分 (停止状態からの復帰)
• 推奨ケース: 週 40 時間未満の利用、コスト最優先の環境

AlwaysOn vs AutoStop の選択基準

月額コスト試算の目安 (概算例・リージョンとバンドルにより異なる):
  AlwaysOn: バンドル月額固定料金 (例: Value バンドル ~$35/月)
  AutoStop: 月額基本料 + 接続時間 × hourly 単価
(例: Value バンドル ~$9.5/月 + $0.22/時間)

  分岐点の目安:
 月 ~130 時間 (週 ~33 時間) 以上 → AlwaysOn の方がトータルで安くなる傾向
 月 ~130 時間 未満 → AutoStop でコスト削減

  正確な分岐点は AWS Pricing Calculator で試算すること。

2-3. バンドルと OS ライセンス — 2025 年廃止対応

WorkSpaces のバンドルは「OS + CPU + RAM + Storage + (オプション) Office」の組み合わせを指す。2024-2025 年にかけての重要な変更点を以下に整理する。

Office 2016/2019 Plus アプリケーションバンドル廃止 (2025-10-14)

AWS は Office 2016 および Office 2019 を含む「Plus Applications」バンドルのサポートを 2025 年 10 月 14 日 に終了することを発表している。Microsoft の Office 2016/2019 サポート終了スケジュールに連動した対応であり、本番環境での計画的な移行が急務である。

移行の手順概要:
1. 既存 Personal/Pools の WorkSpaces で使用中のバンドルを特定 (コンソール → WorkSpaces → Bundles)
2. Office 2021 または Office 2024 を含む新バンドルへ移行 (バンドル変更には WorkSpaces の再作成が必要)
3. ユーザープロファイルデータのバックアップ計画を事前に立案して実行する

Windows ライセンス (RDS SAL)

WorkSpaces の Windows デスクトップは、月額固定の RDS SAL (Remote Desktop Services Subscriber Access License) として Windows ライセンスを内包している。組織が別途 Windows ライセンスを購入・管理する必要がなく、AWS が SAL として提供するモデルである。BYOL (Bring Your Own License) オプションを使う場合を除き、追加のライセンス管理は不要。

2-4. ディレクトリ設計 — AD 連携の選択肢

WorkSpaces は必ずディレクトリサービスと統合する必要がある。ディレクトリの選択はユーザー管理・認証・グループポリシーに直接影響し、設計ミスが後の変更コストを高める。

WorkSpaces で使用できるディレクトリの種類

AD Connector の活用

オンプレ AD を既に保有している組織では、AD Connector を経由することでオンプレ AD の認証情報をそのまま WorkSpaces に使用できる。ユーザーは既存の AD アカウントと同じパスワードでデスクトップにログインでき、IT 部門は AD の一元管理を維持できる。ただし AD Connector はオンプレ AD への依存を保持するため、オンプレ側の障害が WorkSpaces 接続に影響する点に注意が必要。

AWS Managed Microsoft AD のグループポリシー

AWS Managed Microsoft AD を使う場合、WorkSpaces の OU (Organizational Unit) に対してグループポリシーを適用できる。デスクトップのロック画面ポリシー・ドライブリダイレクトの制限・プリンタ設定などを GPO で一元管理することが本番運用のベストプラクティスである。WorkSpaces 専用 OU を作成し、そこにのみ WorkSpaces 関連ポリシーを適用する設計を推奨する。

2-5. イメージ管理とカスタムバンドル

WorkSpaces のカスタムイメージ管理は、本番導入後の標準化と迅速な展開に欠かせない。

イメージ作成の流れ

1. ベースとなる WorkSpaces Personal を起動し、必要なアプリケーションをインストール・設定
2. WorkSpaces コンソールから「イメージ作成」を実行 (起動中の WorkSpaces をイメージ化)
3. 作成したイメージからカスタムバンドルを定義 (CPU / RAM / Storage との組み合わせ)
4. カスタムバンドルを使って追加の WorkSpaces をプロビジョニング

イメージは各 AWS リージョンに保存され、別リージョンへのコピーも可能。マルチリージョン展開時はイメージのリージョン間同期スケジュールを運用設計に含めること。

更新サイクルの管理

OS パッチ・アプリケーションアップデートをイメージに適用する際は、本番イメージを直接更新せず「テストイメージ → テスト WorkSpaces → 検証 → 本番イメージ更新」のサイクルを厳守する。WorkSpaces の更新モードには「Maintained」と「Auto Update」があり、本番では「Maintained」モードで更新タイミングをコントロールすることを推奨する。

2-6. ネットワーク設計

WorkSpaces のネットワーク設計は、ユーザーの接続経路・帯域・レイテンシに直結する。

VPC・サブネット設計

WorkSpaces は VPC 内の 2 つのプライベートサブネット (異なる AZ) に展開される。サブネットは /26 以上 (64 アドレス以上) を確保し、WorkSpaces の展開数に余裕を持たせる設計が基本。パブリックサブネットへの直接配置は行わない。

接続プロトコル

WorkSpaces は以下の 2 つのリモートデスクトッププロトコルをサポートする。

エンドユーザーの接続環境 (帯域・レイテンシ) を測定してプロトコルを選択する。低帯域・モバイル接続が多い環境では DCV が安定する傾向にある。

Direct Connect / VPN との組み合わせ

オンプレ AD との連携 (AD Connector 使用時) や社内リソースへのアクセスが必要な場合、WorkSpaces の VPC とオンプレ環境を AWS Direct Connect または Site-to-Site VPN で接続する。このルートを通じた接続ではインターネット経由のトラフィックを最小化し、安定性を確保できる。

2-7. 課金最適化の実践

WorkSpaces のコストを最適化するには、以下の戦略を組み合わせる。

1. AlwaysOn / AutoStop の正確な使い分け: 前述の分岐点 (月 ~130 時間) を基準に、ユーザーごとに課金モデルを選択する
2. Pools の利用率モニタリング: WorkSpaces Pools では同時接続数ベースのプール設計が重要。過剰なプール容量は余剰コストを生む。CloudWatch メトリクス (ConnectionAttempted / InSessionLatency 等) でプール利用率を監視し、適正な最大プール容量を設定する
3. 未使用 WorkSpaces の定期レビュー: 月次で WorkSpaces コンソールの「利用状況レポート」を確認し、30 日以上未接続の WorkSpaces を停止・削除する
4. バンドル選択の見直し: ユーザーの実際の CPU / RAM 使用率を CloudWatch で計測し、オーバースペックなバンドルをダウンサイズする
5. Savings Plans の検討: WorkSpaces は Savings Plans には対応していないが、マルチアカウント環境では AWS Organizations の一括請求を活用してコスト集計を可視化する

3. Amazon WorkSpaces Web本番運用

3.1 WorkSpaces Web (WorkSpaces Secure Browser) の位置づけ

Amazon WorkSpaces Web は、フルデスクトップを配信する WorkSpaces Core とは根本的にアーキテクチャが異なる。ブラウザセッションのみをクラウド上で実行し、その画面だけをエンドポイントに届けるマネージドサービスである。クライアントデバイスにはアプリケーション・プラグイン・データのいずれもインストールされず、エンドユーザーは標準 Web ブラウザを起動するだけでアクセスできる。

「WorkSpaces Secure Browser」という呼称が AWS ドキュメントや FAQ で併用されているが、本記事では WorkSpaces Web に統一する。

WorkSpaces Web が対象とする主なユースケースは次の3類型である。

WorkSpaces Core が提供する永続デスクトップ (Personal) や非永続デスクトップ (Pools) が不要なシナリオ、すなわち「業務の大半がブラウザで完結するユーザー層」においては WorkSpaces Web がコスト対効果で勝る。デスクトップ OS ライセンス (RDS SAL) やイメージ管理のオーバーヘッドが発生しない点が大きな差別化要因である。

3.2 ポータル設計とエンドポイント構成

WorkSpaces Web ではポータル (Portal) がテナント境界となる中心リソースである。ポータルごとに専用の URL (例: portal-id.workspaces-web.<region>.amazonaws.com) が払い出される。ポータルには以下のリソースを関連付けて機能を構成する。

ネットワークの2層構造:

WorkSpaces Web のネットワークはフロントエンド層とバックエンド層の2層で構成される。

• フロントエンド層 (AWS マネージド): エンドユーザーのブラウザからポータル URL への接続を受け付ける層。AWS が管理するインフラで、SLA・スケーリングは AWS 責任範囲。
• バックエンド層 (VPC 管理下): ポータルが社内 Web アプリやオンプレミスシステムへアクセスする際の出口。プライベートサブネットに ENI が作成され、Direct Connect / VPN で社内接続が可能。インターネット向け通信は NAT Gateway を経由する。

この2層分離により、エンドポイントから見るとすべての通信は WorkSpaces Web ポータルで終端される。バックエンドの社内システムはインターネットに直接露出しない。

ポータル URL のカスタムドメイン対応:
WorkSpaces Web は標準で AWS 提供の URL が払い出されるが、組織内ユーザー向けにカスタムドメインを設定することも可能である。Route 53 や外部 DNS で CNAME を設定し、社内標準の URL でアクセスさせることで、エンドユーザーの利便性と認知を高められる。

3.3 アクセス制御 — ユーザー設定によるデータ漏洩防止

WorkSpaces Web のアクセス制御の中核はユーザー設定 (User Settings) リソースである。クリップボード・ダウンロード・印刷などのデータ流出経路を操作単位で制御できる。

制御可能なアクション一覧:

URL フィルタリング:
Trusted Sites (許可 URL リスト) と Blocked Sites (ブロック URL リスト) をポータルに設定できる。カテゴリベースのフィルタリングはサービスに組み込まれており、SNS・動画配信・ギャンブルサイト等をカテゴリ単位でブロックできる。高度なコンテンツインスペクションが必要な場合は、Network Settings の NAT Gateway 経路にプロキシを配置して対応する。

ロール別ポリシー分離:
User Settings はポータルと 1:1 ではなく、部門・ロール別に複数定義して複数ポータルに割り当てられる。コールセンター向けの「全制限ポリシー」と、管理部門向けの「印刷のみ許可ポリシー」を別々に定義し、対応するポータルにそれぞれ紐付けるのが典型的な設計パターンである。

3.4 SAML 2.0 IdP連携

WorkSpaces Web の認証は SAML 2.0 または IAM Identity Center を通じて行われる。ローカルユーザー認証は提供されておらず、必ず外部 IdP が介在する設計となっている。

3.4.1 対応 IdP と連携パターン

3.4.2 SP-initiated フロー (推奨)

エンドユーザー → WorkSpaces Web ポータル URL にアクセス
→ ポータル (SP) が IdP へ AuthnRequest をリダイレクト送信
→ IdP 画面でユーザー認証 (ID / PW + MFA)
→ IdP が SAML アサーションを HTTP POST でポータル (ACS URL) へ送信
→ ポータルがアサーションを検証しセッション確立
→ ブラウザセッション開始

SP-initiated フローはリクエストの発起点が明確なため、アサーション注入攻撃のリスクが低い。本番環境ではこちらを標準とする。

3.4.3 IdP-initiated フロー

エンドユーザー → IdP ポータル (Okta App Dashboard / My Apps 等) にログイン
→ WorkSpaces Web アプリアイコンをクリック
→ IdP が SAML アサーションを HTTP POST でポータルへ送信
→ ポータルがアサーションを検証しセッション確立

IdP-initiated フローは利便性が高くシングルクリックで起動できる一方、SAML アサーションを外部から注入されるリスクがある。使用する場合は IdP 側で以下を設定する。

• Audience (SP Entity ID) の厳格な制限
• NotOnOrAfter (有効期限) を短く設定 (5分以内推奨)
• Destination 属性を ACS URL に固定

3.4.4 SAML アサーション暗号化

WorkSpaces Web は SAML アサーションの暗号化をサポートする。設定手順の概要は以下のとおりである。

1. WorkSpaces Web コンソールから SP 暗号化証明書 (X.509 公開鍵) をダウンロード
2. IdP 側に SP 証明書をアップロードし、アサーション暗号化を有効化 (AES-256 / RSA-2048 推奨)
3. WorkSpaces Web の IdP 設定で IdP メタデータ URL または XML ファイルをアップロード

暗号化を有効にすると、通信経路上でアサーション内の属性値 (メールアドレス・グループ情報・カスタム属性) が保護される。コンプライアンス要件 (HIPAA / PCI-DSS 等) がある組織では必須設定として扱う。

3.5 MFA とコンテキストアクセスポリシー

WorkSpaces Web 自体には MFA エンジンが内蔵されていない。MFA は接続先の IdP 側で適用するアーキテクチャである。これは IdP に MFA ポリシーを集中管理させるゼロトラスト設計の原則と整合する。

IAM Identity Center での MFA 設定:
– Identity Center の [設定] → [多要素認証] で「コンテキストが変化したとき、または常に」を選択
– デバイス登録方式: TOTP (Authenticator アプリ) / FIDO2 セキュリティキー / 組み込みデバイス認証
– 「MFA をバイパスできるネットワーク」に社内 IP を除外設定することで、VPN 接続時はパスワードのみ許可といったポリシーも構成可能

Microsoft Entra ID での Conditional Access Policy 活用:

WorkSpaces Web は SP として IdP からのアサーションを受け取るだけであり、コンテキスト条件のチェックはすべて IdP 側で完結する。複数の AWS EUC サービスを利用する組織でも、IdP の CAP 一箇所でアクセスポリシーを統一管理できる。

3.6 トラスト境界の設計

WorkSpaces Web 本番運用の核心はトラスト境界の設計にある。4つの境界を意識して設計する。

境界 1: エンドポイント → WorkSpaces Web ポータル
– TLS 1.2 以上で暗号化。クライアント証明書は不要 (IdP が認証を担当)
– IP Access Settings を使用して送信元 IP 範囲を絞り込む
– エンドポイントには何もインストールされないため、管理外デバイスでも安全に利用可能

境界 2: ポータル → VPC ネットワーク設定
– バックエンド ENI がプライベートサブネットに作成される
– セキュリティグループで通信先 (HTTPS/443 等) を最小化
– 社内 Web アプリへの通信はすべてこの ENI を経由し、インターネットへの直接露出はない

境界 3: VPC → オンプレミス / クラウドサービス
– Direct Connect または Site-to-Site VPN でオンプレミスシステムへ接続
– AWS PrivateLink を使用して VPC エンドポイント経由で AWS サービスへアクセス
– NAT Gateway 経由のインターネットアクセスはセキュリティグループと URL フィルタで制御

境界 4: ブラウザセッション内
– User Settings (アクセス制御) によりクリップボード・ダウンロード・印刷が制御される
– セッションデータはクラウド上のブラウザプロセスにのみ存在し、エンドポイントには残らない
– セッション終了と同時にクラウド上のプロセスが破棄される (データの残留なし)

ゼロトラスト設計との整合性:
WorkSpaces Web は Remote Browser Isolation (RBI) の原理でエンドポイントのリスクを遮断する。「デバイスが信頼できるか」ではなく「アクセスするコンテンツをエンドポイントから隔離できるか」を優先する設計であり、BYOD 推進・外部スタッフ活用の場面でゼロトラスト的な要件を低コストで実現する。

3.7 運用チェックリストと CLI 操作

本番展開前チェックリスト:

よく使う CLI コマンド:

# ポータル一覧の確認
aws workspaces-web list-portals \
  --query 'portals[*].{id:portalId,status:portalStatus}' \
  --output table

# User Settings (アクセス制御ポリシー) の一覧
aws workspaces-web list-user-settings \
  --query 'userSettings[*].{arn:userSettingsArn,copyAllowed:copyAllowed,downloadAllowed:downloadAllowed,printAllowed:printAllowed}' \
  --output table

# IdP (Identity Provider) 設定の確認
aws workspaces-web list-identity-providers \
  --portal-arn <portal-arn> \
  --query 'identityProviders[*].{arn:identityProviderArn,name:identityProviderName,type:identityProviderType}' \
  --output table

# IP Access Settings の確認
aws workspaces-web list-ip-access-settings \
  --query 'ipAccessSettings[*].{arn:ipAccessSettingsArn,description:description}' \
  --output table

3.8 監視・ログ・コスト管理

WorkSpaces Web の本番運用では、接続状態・セキュリティ・コストの3軸を継続的にモニタリングする。

CloudWatch メトリクス

WorkSpaces Web はフルマネージドサービスであり、インフラレイヤーのメトリクスは AWS が管理する。オペレーターが主に監視すべきはセッション数の異常増加と接続失敗パターンである。

CloudWatch Logs によるセッション監査

WorkSpaces Web は以下のログを CloudWatch Logs に出力できる。ポータル設定でログ出力先のロググループを指定する。

# セッションログを出力するロググループの設定 (コンソール操作が推奨だが CLI でも設定可)
aws workspaces-web update-portal \
  --portal-arn <portal-arn> \
  --additional-encryption-context '{"logging":"enabled"}'

セッションログには以下の情報が含まれる:
– 接続ユーザー ID (IdP のサブジェクト)
– セッション開始/終了の日時
– アクセスした URL とドメイン
– 転送データ量 (ダウンロード/アップロード)
– セッション終了理由 (ユーザー切断 / タイムアウト等)

これらを CloudWatch Logs Insights でクエリすることで、「特定ユーザーがアクセスした URL 一覧」「過去30日間の接続パターン」「アクセス制御違反の試み」を抽出できる。

コスト管理

WorkSpaces Web の課金構造は次のとおりである。

WorkSpaces Personal (月額固定) と比較すると、WorkSpaces Web はアクティブユーザー数に比例する変動課金であり、月次ユーザー数が少ない初期展開段階やパイロット運用でコストを抑えやすい。Cost Explorer で workspaces-web サービスのコストをタグ別にフィルタし、部門単位のコストを可視化することを推奨する。

3.9 マルチポータル構成と組織展開

大規模組織や複数の部門・子会社を持つ企業では、複数のポータルを構成するマルチポータル設計が必要になる場合がある。

マルチポータルが必要なシナリオ:
– 部門 A と部門 B でアクセス制御ポリシー (User Settings) が大きく異なる
– リージョンをまたいだ展開でエンドユーザーのレイテンシを最適化したい
– 子会社ごとに独立した URL・IdP 設定が必要
– 本番環境とステージング環境を明確に分離したい

マルチポータルの注意点:
各ポータルは独立した課金単位となるため、ポータル数が増えると固定コストが積み上がる。部門単位でポータルを分けるよりも、User Settings と IP Access Settings の組み合わせで1ポータルに集約する設計を優先し、真にポリシーが分岐する場合のみポータルを追加することを推奨する。

AWS Organizations との統合:
WorkSpaces Web はリソースベースのアクセス制御に対応しており、AWS Organizations の SCP (Service Control Policy) でポータルリソースへのアクセスをアカウント単位で制限できる。マルチアカウント構成では中央管理アカウントでポータルを管理し、RAM (Resource Access Manager) でネットワーク設定を共有する設計が有効である。

4. Amazon AppStream 2.0本番運用

AppStream 2.0 を GPU ヘビーな業務アプリ (CAD / 3D モデリング / 映像編集) 配信の文脈で深掘りした記事 (Game & Media Vol1) は既出である。本節ではそれと重複を避け、AppStream 2.0 を End User Computing ポートフォリオの「アプリケーション単位配信層」として位置づけ、WorkSpaces (フルデスクトップ) との使い分け・DaaS としての判断軸に焦点を絞る。Fleet タイプや Image Builder の基礎は前掲記事を参照されたい。

4.1 AppStream 2.0 の位置づけ — EUC ポートフォリオにおけるアプリ配信層

Amazon AppStream 2.0 (AWS ドキュメント上では 2024 年以降「Amazon WorkSpaces Applications」への名称統合が進行中) は、特定のアプリケーションをストリーミング配信するマネージドサービスである。WorkSpaces Core がフルデスクトップ OS ごと配信するのに対し、AppStream 2.0 はアプリケーション単体またはグループをブラウザ経由でストリーミングする。

EUC ポートフォリオにおける4サービスの配信単位と永続性は次のとおりである。

名称統合の動向 (2024-2025):
AWS は EUC サービスの統合ブランド化を進めており、AppStream 2.0 は公式ドキュメントの一部で「Amazon WorkSpaces Applications」として言及されるケースが増えている。サービスの機能・API には変更はなく、ロードマップ上の名称変更として理解しておけばよい。コンソール上のサービス名は執筆時点では AppStream 2.0 のままであり、IaC コードのリソース名変更は現時点で不要である。社内ドキュメントやダッシュボードラベルには、将来の名称完全統合に備えて別名を注記しておくことを推奨する。

4.2 Fleet タイプ3種 — 用途別コスト最適化

AppStream 2.0 のコンピューティング基盤はフリート (Fleet) である。フリートには3つのタイプがあり、利用パターンに応じて選択する。

Always-On フリート

On-Demand フリート

Elastic フリート (サーバーレス)

フリートタイプ選択マトリクス:

4.3 スタックと Auto Scaling

スタック (Stack) の役割

フリートは単独では動作せず、スタック (Stack) と関連付けて使用する。スタックはユーザー向けのアクセス設定・ストレージ設定・アクセス制御を定義するリソースである。

ストレージコネクタの活用:
AppStream 2.0 では「Home Folders」機能で S3 バケットをユーザーのホームドライブとしてマウントできる。On-Demand / Elastic フリートはセッション終了でデータが消えるため、ファイルを持ち越す必要がある場合は Home Folders の設定が必須である。また Google Drive / OneDrive との直接統合も提供されており、既存のクラウドストレージとシームレスに連携できる。

Auto Scaling ポリシーと Scaling Optimizer

On-Demand フリートでは Auto Scaling でインスタンス数を動的に制御する。CloudWatch メトリクス CapacityUtilization を基準にした Target Tracking ポリシーが標準的である。

# Target Tracking スケーリングポリシーの設定例
aws application-autoscaling put-scaling-policy \
  --service-namespace appstream \
  --resource-id fleet/MyFleet \
  --scalable-dimension appstream:fleet:DesiredCapacity \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
 "TargetValue": 75.0,
 "CustomizedMetricSpecification": {
"MetricName": "CapacityUtilization",
"Namespace": "AWS/AppStream",
"Statistic": "Average"
 },
 "ScaleInCooldown": 300,
 "ScaleOutCooldown": 60
  }'

Scaling Optimizer ツール:
AppStream 2.0 は Scaling Optimizer と呼ばれる分析ツールを提供しており、過去のセッション使用パターン (時刻別・曜日別) を分析して最適なスケーリングパラメータを提案する。実装前に Scaling Optimizer の推奨値を確認し、Over-provisioning (コスト過大) / Under-provisioning (ユーザー待機) のバランスを事前に調整しておくことを推奨する。

スケジュールスケーリングの活用:
Always-On フリートで夜間・週末のコストを削減したい場合は、スケジュールスケーリングを使ってインスタンス数の最小値を夜間0時〜7時は最小値まで引き下げる設定が有効である。Auto Scaling ルールとスケジュールルールを組み合わせることで、コストと可用性の両立が図れる。

4.4 WorkSpaces vs AppStream 2.0 — DaaS 選択基準

本節の核心テーマは「いつ WorkSpaces を選び、いつ AppStream 2.0 を選ぶか」である。

判断フレームワーク:

質問1: ユーザーはフルデスクトップ OS が必要か？
  → YES → WorkSpaces Personal (永続) または WorkSpaces Pools (非永続) へ
  → NO  → 質問2へ

質問2: アクセスするのは Web アプリだけか？
  → YES → WorkSpaces Web (Secure Browser) へ
  → NO  → 質問3へ (ネイティブアプリが必要)

質問3: 配信するのが特定のアプリケーション群に限定されるか？
  → YES → AppStream 2.0 へ (アプリ単位配信)
  → NO  → WorkSpaces Personal または Pools へ (フルデスクトップ)

選択マトリクス — 典型パターン:

コスト比較軸:

AppStream 2.0 が WorkSpaces より優位なシナリオ:
– ユーザーが特定のアプリケーションセットしか使わない (会計・統計ツール・設計アプリ等)
– デスクトップ OS の管理 (パッチ / GPO / プロファイル) を省きたい
– アプリを複数部門・拠点に管理コスト低く均一展開したい
– OS ライセンス (RDS SAL) コストを削減したい

AppStream 2.0 より WorkSpaces が優位なシナリオ:
– ユーザーが日常的に複数アプリを横断して作業する (Office + 業務アプリ + ブラウザ + 通話)
– 永続デスクトップ設定 (壁紙・フォント・設定ファイル) を維持したい
– GPO によるデスクトップポリシー一元管理が組織の標準になっている
– エンドユーザーが「デスクトップ」という概念に慣れており、アプリ単体起動に抵抗感がある

4.5 イメージ管理とアプリケーションカタログ

AppStream 2.0 でアプリケーションを配信するには、まずイメージ (Image) を作成しフリートに紐付ける。イメージ管理は AppStream 2.0 の運用基盤の核心である。

Image Builder によるイメージ作成フロー

Image Builder インスタンス起動
  → アプリケーションインストール・設定 (RDP 接続または AWS 管理コンソール)
  → アプリケーションのデスクトップアイコン登録 (AppStream 2.0 Image Builder エージェント)
  → イメージ作成 (スナップショット取得)
  → フリートへの適用

Elastic フリートのみ Image Builder 不要 (カスタムイメージ非対応)。Always-On / On-Demand フリートはカスタムイメージが必須。

イメージ更新サイクルの管理:
– OS パッチ適用はイメージ単位で行う。既存イメージをソースとして新規 Image Builder を起動し、パッチ後に新イメージを作成する
– アプリケーションバージョンアップも同様のフローで行い、テストフリートで動作確認後に本番フリートへ適用する
– イメージは定期的に不要なバージョンを削除してコストを最適化する (保存イメージ数 × ストレージコスト)

アプリケーションカタログ

AppStream 2.0 のスタックにはアプリケーションカタログを設定できる。ユーザーがセッション開始時に表示されるアプリ一覧がカタログである。

特定のユーザーグループにのみ特定アプリを表示させるグループ別カタログは、部門横断展開で不要アプリを非表示にしてユーザー体験を向上させる上で有効である。

4.6 監視・ログ・コスト管理

CloudWatch メトリクス

AppStream 2.0 は以下の CloudWatch メトリクスを提供する。

PendingSessions が 0 より大きい状態が継続する場合はフリートの最小キャパシティが不足している。CloudWatch アラームで閾値超過を検知し、担当者に通知する設定を推奨する。

コスト管理

AppStream 2.0 の課金は Fleet タイプとインスタンスタイプによって大きく異なる。

月次コストは Cost Explorer で appstream サービスでフィルタし、フリート単位のタグを使って部門別コストを可視化することを推奨する。

4.7 ユーザー体験の最適化

AppStream 2.0 の End User Computing としての価値は、ユーザーが「ローカルアプリと遜色ない体験」を得られるかどうかで評価される。

接続品質の向上:
– インスタンスタイプの選択: CPU / GPU バウンドのアプリはインスタンスサイズを上げる。画面解像度が高い場合は GPU グラフィック処理のインスタンス (G4dn 等) を検討する
– ネットワーク帯域: AppStream 2.0 は適応的ビットレートを採用。クライアント回線の帯域が低い場合は解像度・フレームレートが自動調整される
– NICE DCV プロトコル: AppStream 2.0 の標準配信プロトコル。低レイテンシ・高圧縮率でリモートアクセス体験を最適化する

ユーザーサポート体制:
– 初回接続ガイド: ブラウザ (Chrome / Edge 推奨) と許可するポート (443 / 8443) を事前にユーザーに案内する
– クライアント (Windows ネイティブ) の提供: ブラウザアクセスが不安定な場合は Windows クライアントアプリを配布する
– セッション録画 (監査目的): スタックの設定でセッション録画を有効にし、S3 に保存できる。コンプライアンス要件がある環境でのユーザー操作の証跡管理に活用する

5. DaaS設計 — 3サービスの使い分け

AWS EUC を本番設計するとき、最初に決めるべきは「どのサービスで何を届けるか」だ。WorkSpaces (Personal / Pools)・WorkSpaces Web・AppStream 2.0 の 3サービスは、利用形態・永続性・課金モデルが根本的に異なる。どれか1つで全員を賄おうとすると必ず過剰コストか機能不足が生まれる。

実際の本番環境では、3サービスを「フルデスクトップ層 / セキュアブラウザ層 / アプリケーション配信層」として役割分担し、ユーザーグループごとに割り当てる設計が有効だ。以下の判断マトリクスはサービスを絞り込む一次スクリーニングとして使う。

5-1. 3サービス統合判断マトリクス

最初の選択分岐は「ユーザーのデスクトップ設定・ローカルファイルを次回セッションでも維持する必要があるか」だ。Yes なら WorkSpaces Personal が適する。No の場合は「アプリ単位のみ必要か」を問い、Yes なら AppStream 2.0、No (フルデスクトップが必要) なら WorkSpaces Pools が適する。WorkSpaces Web は「Web アプリ・社内ポータルのみ」という要件に絞って採用する。

なお、1人のユーザーが複数サービスを使い分けることも可能だ。たとえば「WorkSpaces Personal を主デスクトップとして使いつつ、機密の人事システムへのアクセスのみ WorkSpaces Web を経由させる」という構成は、セキュリティ要件とユーザー利便性のバランスを取る実践的なアプローチだ。サービスの組み合わせは固定観念にとらわれず、ユーザーグループの実態に応じて柔軟に設計する。

5-2. 判断軸 5 要素の詳解

(1) 永続性要否

WorkSpaces Personal は、ユーザーごとに独立した Windows デスクトップを常時保持する。デスクトップ上のアイコン配置・ブラウザのブックマーク・ローカルドキュメントが次のログイン時もそのまま残る。オンプレミス PC 環境がそのままクラウドに移るような体験を重視する用途に向く。

WorkSpaces Pools は共有イメージから起動し、セッション終了時にユーザープロファイルを削除する非永続モデルだ。AutoStop モードと組み合わせることで、交代制勤務・コールセンター・季節雇用など「同じ業務端末を複数人が使い回す」用途でコストを大幅に下げられる。ホームフォルダは FSx for Windows File Server または S3 へリダイレクトする設計が前提となる。

WorkSpaces Web と AppStream 2.0 は「デスクトップを持たせない」設計思想に基づく。セッション外でデータを端末に残さないため、機密性の高い社内システムへ社外パートナーがアクセスする場面など、ゼロトラスト的なアクセス制御に適する。

(2) アプリケーション単位 vs デスクトップ単位

「ツールをいくつか使えれば良い」ユーザー向けには AppStream 2.0 が最適だ。フルデスクトップを払い出すと不要な設定変更・データ持ち出しリスクが増えるが、AppStream ではウィンドウ単位で特定アプリのみを表示できるため、ユーザーに「クラウド上の PC」という意識を持たせずに使わせられる。

複数の業務アプリを行き来しながら働くユーザーには WorkSpaces フルデスクトップの方が操作性で優位だ。ウィンドウ管理・クリップボード・ファイルの貼り付けがネイティブに機能するため、ユーザー教育コストが低い。

WorkSpaces Web は「社内 SaaS / Web アプリへのアクセスをブラウザ経由で制御したい」要件に特化する。セキュアブラウザとしてコピー・貼り付け・ダウンロードを管理コンソールで制限できるため、審査業務・外部委託スタッフのアクセス管理として有効だ。

(3) GPU 要否

GPU を要求するワークロード (3D モデリング・CAD・映像編集・機械学習推論) には AppStream 2.0 の G4dn / G5g インスタンスが主力だ。WorkSpaces Personal にも G4dn ベースのバンドル (Graphics / Graphics Pro) が存在するが、常時課金の月額固定モデルであるためコストが高止まりしやすい。利用時間が短い・ユーザー数が変動する GPU 用途は AppStream の On-Demand / Elastic フリートが適する。WorkSpaces Web は GPU 非対応のため、映像処理・設計ツールを動かせない。

(4) コスト構造

WorkSpaces Personal の AlwaysOn は月額固定制だ。米国東部リージョン (us-east-1) 基準で Standard バンドル (2vCPU/4GB/100GB SSD) は月額約 $35、Performance (2vCPU/8GB) 約 $60、Value (2vCPU/2GB) 約 $25 の水準となる (リージョン・バンドルにより変動)。稼働日数に関わらず定額なため、フル稼働ユーザーには割安だが、月20日未満のライトユーザーには割高になりやすい。

WorkSpaces Pools の AutoStop は接続中のみ課金する。月の接続時間が損益分岐点を下回るユーザーには AutoStop が有利だ。詳細な損益分岐点計算は §5-4 で後述する。

AppStream 2.0 の On-Demand は Fleet が起動する期間のみ課金される。Elastic フリートはユーザー接続時に OS 起動から開始するためコールドスタート (1〜2分) があるが、インスタンス管理が不要でサーバーレスに近い運用ができる。

(5) セキュリティ要件

WorkSpaces はデスクトップが AWS リージョン内に閉じており、エンドユーザーのデバイスには画面ストリームしか届かない。リモートワーク環境でのデータ漏洩対策として効果的だ。VPC 内のサブネットにプロビジョニングされ、インターネットアクセス制御も VPC ルーティング + セキュリティグループで実施できる。

WorkSpaces Web は特に BYOD (私用デバイス) からのアクセスを「ブラウザ経由のみ」に制限できる。コピー・貼り付け・スクリーンキャプチャをサービス側でブロックできるため、管理外デバイスへのデータ流出を防ぎやすい。

5-3. ディレクトリ設計 — AD連携の共通化

3サービスを並行導入する場合、ディレクトリ設計が最も影響範囲の広い設計判断になる。WorkSpaces は AWS Directory Service が必須、AppStream 2.0 はオプション、WorkSpaces Web は IdP (SAML) 側でユーザー管理できる。

ディレクトリ選択肢は「AWS Managed Microsoft AD」「AD Connector」「Simple AD (WorkSpaces 非推奨)」の3種がある。実務では Managed AD または AD Connector の二択となる。ユーザー数 500以下は Standard Managed AD、それ以上は Enterprise Managed AD を選ぶ。Simple AD は WorkSpaces の利用には制限があり、本番環境には推奨されない。

推奨パターン: AWS Managed Microsoft AD を共通ハブとする

AWS Managed Microsoft AD (Enterprise エディション) を1つ立て、WorkSpaces Personal / Pools の両方から参照する構成を基本とする。オンプレミスに既存の Active Directory がある場合は「信頼関係 (Trust)」を結んでシングルサインオンを実現するか、AD Connector で既存 AD にプロキシする。

AD Connector は既存 AD への読み書きをブリッジするが、AD 本体をクラウドに持たない分コストは低い。ただし AD Connector ノード自体の可用性設計が重要だ。Managed AD は AWS が内部的に Multi-AZ 構成で可用性を担保しており運用負荷が低い。

AppStream 2.0 の AD 統合

AppStream 2.0 に Microsoft AD (Managed AD または AD Connector) を統合することで、ドメイン参加済みのフリートを起動できる。ドメイン参加フリートはグループポリシー適用・ホームフォルダマッピングが可能になり、既存 AD 環境を持つ企業が AppStream を EUC ポートフォリオに追加するときの自然な選択だ。

AD 統合なしの AppStream 2.0 も動作する。ユーザー認証は Amazon Cognito または SAML/OIDC IdP 直接統合となる。SaaS 型アプリ配信 (特定ツールだけ外部パートナーに開放する) では AD 不要パターンが多い。

IAM Identity Center との統合

WorkSpaces Web は IAM Identity Center + SAML 2.0 IdP を認証基盤として使う。Managed AD と IAM Identity Center を連携させることで、WorkSpaces Personal / Pools と WorkSpaces Web のログインを同一 IdP で統一できる。Okta・Microsoft Entra ID・Ping Identity など主要 IdP は IAM Identity Center のカスタムアプリケーションとして登録できる。

AppStream 2.0 も Amazon Cognito User Pool または SAML 2.0 対応の外部 IdP でアクセスを制御できる。ユーザーごとに異なる IdP を使う複合環境でも、フリートごとに認証設定を変えることで対応できる。

5-4. コスト試算 — AlwaysOn vs AutoStop 損益分岐

WorkSpaces の課金モデル選択は本番設計で間違えやすいポイントだ。AlwaysOn (月額固定) と AutoStop (時間課金) の損益分岐点を事前に把握しておく。

AutoStop の課金構造

AutoStop モードでは、ユーザーがセッションを切ると指定した待機時間後にインスタンスが停止する。停止中はインスタンス時間課金は発生せず、EBS ストレージ (ルートボリューム) のみ課金される。接続中はインスタンスタイプに応じた時間課金となる。

損益分岐点の試算方法

AlwaysOn 月額固定費 = P_ao (例: Standard バンドル = $35/月)
AutoStop 月額費 = P_as_hourly × H + P_storage
 (H = 月接続時間、P_storage = EBS ストレージ月額)

損益分岐点 H* = (P_ao - P_storage) / P_as_hourly

Standard バンドル (us-east-1 基準) の場合:
– AlwaysOn: 約 $35/月
– AutoStop 時間課金: 約 $0.57/時間 (2vCPU / 4GB)
– 損益分岐点: 35 ÷ 0.57 ≈ 61 時間/月

月61時間以上接続するユーザーには AlwaysOn が割安、61時間未満なら AutoStop が有利だ。1日8時間・週5日勤務は月約160時間になるため、フルタイム勤務には AlwaysOn が適する。パートタイム・補助業務ユーザーは AutoStop の検討価値が高い。

WorkSpaces Pools の AutoStop

WorkSpaces Pools では AutoStop の課金単位がユーザーセッション (接続時間) になる。Pools の特性上、同一時間帯に接続するユーザー数の最大値がフリートキャパシティを決める。ピーク同時接続率 (例: 300ユーザーのうち最大180人が同時接続 = 60%) を基に最小フリートサイズを設定し、Auto Scaling で拡縮するコスト設計が基本だ。

AppStream 2.0 の課金形態選択

Always-On は接続不要でも課金されるため、週5日・1日8時間フル利用する専任ユーザー向けだ。Elastic はイメージ管理・Fleet 管理が不要でスケールが全自動だが、コールドスタートが許容できる用途に限る。ユーザー数が変動しやすい季節需要・教育研修には Elastic が特に有効だ。

5-5. 監視運用 — CloudWatch メトリクスとセッション監視

WorkSpaces の主要メトリクス

WorkSpaces は CloudWatch に以下のメトリクスを発行する:

ConnectionFailure が高い場合はネットワーク経路 (VPC ルーティング・NAT Gateway・Direct Connect) の疎通確認を優先する。InSessionLatency が高い場合は接続プロトコルを PCoIP から WorkSpaces Streaming Protocol (WSP) へ変更することで改善する場合がある。

AppStream 2.0 の主要メトリクス

セッション使用率最適化

WorkSpaces Pools / AppStream 2.0 は「アイドル切断タイムアウト」と「スケジュールスケーリング」の組み合わせでコストを最適化する。業務時間 (平日 9:00-18:00) に最小キャパシティを高め、夜間・週末はスケールインする Auto Scaling スケジュールを設定する。接続数の実績メトリクスを1ヶ月分蓄積してから、ピーク同時接続率を算出して最小・最大キャパシティを調整するのが現実的なアプローチだ。

WorkSpaces Personal の未使用インスタンスは CloudWatch の SessionConnected メトリクスで特定できる。30日以上セッションがない WorkSpaces は削除または AutoStop への変更を検討する。定期的なライセンス棚卸しとセットで実施する。

CloudWatch ダッシュボードの設計指針

EUC 3サービスを横断して監視するには、CloudWatch ダッシュボードを以下の4ウィジェット構成で作成することを推奨する。

アラームの優先度は「ユーザーに直接影響するもの」を最優先とする。InsufficientCapacityError と Unhealthy は「Critical」として即時通知、ConnectionFailure 率上昇は「Warning」として5分継続時に通知するルールが実務で有効だ。

また、Amazon CloudWatch Anomaly Detection を WorkSpaces の ConnectionAttempt に設定することで、急激なアクセス増 (ランサムウェア感染端末の大量接続試行など) を通常パターンとの乖離として検知できる。

EUC 運用の月次レビュー項目

月次レビューを定例化することで、コスト最適化の機会 (バンドルダウングレード・AutoStop 切替) を継続的に発見できる。

5-6. 移行観点 — オンプレ VDI / 物理 PC からの移行ステップ

オンプレミス VDI や物理 PC から AWS EUC サービスへ移行する際は、段階的マイグレーションが推奨される。一括移行はユーザー影響が大きく、サポートコストが集中するためだ。

移行フェーズ設計

フェーズ 1: パイロット (20〜50 ユーザー・低リスクグループ)
  目的: 接続品質・アプリ動作・ディレクトリ統合を本番環境で検証
  期間: 4〜8 週間
  成功基準: セッション成功率 99% 以上 / ユーザー満足度 70% 以上

フェーズ 2: 段階展開 (部署単位・50〜200 ユーザー/フェーズ)
  目的: サポート体制の習熟・イメージ更新プロセスの標準化
  期間: 2〜4 週間/フェーズ
  注意: AD 統合・プロファイル移行・アプリケーション互換性テスト

フェーズ 3: フル展開 (全ユーザー)
  物理 PC・オンプレ VDI の廃止スケジュールと連動させる

プロファイル移行の注意点

WorkSpaces Personal へのプロファイル移行で最もトラブルが多い箇所は「ユーザーホームディレクトリの移行」だ。物理 PC のドキュメント・デスクトップデータを D: ドライブ (ユーザーボリューム) へ移行するには次の手順が確実だ。

手順1: 旧 PC から OneDrive / S3 / FSx へ一時バックアップ
手順2: WorkSpaces 初回起動後、D: ドライブへコピー
手順3: 旧環境を 2〜4 週間は読み取り専用で残す (差分確認用)

アプリケーション互換性テスト

WorkSpaces Pools / AppStream 2.0 のイメージ作成時に、全業務アプリのインストール・起動・印刷・ファイル保存を事前テストする。特に確認すべき項目を以下に示す。

• 32bit アプリの Windows 10/11 互換性 (要テスト)
• ローカルドライブパス (C:\Users\username) を直書きしているアプリの設定変更
• USB デバイス依存のアプリ (WorkSpaces ではデバイスリダイレクト設定が必要)
• Office ライセンス (Microsoft 365 Apps vs Office LTSC vs RDS SAL の違いを確認)
• 社内ネットワーク接続 (WorkSpaces 移行後は専用クライアント不要になるか確認)

5-7. マルチサービス統合設計 — 3サービス混在環境の実践パターン

大規模組織では WorkSpaces・WorkSpaces Web・AppStream 2.0 を同時に運用する「マルチサービス EUC 環境」が現実的な姿だ。以下に代表的な3つの統合パターンと、それぞれの運用上のポイントを示す。

パターン A: 役割分担型 (フルデスクトップ + アプリ配信の並行)

正社員にはWorkSpaces Personal (AlwaysOn)、派遣・契約社員にはWorkSpaces Pools (AutoStop)、外部委託先には AppStream 2.0 On-Demand を割り当てる構成だ。ユーザーの雇用形態・利用頻度・セキュリティ要件が明確に分かれる組織に向く。

ディレクトリは Managed AD を共通基盤とし、OU で3グループを分けて GPO を個別適用する。コスト管理は「ユーザーグループ × サービス種別」のタグ戦略で AWS Cost Explorer から分析する。

パターン B: セキュアアクセス型 (WorkSpaces Web + WorkSpaces Personal の組み合わせ)

業務の主軸は WorkSpaces Personal でカバーしつつ、特定の機密 Web システム (人事情報・財務情報) へのアクセスは WorkSpaces Web を使わせる構成だ。WorkSpaces Personal からでも WorkSpaces Web のポータルを経由することで、機密システムへのアクセスログを集中管理できる。

この構成では WorkSpaces Personal と WorkSpaces Web の両方を IAM Identity Center で統合し、ユーザーはひとつの IdP でどちらにもサインインできる体験を提供する。

パターン C: BYOD 完全対応型 (WorkSpaces Web + AppStream 2.0 中心)

「社員 PC を支給しない」BYOD 環境では、WorkSpaces Web を主要ブラウザアクセス基盤とし、ネイティブアプリが必要な業務にのみ AppStream 2.0 を使う構成が現実的だ。エンドユーザーのデバイスに何もインストールせず、すべてクラウド側で管理する。

クライアント要件を最小化できる反面、WorkSpaces Web のブラウザ制限 (コピー・貼り付け・ダウンロード) がユーザー体験に影響する。ブラウザ制限ポリシーは部門・業務種別ごとにきめ細かく設定することが重要だ。

3サービス統合時のネットワーク設計ポイント

3サービスを同一 VPC で運用する場合、サブネットの分離設計が重要だ。

各サービスのサブネットからインターネットへのアクセスはいずれも NAT Gateway 経由が基本だ。WorkSpaces は PCoIP / WSP プロトコル用のポート (443 / UDP 4172 等) を許可したセキュリティグループを設定する。AppStream 2.0 は HTTPS (443) + WSS (443) のみで動作するためシンプルだ。

コスト一括管理のタグ戦略

複数 EUC サービスのコストを一元管理するには、AWS タグを統一ルールで付与することが効果的だ。

推奨タグ構造:
  CostCenter: <部門コード>
  EUCService: WorkSpaces-Personal / WorkSpaces-Pools / WorkSpaces-Web / AppStream
  UserGroup: fulltime / parttime / contractor / partner
  Environment: production / staging / dev

AWS Cost Explorer のフィルタリングで「EUCService タグ別コスト」を確認することで、サービスごとの月次コスト推移を把握しやすくなる。予算アラートも EUCService タグ単位で設定すると、突発的なコスト増を早期検知できる。

EUC ガバナンス体制の構築

3サービスを並行運用する組織では、EUC 全体のガバナンス体制を定義することが重要だ。以下の役割分担を組織内で明文化しておく。

この体制を事前に整えておくことで、サービス拡大時の運用負荷増大を組織として吸収できる。EUC の利用ユーザー数が増加しても、役割分担が明確であれば担当者1〜2名の増員で対応できる規模感になる。

§5 まとめ — DaaS設計の核心

3サービスの使い分けにおいて最も重要な判断軸は「永続性」「配信単位 (デスクトップ vs アプリ)」「コスト構造」の3点だ。これらを軸に判断マトリクスを使ってユーザーグループごとにサービスを割り当て、ディレクトリは Managed AD を共通ハブとして設計することが、後戻りの少ない安定した EUC 基盤につながる。コスト最適化は損益分岐点を把握してから AlwaysOn / AutoStop を仕分けし、CloudWatch による継続的な使用率モニタリングで維持する。移行は段階的フェーズ設計とバックアップ確認ゲートを組み込むことで、ユーザーへの影響を最小化しながら完遂できる。

6. 詰まりポイント7選

詰まり1: バンドル選定ミスで月額固定費が過大になる

症状

WorkSpaces を展開して2〜3ヶ月後、AWS 請求書が試算の1.5〜2倍になっていることに気づく。月々の固定費が想定を大きく上回り、部門予算を圧迫する。

原因

「念のため高スペック」という思考でバンドルを選定してしまうことが多い。全社展開時に Performance (2vCPU/8GB) または Power (4vCPU/16GB) を一律適用し、実際には Value (2vCPU/2GB) または Standard (2vCPU/4GB) で十分なユーザーに過剰スペックを割り当てている。また、AlwaysOn を全員に適用しているケースも多い。

対処

ユーザー種別ごとにバンドルを分けて運用する。事務処理・Web ブラウジング・軽量 Office 作業には Value / Standard で十分だ。エンジニア・設計担当・データ分析者に限って Performance / Power を適用する。

また、バンドルは後から変更できる (再起動が必要) ため、パイロット期間中にユーザーごとの CPU / メモリ使用率を CloudWatch で実測し、最適バンドルに引き下げる。AlwaysOn / AutoStop の切替は月単位でコンソールから変更可能だ。利用時間の実績データを取ってから課金モデルを確定させる手順を標準化することで、過剰コストを防げる。

バンドル選定の実践的な分類基準

以下の業務種別ごとのバンドル推奨をガイドラインとして使うと、初期選定のミスを防ぎやすい。

詰まり2: ディレクトリ設計の後戻りが全 WorkSpaces 削除・再作成になる

症状

WorkSpaces を展開した後、「やはり Managed AD から AD Connector に変えたい」「別の AD ドメインに接続し直したい」という要望が出てくる。コンソールで変更を試みるが、エラーが出て変更できない。

原因

WorkSpaces はディレクトリ (AD) と WorkSpaces の紐付けが作成時に固定される。既存の WorkSpaces を別ディレクトリに「移動」するオプションは存在しない。WorkSpaces の Directory を変更するには、既存 WorkSpaces を全削除して新 Directory 配下で再作成するしかない。

対処

設計フェーズで AD 構成を確定させることが唯一の予防策だ。以下の問いに事前に答えておく必要がある。

• オンプレ AD との連携は必要か (必要なら Trust か AD Connector を選ぶ)
• AD の OU 構造は WorkSpaces / AppStream の GPO 管理に適しているか
• 今後 M&A・組織再編で AD ドメインが変わる可能性はあるか

Managed AD を選ぶ場合は Enterprise エディション (Standard は WorkSpaces 非対応) を選択する。AD の設計に1週間かけても、後戻りのコスト (全 WorkSpaces 削除 + ユーザーへの通知 + 再展開) に比べれば安い。

AD 設計の確認フロー

ステップ1: 既存 AD の有無を確認
  既存 AD あり → AD Connector (プロキシ) または Trust 関係 (Managed AD ハブ化) を選択
  既存 AD なし → Managed AD Enterprise を新規構築

ステップ2: OU 設計を先に確定
  WorkSpaces 用 OU / AppStream 用 OU / 管理者用 OU の3分離を基本とする

ステップ3: 設計書を作成してから WorkSpaces を1台もデプロイしない
  設計書承認後にパイロット WorkSpaces を1台だけ試験展開する

詰まり3: AlwaysOn 課金を全ユーザーに適用してコスト超過

症状

導入初期に「シンプルにするため」と全ユーザーを AlwaysOn に設定した。利用状況を確認すると、週に2〜3回しか接続していないユーザーが全体の30%を占めており、そのユーザー群の WorkSpaces が毎月フルコストで課金されている。

原因

AlwaysOn は月額固定のため、接続頻度に関わらず同額が課金される。週2〜3回・1日3〜4時間の接続では月15〜20時間程度になり、損益分岐点 (Standard バンドルで約61時間/月) を大きく下回る。

対処

全社導入の前に、ユーザーの利用パターンを事前調査または既存 VDI / リモートデスクトップのログで分析する。接続頻度・時間帯を把握してから課金モデルを仕分けする。

推奨の仕分け基準 (Standard バンドルの場合):
  月61時間超  → AlwaysOn (フルタイム・ヘビーユーザー)
  月61時間以下 → AutoStop (パートタイム・軽度利用)
  月20時間以下 → AutoStop + バンドルダウングレードを検討

既に AlwaysOn で展開済みの場合も、コンソールから AutoStop への変更が可能だ (WorkSpaces の再起動が必要)。利用状況レポートを毎月確認し、3ヶ月連続で損益分岐点を下回るユーザーを AutoStop に切り替えるルール化を推奨する。

WorkSpaces コンソールの「移行」機能 (Migrate WorkSpaces) を使うと、別バンドルへの変更が最低限のダウンタイムで実行できる。既存ユーザーデータ (D: ドライブ) を保持したまま移行でき、ユーザーへの影響を最小化できる。バンドル変更は移行後に ReConnect (再接続) するだけで完了するため、金曜夜に実行して翌月曜の業務開始前に完了させるスケジューリングが定番だ。

詰まり4: WorkSpaces Web の IdP 設定不備で SAML 認証が通らない

症状

WorkSpaces Web のポータル URL にアクセスすると、IdP の認証画面には遷移するが、認証後に「SAML レスポンスが無効です」「ACS URL が一致しません」などのエラーが表示されてログインできない。

原因

WorkSpaces Web ポータルの SP メタデータ (Service Provider metadata) を IdP に正確に登録していないことが多い。特にトラブルが多い箇所は次の3点だ。

1. ACS URL の誤り: WorkSpaces Web が発行するポータル固有の ACS URL を IdP の「応答 URL / Assertion Consumer Service URL」に正確にコピーしていない
2. Entity ID の不一致: SP Entity ID (Issuer) が IdP 側の設定と一致していない
3. NameID フォーマットの不一致: IdP が送信する NameID フォーマット (emailAddress / unspecified) が WorkSpaces Web の期待値と異なる

対処

WorkSpaces Web コンソールの「アイデンティティプロバイダー」設定ページから SP メタデータ XML をダウンロードし、そのファイルを IdP にインポートする手順を徹底する。手動入力は誤りの温床になるためメタデータ XML ファイルの直接インポートを使う。

IdP として IAM Identity Center を使う場合は、WorkSpaces Web 専用のカスタムアプリケーションを作成し、属性マッピング (email / displayName) を正確に設定する。Okta や Microsoft Entra ID の場合も同様にメタデータをインポートする手順が用意されている。

SAML トレーサー (ブラウザ拡張機能) を使って実際の SAML レスポンスをデコードすることで、どの属性が不足しているかを迅速に特定できる。

SP-initiated vs IdP-initiated の切替

WorkSpaces Web は SP-initiated と IdP-initiated の両フローをサポートする。デフォルトは SP-initiated (ポータル URL にアクセス → IdP にリダイレクト → 認証 → ポータルに戻る) だ。IdP-initiated (IdP のアプリランチャーから WorkSpaces Web を起動する) を使う場合は IdP 側でアプリを「IdP-initiated」として設定し、RelayState パラメータにポータル URL を渡す設定が必要になる。

認証エラーは「SAML アサーションの有効期限切れ」でも発生する。IdP 側の SAML アサーション有効期限 (NotOnOrAfter) が短すぎると、ネットワーク遅延で WorkSpaces Web に届く前に期限切れになる。IdP の有効期限を5分以上に設定することで回避できる。

詰まり5: AppStream フリート容量の過不足でピーク時拒否または深夜も課金

症状 A (過少容量): 業務ピーク時間帯 (朝9-11時・昼13-15時) に AppStream セッションが開始できないエラーが頻発する。ユーザーから「繋がらない」という問い合わせが集中する。

症状 B (過剰容量): AppStream のコストが予算を超えている。確認すると深夜・週末も多数のインスタンスが Always-On フリートとして稼働しており、接続がゼロでも課金が継続している。

原因 A: 最大キャパシティが低すぎるか、Auto Scaling ポリシーの Desired Capacity の増加速度が遅すぎる。InsufficientCapacityError が発生している。

原因 B: スケジュールスケーリングを設定せず、最大キャパシティを高く固定したまま運用している。または Always-On フリートで夜間・休日のスケールダウンルールが未設定。

対処

AppStream 2.0 の Auto Scaling は「スケーリングポリシー」と「スケジュールアクション」を組み合わせて設計する。

推奨設定パターン:
  スケーリングポリシー: CapacityUtilization > 70% で +2 台
  CapacityUtilization < 30% で -1 台 (クールダウン 5分)
  スケジュールアクション:
 平日 8:30  → MinCapacity = 10 (業務開始前にウォームアップ)
 平日 19:00 → MinCapacity = 2  (夜間はスケールダウン)
 土日 00:00 → MinCapacity = 1  (週末は最小限)

On-Demand / Elastic フリートは Always-On に比べて起動時間 (1〜2分) が発生するが、未接続時の課金がゼロになるため、週末・夜間コストを大幅に削減できる。ピーク応答速度が重要な業務には Always-On + スケジュールスケーリングの組み合わせが現実的だ。

AppStream Scaling Optimizer ツールの活用

AWS が提供する AppStream Scaling Optimizer は、過去の使用状況データ (CloudWatch のメトリクス) を分析して最適なスケーリングポリシーのパラメータを推奨してくれるツールだ。導入後1〜2ヶ月の実績データを蓄積してから Scaling Optimizer を実行し、推奨値に従ってポリシーを更新する運用サイクルが効果的だ。

スケーリングのクールダウン期間は慎重に設定する。スケールアウト側のクールダウンを短く (2分) 、スケールイン側のクールダウンを長く (10分) 設定することで、急激なアクセス増に素早く対応しつつ、一時的な需要減少での過剰なスケールインを防ぐことができる。

詰まり6: WorkSpaces イメージ更新の属人化

症状

WorkSpaces のイメージ (カスタムバンドル) を更新する作業が特定の担当者だけに集中し、その担当者の休暇・退職時に手順が不明になる。セキュリティパッチの適用が遅延し、アプリケーションの更新も滞る。

原因

Image Builder (WorkSpaces のイメージ作成機能) の操作手順を文書化せず、担当者の経験値に依存している。また、イメージ更新のトリガー (パッチ Tuesday / アプリバージョンアップ) と承認フローが明確に定義されていない。

対処

イメージ更新を「定常業務」として標準化する手順を整備する。以下の4要素を文書化する。

1. 更新トリガー定義: 月次 (Windows Update 統合) / アプリバージョンアップ時 / セキュリティ通知時
2. Image Builder 操作手順書: スクリーンショット付きの手順書を共有ドキュメントに保管
3. テスト手順: 新イメージで動作確認すべき業務アプリのテストケース一覧
4. 承認フロー: テスト完了後に情報システム部門マネージャーが承認し、既存バンドルを新イメージで更新する

AppStream 2.0 の Image Builder も同様に、Image Recipe または手順書を残して担当者が変わっても再現できる運用体制を作る。自動化できる部分 (Windows Update の自動適用 + 定期スナップショット) は AWS のオートメーション機能で標準化することが効果的だ。

イメージ更新のテスト自動化

新イメージをリリースする前の動作確認テストは、チェックリスト形式で実施するのが確実だ。以下を標準テストケースとして文書化しておく。

イメージ更新後の必須確認項目:
  [ ] Windows ログイン (ドメインアカウント) で正常起動
  [ ] 業務アプリ A (名称) が起動・保存・印刷できる
  [ ] 業務アプリ B が起動・データ保存できる
  [ ] ホームドライブ (D: または FSx) が正常にマウントされる
  [ ] インターネット / 社内ネットワークへの疎通確認
  [ ] プリンタリダイレクト (必要な場合)
  [ ] USB リダイレクト (必要な場合)
  [ ] 新イメージの Windows Update 適用状況確認

このチェックリストを2名体制で確認し、署名後に本番イメージとして反映するプロセスを確立することで、属人化とリリース品質の双方を同時に解決できる。

詰まり7: 移行時のユーザープロファイル・ファイルデータ移行漏れ

症状

WorkSpaces への移行完了後、ユーザーから「デスクトップのファイルが消えた」「ブックマークがない」「メールの設定がリセットされた」という問い合わせが続出する。旧 PC はすでに返却・初期化済みで復元不可能な状況になっている。

原因

移行前のデータバックアップを「各自で実施」とアナウンスしたが、バックアップ状況を組織として確認していなかった。WorkSpaces 移行とPC返却のスケジュールが近すぎて、確認期間がなかったことも重なった。

また、WorkSpaces Personal の D: ドライブ (ユーザーボリューム) は WorkSpaces 作成後に空の状態で払い出されるため、旧 PC のデータを事前に移行していないと当然空になる。

対処

移行プロセスに「バックアップ確認ゲート」を組み込む。以下のフローを必ず実施する。

移行フロー (バックアップ確認ゲート付き):

Step 1: ユーザーへの事前通知 (移行2週間前)
  → 移行対象ユーザーにデータバックアップ方法を説明
  → OneDrive または部門ファイルサーバーへの移行を完了させる

Step 2: バックアップ確認 (移行1週間前)
  → IT 担当者が OneDrive / ファイルサーバーへのバックアップ完了を個別確認
  → 未完了ユーザーは移行スケジュールから除外し、翌週に先送り

Step 3: WorkSpaces への移行 (移行当日)
  → WorkSpaces へのログイン・動作確認を IT 担当者立会いで実施
  → D: ドライブへのデータコピーを完了させる

Step 4: 旧 PC 返却 (移行後2週間)
  → 2週間の並走期間を設け、不足データがないかユーザーに確認させる
  → 問題がないことを確認してから旧 PC を返却・初期化する

旧 PC の返却を「移行後2週間以上空ける」ルールを守ることが最も重要だ。並走期間中に差分確認が行えるため、「旧 PC から消えた」という事態を防げる。

Outlook / メールクライアント設定の移行

最も問い合わせが多いのが Outlook の設定引き継ぎだ。WorkSpaces は新規デスクトップとして払い出されるため、Outlook プロファイル (メールアカウント・署名・連絡先・予定表) は自動では移行されない。

Microsoft 365 Exchange Online を使っている環境ではメールデータ本体はクラウドにあるため消えないが、Outlook のローカルキャッシュ (.ost) や旧 PC に保存したアーカイブ (.pst) は手動で移行する必要がある。移行手順に「Outlook 初回セットアップ手順」「.pst のインポート手順」を含めておくことで、ヘルプデスクへの問い合わせを大幅に削減できる。

詰まりポイント対策の優先順位

7つの詰まりポイントのうち、回避コストが最も高いのは「詰まり2 (AD 設計の後戻り)」だ。WorkSpaces を一度展開した後の Directory 変更は全削除・再作成を意味するため、ユーザー数が多いほど被害が大きくなる。設計フェーズでこのポイントだけでも念入りに検討するだけで、導入後の致命的なやり直しを防げる。

コスト面での影響が最も大きいのは「詰まり1 (バンドル過剰選択)」と「詰まり3 (AlwaysOn 全員適用)」の組み合わせだ。この2点が重なると月額コストが正しい設計の2〜3倍になることがある。パイロット期間中の実測データをもとに修正する機会を必ず設けることが、本番展開前の最重要チェックポイントとなる。

7. アンチパターン→正解パターン変換

本番運用でよく見られる誤った設計パターン（アンチパターン）と、正しい設計パターン（正解パターン）を 7 件整理する。
EUC の導入失敗の大半は、ここに挙げるいずれかのパターンに起因している。
本番展開前のセルフチェックリストとして活用してほしい。

アンチパターン1: 全員に永続 WorkSpaces を配布しコストが膨張

アンチパターン（症状）: 社員 300 名全員に WorkSpaces Personal（永続デスクトップ）を AlwaysOn で割り当てた結果、
利用頻度が低い部門を含めて月額コストが予算の 3 倍を超えた。
外部委託者やパート社員、季節スタッフにも同一スペックの永続 WorkSpace を発行していた。

なぜ問題か: WorkSpaces Personal はユーザーごとに専用インスタンスを常時確保する課金モデルである。
利用の有無にかかわらず料金が発生するため、週数回しかアクセスしない非正規雇用者・外部パートナーに
割り当てると大幅なコスト超過を招く。サービスの選択が利用パターンに合っていないことが根本原因である。

正解パターン: ユーザーの利用形態を 4 区分に整理し、最適なサービスを割り当てる。

WorkSpaces Pools の AutoStop 課金は「接続時間 + 停止中は低額ストレージ料金のみ」のため、
週 10 時間以下の利用者には大幅なコスト削減が見込める。
利用ログを分析し、週 10 時間未満のユーザーを Pools または WorkSpaces Web / AppStream へ移行するだけで
トータル EUC コストを 30〜50% 削減した事例が多い。

アンチパターン2: 課金タイプを AlwaysOn 一択に設定し夜間・休日も課金

アンチパターン（症状）: WorkSpaces Pools の AutoStop 設定をせず、全フリートを AlwaysOn のまま運用した。
週末・深夜も稼働し続け、月額コストが AutoStop 比で約 2〜3 倍に膨らんだ。
コスト超過が発覚したのは 3 か月後で、総超過額が数百万円規模になってからだった。

なぜ問題か: AlwaysOn は接続・非接続を問わず常時インスタンスを稼働させる課金モデルである。
即起動が必須なケースには有効だが、1 日あたり 8〜10 時間しか使われない業務端末を
AlwaysOn で運用すると、稼働しない残り 14〜16 時間も同額を払い続ける。
AutoStop と比較した場合、稼働率 50% 以下の環境では 2 倍超の無駄な支出が発生する。

正解パターン: 用途に応じて AlwaysOn / AutoStop を使い分け、Auto Scaling を組み合わせる。

• AlwaysOn: VIP ユーザー・コールセンター最前線など、待機時間ゼロが必須な限定ケースのみに適用する。
• AutoStop: 大半の業務ユーザーは 1〜2 分の起動待機を許容できる。接続検知時に自動起動させ、非接続後の停止タイムアウトを設定する（例: 非接続 60 分で停止）。
• Auto Scaling Policy: Pools の利用ピーク・オフピークを分析し、スケールイン/アウトの閾値を設定する。深夜は最小フリートサイズまで縮退させることで夜間・休日の無駄な稼働を排除する。
• AppStream 2.0 Scaling Optimizer: AppStream の場合は Scaling Optimizer を活用し、過去の利用傾向から最適な Desired Capacity を自動推算する。

AlwaysOn が本当に必要なユーザーを可視化し、残りを AutoStop へ移行することが最初のコスト最適化施策になる。

アンチパターン3: ブラウザ業務のみのユーザーに重い WorkSpaces をプロビジョニング

アンチパターン（症状）: イントラネット・業務 SaaS へのアクセスのみを目的とする事務職や外部パートナーにも
WorkSpaces Personal（2 vCPU / 4 GiB RAM）を割り当て、ライセンス費を含む月額費用を全員分負担していた。
デスクトップ上でブラウザ以外のアプリを使うユーザーはほぼいなかった。

なぜ問題か: ブラウザ業務のみのユーザーにフルデスクトップは過剰である。WorkSpaces は
ディスクイメージ管理・ユーザープロファイル管理・OS パッチ適用など運用負荷が高く、
Windows ライセンス（RDS SAL）も月額で発生する。ブラウザ以外を使わないユーザーには
リソース・コスト・運用の三重の無駄が生じている。

正解パターン: WorkSpaces Web（Secure Browser）を採用する。

• ゼロインストールクライアント: エンドユーザーはブラウザだけで接続できる。クライアント端末へのデータ持ち出しをセッション単位でブロックする（クリップボード制限・ダウンロード禁止・スクリーンショット禁止）。
• SAML 2.0 統合: IAM Identity Center / Okta / Microsoft Entra ID と連携し、既存 IdP からシングルサインオン。コンテキストアクセスポリシー（デバイス・場所・時間帯）を IdP 側で統一管理する。
• コスト比較: WorkSpaces Web は WorkSpaces Personal の 1/3 以下のコストで同等のアクセス制御を実現できるケースが多い。
• 最適ユースケース: 社内 Web アプリのみ利用する事務職・外部委託パートナー向けポータル・BYOD 端末からのセキュアアクセス。

WorkSpaces Web は「デスクトップが本当に必要かどうか」を問い直す契機となるサービスである。

アンチパターン4: AppStream 2.0 を使わず、アプリ 1 本のためにデスクトップ全体を配布

アンチパターン（症状）: 特定の Windows アプリ（図面ビューア・業務専用ツール）を外部ユーザー 200 名に届けるために、
WorkSpaces Personal を全員分プロビジョニングした。
デスクトップ上に対象アプリを 1 本だけインストールした状態で運用しており、
リソースの大半は未利用のままデスクトップ機能に充てられていた。

なぜ問題か: デスクトップリソース（OS・ディスク・Windows ライセンス）を
1 アプリのために占有している。200 名分 × 月額 WorkSpaces 料金は
AppStream 2.0 Elastic Fleet の利用コストの数倍になることが多い。
AppStream は複数ユーザーがフリートインスタンスを時分割で共有できるため、
同時接続率が低い外部ユーザー向けケースほどコスト優位性が高まる。

正解パターン: AppStream 2.0 をアプリ配信層として採用する。

• Image Builder でゴールデンイメージ作成: アプリをインストール・設定したイメージを Elastic Fleet に割り当てる。フルデスクトップ OS の維持コストなしにアプリを配信できる。
• スタック設定: スタック単位でアクセス制御・ストレージコネクタ（Amazon S3 / OneDrive）・クリップボードポリシー・セッション録画を設定する。
• Elastic Fleet で従量課金: 接続ユーザーがいない間はインスタンスを保持しない。ピーク同時接続数 × 時間のみ課金となり、外部ユーザー向けの非定期配信に適している。
• WorkSpaces との使い分け基準: 「フルデスクトップが必要か？」「永続ユーザープロファイルが必要か？」いずれも No なら AppStream 2.0 が適切である。

AppStream 2.0 の GPU アプリ配信（CAD / 3D モデリング / 映像編集）の詳細は「Game & Media Vol1」に詳述されている。本節は重複を避け、EUC ポートフォリオにおける「アプリ単位配信層」としての位置づけと WorkSpaces との選択基準に焦点を絞る。

アンチパターン5: ディレクトリを未設計のまま各サービスを個別導入し認証が分断

アンチパターン（症状）: WorkSpaces と AppStream 2.0 を別々のチームが個別に導入した。
前者は Simple AD、後者は AD Connector を利用し、パスワードの変更は 2 系統で行う必要が生じた。
WorkSpaces Web にはさらに別の IdP 設定が加わり、ユーザーが「どのサービスにどのアカウントでログインするか」
を把握できなくなった。

なぜ問題か: ディレクトリが分断すると、パスワードリセット・アカウントライフサイクル管理
（採用・異動・退職）が個別運用になり管理コストが激増する。
退職者アカウントの削除漏れが複数サービスで発生するリスクが高まり、
人事異動時の権限変更も二重三重に実施しなければならない。

正解パターン: EUC 3 サービス全体の認証基盤を事前に共通設計する。

• AWS Managed Microsoft AD（フルマネージド）: WorkSpaces Personal / Pools の認証基盤として最も互換性が高い。AD Connector は中継経由のため遅延・障害リスクがあり、Managed AD の直接利用が推奨される。
• IAM Identity Center（SSO 統合）: WorkSpaces Web の SAML 2.0 IdP として IAM Identity Center を採用し、Managed AD と連携する。3 サービスのアカウントライフサイクルを IAM Identity Center の 1 か所で管理する。
• ライフサイクル自動化: AD グループ = EUC サービス割り当てとマッピングし、採用・退職イベントで自動プロビジョニング / デプロビジョニングを実装する。
• 設計タイミング: 複数サービスを導入する場合、ディレクトリ設計は「サービス個別で後付け」ではなく「共通基盤を先行設計」が必須である。後から統合するとユーザーへの影響（ログイン方式変更・データ移行）が大きくなる。

アンチパターン6: Office バンドルの更新を放置し旧バージョンを使い続ける

アンチパターン（症状）: WorkSpaces Personal のイメージに Office 2016 / 2019 を含む
Plus applications バンドルを使用したまま、バンドル更新を先送りにしている。
IT 部門は「今のところ動いているから問題ない」と判断し、移行計画が未策定の状態が続いていた。

なぜ問題か: AWS は Office 2016 / 2019 を含む Plus applications バンドルのサポートを
2025 年 10 月 14 日で終了することを発表している。この日以降、新規 WorkSpace 作成時の
バンドル選択肢から旧バージョンが削除され、新規プロビジョニングができなくなる。
既存の WorkSpace は動作し続ける可能性があるが、RDS SAL の継続保証・セキュリティ更新は
失われ、Microsoft のサポートも終了した旧 Office の脆弱性リスクが残り続ける。

正解パターン: 計画的に Office 2021 または Office 2024 バンドルへ移行する。

• Image Builder での新イメージ作成: 新しい Office バンドル（2021/2024）を使用した WorkSpaces イメージを Image Builder で作成し、既存ユーザーの WorkSpace をマイグレーションする。
• 移行スケジュール: 2025 年 10 月 14 日より前に、テスト環境・一部本番での切り替えを完了させ、全体移行に十分な余裕を持たせる。最低 6 か月前から計画を開始することを推奨する。
• RDS SAL の継続確認: 月額固定の Windows Server RDS CAL（Software Assurance 相当）が新バンドルでも継続適用されることを確認し、追加ライセンスコストを試算する。
• ユーザー通知: 移行によりデスクトップ環境が変わることをユーザーに事前告知し、移行後のサポート窓口を設けておく。

バンドル移行を放置するとサポート切れのリスクと突然の動作不具合を招く。計画的な移行こそが唯一の正解である。

アンチパターン7: SAML 設定なしで WorkSpaces Web ポータルを本番運用

アンチパターン（症状）: WorkSpaces Web（Secure Browser）をプロビジョニングし、
ネットワーク ACL と VPC セキュリティグループだけで制御した状態で、
SAML 2.0 IdP 連携を設定せずに試験運用を開始した。
その後、本番運用に移行したが SAML 設定が後回しのままになった。

なぜ問題か: SAML 統合なしでは WorkSpaces Web 独自のパスワード認証が必要になる。
MFA 強制・条件付きアクセス（デバイス・場所）・一元的なセッション無効化（退職時停止）が
機能しない。既存の IdP（Okta / Entra ID 等）のポリシーが WorkSpaces Web に適用されないため、
認証情報漏洩時に社内 Web アプリへの不正アクセスを防ぐ手段が限られる。

正解パターン: WorkSpaces Web は SAML 2.0 統合 + MFA を必須とした状態でのみ本番公開する。

• IdP 側での設定: IAM Identity Center、Okta、Microsoft Entra ID、Ping Identity などの SAML 2.0 IdP に WorkSpaces Web を SP として登録し、SP-initiated / IdP-initiated の両フローを検証する。
• アサーション暗号化: SAML アサーションの暗号化（Encrypted Assertions）を有効化し、通信経路での傍受リスクを排除する。
• コンテキストアクセスポリシー: デバイスコンプライアンス確認・IP アドレス制限・時間帯制限を IdP 側のコンテキストアクセスポリシーで適用する。
• セッション管理: IdP でセッション最大時間を設定し、長時間放置のブラウザセッションを自動失効させる。退職時は IdP でアカウントを無効化するだけで、WorkSpaces Web・WorkSpaces Personal・AppStream の全サービスへのアクセスを一括遮断できる（IAM Identity Center 連携の場合）。

SAML 統合はポータル公開前の必須チェックリスト項目として位置づけ、試験運用開始前に完了しておくべきである。

8. まとめ — End User Computing本番運用 新シリーズ起点

本記事では AWS の End User Computing（EUC）3 サービスを DaaS 視点で体系化し、
本番運用設計の全体像を整理した。
オンプレミス VDI・物理 PC 運用の限界を感じているクラウドアーキテクト・情報システム部門・
EUC 管理者が直面する「どのサービスをいつ使うか」という判断軸を、
本記事を通じて獲得できることを目標として設計した。

本記事の要点総括

WorkSpaces Core（Personal / Pools）— フルデスクトップの使い分け

WorkSpaces は AWS の永続・非永続デスクトップ基盤である。
WorkSpaces Personal は 1 ユーザー専用の永続デスクトップを提供し、
常時業務・固定アプリ・個人設定の保持が必要な事務職・開発職に適している。
WorkSpaces Pools は共有プールから非永続デスクトップを貸し出し、
多数同時接続・シフト制業務・コスト最適化を重視する場合に有効である。

課金最適化の要は AlwaysOn と AutoStop の使い分けにある。
AutoStop は接続検知で自動起動し非接続後に自動停止するため、
稼働率 50% 以下の環境では AlwaysOn 比で大幅なコスト削減が実現できる。
さらに Pools の Auto Scaling ポリシーを組み合わせ、
深夜・休日の最小フリートサイズを設定することで無駄な稼働を排除する。

ディレクトリ設計は AWS Managed Microsoft AD を基盤とし、
AD Connector の中継経由を避けて直接 Managed AD を接続することで安定性を確保する。
Office バンドルの更新（2025-10-14 デッドライン）は見逃しやすい運用タスクであり、
早期の移行計画が求められる。

WorkSpaces Web（Secure Browser）— ブラウザ特化のトラスト境界

WorkSpaces Web はフルデスクトップを持たない、ブラウザ業務専用のマネージドサービスである。
ユーザーはクライアント端末のブラウザだけで社内 Web アプリ・SaaS へアクセスでき、
クリップボード・ダウンロード・スクリーンショットの制御でデータ持ち出しをブロックする。

SAML 2.0 統合（IAM Identity Center / Okta / Microsoft Entra ID 等）は必須設定であり、
MFA・コンテキストアクセスポリシーを IdP 側で一元管理することでトラスト境界の強度を確保する。
ブラウザのみの業務ユーザーに WorkSpaces フルデスクトップを割り当てているケースは、
WorkSpaces Web への移行でコストを大幅に圧縮できる。

AppStream 2.0（WorkSpaces Applications）— アプリ単位配信のアプリ配信層

AppStream 2.0 は EUC ポートフォリオにおいて「アプリケーション単位配信層」の役割を担う。
フルデスクトップを保持せずアプリのみをストリーミング配信するため、
外部ユーザー向け・同時接続率の低い業務アプリ配信に最も費用対効果が高い。

Fleet は Always-On（即起動・常時課金）/ On-Demand（1〜2 分起動・停止時低額）/
Elastic（サーバーレス・容量管理不要）の 3 種類があり、利用パターンに応じて選択する。
GPU ヘビーな業務アプリ（CAD・3D モデリング・映像編集）の深掘りは
既公開の「Game & Media Vol1」で体系化されているため、本記事ではその重複を避け
WorkSpaces との使い分け基準に焦点を絞った。

DaaS 設計 — 3 サービスを統合する判断マトリクス

3 サービスの使い分けは次のシンプルな問いで判断できる。

1. フルデスクトップが必要か？ Yes → WorkSpaces（Personal / Pools） / No → 次の問いへ
2. ブラウザのみで業務が完結するか？ Yes → WorkSpaces Web / No → 次の問いへ
3. 特定アプリのみ配信すればよいか？ Yes → AppStream 2.0

この 3 段階の問いにより、サービス選択のミスマッチを防ぐことができる。
ディレクトリは Managed AD + IAM Identity Center の共通基盤を先行設計し、
3 サービスにまたがるアカウントライフサイクル（採用・異動・退職）を
単一ソースから管理することが、長期運用コストと管理品質の両立につながる。

コスト観点では、WorkSpaces Pools の AutoStop・AppStream 2.0 の Elastic Fleet・
WorkSpaces Web のセッション課金を組み合わせることで、
全員に WorkSpaces Personal AlwaysOn を割り当てる構成と比較して
組織全体の EUC コストを大幅に最適化できる。

監視・運用面では、CloudWatch を通じた接続数・セッション時間・起動失敗の可視化が重要である。
利用傾向の定期的なレビューにより、Auto Scaling のパラメータを最適化し続けることが
コスト効率の維持につながる。

第28軸目 End User Computing シリーズの起点として

本記事は当サイト第28軸目「End User Computing本番運用」シリーズの Vol1 として位置づけられている。
EUC（WorkSpaces / WorkSpaces Web / AppStream 2.0）を主題とした専門シリーズは
過去 27 軸では未開拓の領域であり、本記事がそのシリーズ起点となる。

AWS の EUC サービスは 2024〜2025 年にかけて大きな変化を迎えた。
AppStream 2.0 は “Amazon WorkSpaces Applications” として
WorkSpaces ファミリーへの統合が進み、サービス名・コンソール・ドキュメントが
整理されつつある。Elastic Fleet のサーバーレス配信・Scaling Optimizer の GA・
WorkSpaces Thin Client の新登場など、EUC の選択肢は急速に広がっている。

本シリーズ Vol1 では「3 サービスの使い分けと DaaS 設計の土台」を確立した。
Vol2 以降では WorkSpaces の高度設定（カスタムバンドル・Personal Compute / Graphics）・
AppStream 2.0 の Image Builder 詳細・WorkSpaces Thin Client・
BYOD 対応の高度ネットワーク設計など、より深い領域へ展開する予定である。

AWS の EUC サービスを活用するすべての読者に、本記事が「最初の一歩」となれば幸いである。

関連軸クロスリンク

本記事で扱った各テーマの詳細は、当サイトの関連軸記事で体系化されている。
以下のリンクから関連する設計知識を横断的に学ぶことができる。

AppStream 2.0 の GPU ヘビーアプリ配信（CAD・3D・映像編集 Fleet 詳細）

AppStream 2.0 を GPU ヘビーな業務アプリ（CAD / 3D モデリング / 映像編集）配信の文脈で深掘りした記事である。
本記事 §4 で参照を推奨したとおり、Fleet タイプ（Always-On / On-Demand / Elastic）の選択・
Image Builder の詳細・Active Directory 連携・ストレージコネクタの実装まで体系化されている。

IAM Identity Center を用いた WorkSpaces Web の SAML 基盤設計

WorkSpaces Web の SAML 2.0 IdP として IAM Identity Center を採用する際の設計指針・
Permission Sets の構成・ABAC（属性ベースアクセス制御）の実装を体系化した記事である。
EUC 3 サービスの認証統合基盤として IAM Identity Center を採用する場合の必読資料である。

EUC 環境のコスト試算と最適化

WorkSpaces の AutoStop 課金・AppStream の Elastic Fleet 従量課金の把握と
Cost Explorer を活用したコスト可視化・Budgets アラート設定・
Compute Optimizer による右サイジングの実践ガイドである。
EUC のコスト管理に Cost Explorer を活用する際の土台知識として参照されたい。

WorkSpaces / AppStream のネットワーク設計（Direct Connect / VPN / Transit Gateway）

WorkSpaces / AppStream 2.0 をオンプレミス AD や社内リソースと接続する際の
ネットワーク設計（Direct Connect / VPN / Transit Gateway）を体系化した記事である。
EUC 環境のハイブリッド接続設計で必要な判断軸・コスト比較・冗長化パターンを網羅している。

68記事化計画について

当サイトでは AWS の本番運用知識を体系化した 68 記事シリーズの構築を進めている。
第 1 軸（Lambda / API Gateway / Step Functions 等のサーバーレス）から始まり、
コンテナ・データベース・Analytics・ネットワーク・コスト最適化・
コンテンツ配信・Game & Media など、27 軸を超える分野で公開済みである。

第 28 軸目となる本 End User Computing本番運用シリーズは、
AWS EUC 3 サービスの使い分け・DaaS 設計・ディレクトリ統合という
これまでのシリーズで扱っていなかった新領域を開拓する。

68 記事化は「AWS の本番運用設計をどの分野から検索しても体系的に学べるサイト」という
ビジョンのもとで進んでいる。各軸が互いにクロスリンクし、読者が関連知識を
自在に横断できる知識基盤の構築を目指している。本記事でいうと §4（AppStream 2.0）から
Game & Media Vol1 へのリンク、§7（コスト課題）からコスト最適化シリーズへのリンクが
その一例である。

Vol2 予告

End User Computing本番運用 Vol2 は本記事の公開後に順次展開する予定である。

Vol2 では以下のテーマを深掘りする予定だ。

• WorkSpaces Personal の高度設定: カスタムバンドル作成・Personal Compute / Graphics ハードウェア選択・プロファイルディスク管理・Image Builder を使ったゴールデンイメージのライフサイクル管理
• AppStream 2.0 Image Builder 詳細実装: アプリインストール・最適化スクリプト・Dynamic Application Framework（DAF）・AppStream アプリブロックを使ったサーバーレス配信の詳細手順
• WorkSpaces Thin Client: 2023 年 GA の新サービス。オンプレ物理シン端末の代替として WorkSpaces / AppStream への接続を専用デバイスで実現する仕組みと用途別選択基準
• BYOD 対応の高度ネットワーク設計: Private Access（VPC 内接続）vs インターネット接続、WorkSpaces Web の IP アドレス制限・証明書ピン留め設定、Direct Connect 経由の WorkSpaces / AppStream 接続の設計パターン
• 移行設計詳細: オンプレミス VDI（Citrix / VMware Horizon）からの段階的移行手順・ユーザー受け入れ検証・パイロット設計・ロールバック計画

Vol2 は本記事公開後に順次公開する。公開後に本ナビ ep-box のリンクを更新するため、
本シリーズの更新情報はサイトを定期的に確認していただきたい。