Amazon WorkSpaces

解決する課題

社員一人ひとりに物理PCを配り、OSやアプリのパッチ適用、故障対応、退職時のデータ消去まで運用するのは大きな負担です。テレワークやBYOD（私物端末の業務利用）が広がると、端末に業務データが残ること自体がリスクになります。Amazon WorkSpaces なら：

• デスクトップ環境をクラウド上に置き、手元の端末は「画面を映す窓」にできる
• OSパッチ・基盤の冗長化・バックアップをAWSに任せられる
• 業務データはクラウド側に集約され、端末紛失時の情報漏えいリスクを抑えられる
• 入退社や繁忙期に合わせ、デスクトップを数で増減できる

主要概念と用語

• WorkSpace: 1ユーザーに割り当てる1台の仮想デスクトップ。WindowsまたはLinuxのOSを選べる
• バンドル: OS・vCPU・メモリ・ストレージ・付属アプリを束ねた「スペックのテンプレート」。標準のものから選ぶか、独自イメージで作成する
• イメージとカスタムバンドル: 作り込んだWorkSpaceを元にイメージ化し、同じ構成を量産できる
• ディレクトリ: ユーザー認証の基盤。AWS Directory Service のマネージド型ディレクトリや、オンプレのActive Directoryと連携して使う
• 実行モード: 常時起動のAlwaysOn（月額）と、接続時のみ課金されるAutoStop（月額基本料＋時間課金）の2方式
• WorkSpaces クライアント: Windows/macOS/Linux/タブレット/Webブラウザなどから接続するためのアプリ
• ルートボリュームとユーザーボリューム: OS用と、ユーザーデータ（多くは D ドライブ相当）用に分かれたストレージ

仕様・制限・クォータ

• WorkSpace はリージョン内のアベイラビリティゾーンに配置され、ユーザーのディレクトリに紐づく
• バンドルは用途別にValue／Standard／Performance／Power／Graphics系などのグレードが用意され、必要に応じてスペックを上げられる
• 1アカウント・1リージョンあたりに作成できるWorkSpace数には上限（クォータ）があり、引き上げ申請が可能
• ストレージ容量は一定範囲で拡張でき、原則として縮小はできない点に注意する
• 利用にはユーザー認証の土台となるディレクトリが必須

内部の仕組み

各WorkSpaceは、AWSが管理する基盤上で動く専用の仮想デスクトップです。ユーザーはクライアントアプリから接続し、画面転送のストリーミングプロトコルを通じて操作します。実際の処理はクラウド側で行われ、端末には基本的に画面と入力だけがやり取りされます。

• 認証はディレクトリ（マネージドディレクトリ、またはオンプレADとの連携）で行う
• ストレージはルートボリューム（OS）とユーザーボリューム（データ）に分離され、定期的にスナップショットが取得される
• AutoStopでは一定時間の無操作で自動停止し、再接続時に再開する。これにより使っていない時間の費用を抑えられる

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

• 既存ADと連携: オンプレのActive Directoryと連携し、社員が普段使うアカウントでサインオンできるようにする
• バンドルの標準化: 部門・職種ごとに用途に合うバンドルを定義し、カスタムイメージから量産する
• オンプレ接続: VPNやDirect Connect経由で社内システムやファイルサーバーへ安全に到達させる
• ストレージは余裕を持つ: 後から縮小できないため、初期サイズは過大にしすぎず、拡張前提で計画する
• 多要素認証（MFA）: ディレクトリ側でMFAを有効化し、なりすましログインを防ぐ

運用・監視

• CloudWatch でWorkSpaceの接続状況や稼働メトリクスを監視できる
• CloudTrail で作成・削除・再起動などのAPI操作を記録し、監査に使う
• 不調なWorkSpaceは再起動・再構築（リビルド）・復元で対処する。リビルドはユーザーボリュームを保ったままOSを作り直せる
• パッチ適用は基本的にAWSが管理するが、アプリ層の更新は組織のポリシーに沿って運用する
• 退職者のWorkSpaceは速やかに削除し、ライセンスとデータを整理する

コスト

実行モードによって課金体系が変わります。常時利用なら月額固定が読みやすく、断続利用なら時間課金が有利になりやすいです。

• バンドルのグレードを上げるほど単価は上がるため、用途に合うスペックを選ぶ
• 使っていないWorkSpaceは削除する。AutoStopでも基本料は発生する点に注意
• BYOL（自社Windowsライセンスの持ち込み）が要件を満たす場合、ライセンス費を抑えられることがある

セキュリティ

• 業務データは原則クラウド側に保持され、端末に残らないため紛失・盗難時の漏えいを抑えられる
• ルートボリューム・ユーザーボリュームは保存時暗号化に対応し、鍵はKMSで管理する
• 通信はストリーミングプロトコル上で暗号化される
• ディレクトリでMFAを有効化し、IPアドレス制限などのアクセス制御と組み合わせる
• クライアント端末へのファイル持ち出しや印刷などは、ポリシーで制限を検討する

Well-Architected の観点

• セキュリティ: データを端末に残さずクラウドに集約、保存時暗号化とMFA、最小権限の徹底
• 運用上の優秀性: OSパッチや基盤運用をAWSに任せ、カスタムバンドルで構成を標準化・再現可能にする
• 信頼性: マネージド基盤による冗長化と、リビルド・復元による迅速な復旧
• コスト最適化: 実行モードとバンドルグレードの使い分け、不要なWorkSpaceの棚卸し

試験で問われるポイント

関連サービス・比較

ストリーミングでアプリやデスクトップを提供する Amazon AppStream 2.0 とよく比較されます。WorkSpaces は「ユーザー専用の常設デスクトップ」、AppStream は「必要時に配信するアプリ／セッション」が基本イメージです。

ハンズオン / CLI例

# 利用可能なバンドル（スペックのテンプレート）を一覧表示
aws workspaces describe-workspace-bundles \
  --owner AMAZON \
  --query "Bundles[].{Name:Name,BundleId:BundleId}"

# 指定ディレクトリ・バンドルでユーザーにWorkSpaceを払い出す
aws workspaces create-workspaces \
  --workspaces \
  "DirectoryId=d-0123456789,UserName=taro,BundleId=wsb-0123456789,WorkspaceProperties={RunningMode=AUTO_STOP}"

# 既存WorkSpaceの状態を確認
aws workspaces describe-workspaces \
  --query "Workspaces[].{Id:WorkspaceId,User:UserName,State:State}"