株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

Amazon WorkSpaces検証 Part3:ユーザ向けに"Workspace"を展開する

皆様、こんにちは。

ネットワールド SEの目木です。

 

前回の記事でディレクトリの登録までが完了していますので、今回は引き続きWorkspaceの展開を進めていきたいと思います。
ですが、その前にAmazon Workspacesで展開可能なVDIとはどういったものなのか、軽く確認しておきましょう。

まず、Amazon WorkspacesのVDIはシングルセッションでの利用が前提となります。展開されたWorkspaceを複数のユーザで利用するマルチセッション型はサポートされていません。

次に展開したWorkspaceは個々にユーザアカウントが紐づけられており、それぞれで占有して利用することになります。他社のVDIソリューションでよく見かけるプール型(複数台のVDIを用意して接続時にランダムに利用VDIを割り当てる方式)での提供はできないということになります。

最後にEC2と同様、クライアントOS(Windows 10 / 11)の利用は顧客専用のハードウェアにライセンスを持ち込むBYOL形式での利用のみがサポートされています。
加えて、専用ハードウェアの利用にはリージョン単位で最低100台のWorkspaceを稼働させることが要件とされています。

以上の特徴を理解しつつ、実際の設定画面を見ていきましょう。

 

Workspaceの作成

まず、Workspacesの操作画面を開き、「Workspaceの作成」をクリックします。

最初の画面ではWorkspaceを展開する”ディレクトリを選択“します。

ここでは、前回に作成したWorkspaceを選択しています。

次に“ユーザを作成”という内容が表示されますが、この機能はマネージド側のディレクトリサービスを利用していることが前提となりますので、AD Connectorを使用している場合は利用できません。
個人的にはユーザアカウントの作成とコンピュータアカウントおよびVDIの作成は別のフローで管理されているイメージがありますので、ここは使えなくともさほど問題にはならないような気がします。(Amazon Workspaces 専用のアカウントでなければ)

"ユーザを作成"画面をスキップした後は、"ユーザの特定"ページが表示されます。
こちらで選択したユーザアカウントに対してWorkspaceが払い出されます。

説明書きにもある通り、一度に25ユーザまでが選択可能となっていますので、少なくともGUIで同時に払い出せるWorkspaceは25台が限界値となるようです。

ユーザアカウント選択後、次へをクリックすると"バンドルを選択"する画面に移ります。

バンドルとしてはAWSから提供されている標準バンドルと独自に作成したカスタムバンドルから選択することができます。以下は、標準バンドルの一覧ですが、OS、リソースモデル、クライアントプロトコル、言語、Officeアプリケーションの有無などの情報をもとに様々な種類のバンドルが並んでいます。

バンドルごとに細かく定義がされていますが、その中でも接続時のプロトコルが固定されるという点には注意が必要です。クライアント側の設定にてプロトコルを指定することはできませんので、残念ながらWSPとPCoIPの両プロトコルを1台のWorkspaceで利用することはできません。

では、どちらを選ぶべきなのかという話なのですが、管理ガイドを読んでいるとパフォーマンスの観点からAWSはWSPの利用を推奨しているように読み取れましたので、構成要件に対応不可となる項目がない場合はWSPを選択しておけばよさそうです。(分かりやすい要件だと、WSPはiOSやAndroid OSなどのモバイルデバイス系OSからの接続が非サポートとなっています)

今回は接続用の端末もWindows OSですので、より検証できる機能が多くなるようにWSP対応のWindows Server 2022 - Standardモデルとしました。

各モデルのリソースについても以下に載せておりますので、参考としてください。

ちなみにカスタムバンドルの作り方については別記事で紹介しておりますので、興味がありましたらこちらもご確認ください。

blogs.networld.co.jp

 

バンドルイメージを選択後、課金モデルとタグ付けを設定します。

課金モデルに関しては実行モードとして”AlwaysOn”="月額課金"と”AutoStop”="従量課金"から選択します。
Part1で整理した通り、従量課金であってもインフラ利用料は月額払いとなる点を意識しつつ、より低コストとなるように設計していきましょう。
なお、従量課金を選択した場合は、AutoStopの時間についても定義が必要となります。これは未使用時間(ログオフ状態)が指定した時間を超過した場合に、自動的にシャットダウンを実行してくれる機能で最短1時間から設定が可能です。
逆に言えば、この機能で電源を制御している場合でもユーザログオフから自動停止までの間には幾分のラグが生じることになりますので、運用としてはログオフ時にユーザ側からWorkspaceを停止できるようにしておくのも一案として考えられそうです。

いずれにせよ、従量課金の額を算出する際には利用時間を少し多めに見積もっておくとよさそうですね。

また、こちらの機能ですがGPOのアイドルタイムアウトと連動についても気になるところです。ユーザが放置してしまったWorkspaceはアイドルタイムアウトあるいは切断タイムアウトでログオフせてしまうことで不要なWorkspaceが起動し続ける事態を防ぐこともできる可能性がありますが。このあたりの挙動については別記事でまた取り上げたいと思います。

話を戻しまして、今回は検証目的の環境ですので、AutoStop:1時間で停止として、コストが極力小さくなるように設定しています。

 

最後に”カスタマイズ”としてストレージの構成を定義します。

Workspaceではストレージディスクが2つアタッチされた状態で払い出されます。

1つはシステム情報やアプリケーションのインストール情報が書き込まれる”ルートボリューム”で、もう1つがユーザプロファイル情報を書き込む”ユーザボリューム”となります。

ここでは、各ディスクの暗号化有無およびディスクサイズを指定します。今回は暗号化キーも作成していませんでしたので、暗号化なし、最小ボリューム(=最安ボリューム)を選択しています。

このあとは設定した内容の確認画面が出るだけですので、「作成」をクリックしてWorkspaceのデプロイを開始します。

 

以下の画面は使用可能になった状態の画面ですが、この状態になるまで10分程度かかりました。(ストレージを暗号化した場合はもう少しかかるようです)

以上にてWorkspaceの展開は完了となります。

 

今回のまとめ

ここまででAmazon Workspacesの構築の流れを確認してまいりました。
Workspaceの展開についてはおおむね以下のような感じです。

  • Workspaceはシングルセッション利用が前提であるが、その実クライアントOSによる利用には構成上の制限がある
  • Workspaceは管理先となるディレクトリを選択して展開するため、構成がディレクトリ上の設定に依存する
  • 展開されたWorkspaceではバンドル、ストレージ容量のほか利用ユーザが紐づけられている

現時点で検証環境は以下のような状況となっています。

これで、最低限Workspaceに接続可能な状態まで環境が整いましたので、次のパートでは実際にWorkspaceにログインするための手順と、Workspaceの中身について確認していきたいと思います。

本パートも最後まで読んで頂き、ありがとうございました。
Part4にてまたお会いしましょう。