カスタムに設定したイメージからWorkSpacesApplicationsを作成してみた
先月のニュースで AWS WorkSpaces Pools の廃止予定が発表されました。
WorkSpaces Poolsの代替案の一つとしてWorkSpaces Applicationsが推奨されているため、
今回はその差分を確認しながらWorkSpaces Applicationsを作成してみました。
WorkSpaces Applications とは
AppStream 2.0 から名前が変わったサービスで、WorkSpaces Poolsの後継として推奨されています。
基本的な機能はPoolsと同じで次のような部分は同じです。
- ログアウト時にインスタンスは保持されない
- 一部機能を有効化すれば、ユーザーファイルやアプリ設定を保持しておくことが可能
- AD利用可能
- Clipboardの制御が可能
違いとしては次のとおりで、設定できる機能名が違うことや、サインイン方式が異なることが大きな違いと言えます。
| 観点 | WorkSpaces Applications | WorkSpaces Pools |
|---|---|---|
| インスタンス設定 | Fleets | Directory |
| アクセス制御 | Stacks | Directory |
| カスタムイメージ作成方法 | Image Builder(Image Assistant) | 実際に使うWorkSpaceを起動させる(Create Bundle) |
| モード | Desktop, Application | Desktop |
| サインイン方式 | User Pool、SAML 2.0、Streaming URL | SAML 2.0 |
| 利用可能なLinuxOS | RHEL, Rocky Linux | なし（非対応） |
対応OSの詳細についてはそれぞれ次の資料をご覧ください。
Image Builder - Amazon WorkSpaces Applications
WorkSpaces Pools のバンドルとイメージ - Amazon WorkSpaces
細かな仕様の違いはありますが、ざっくりと、WorkSpaces ApplicationsはPoolsよりも機能が増えたものと捉えておきましょう。
作業の全体像
本記事で行う作業の全体像はこんな感じです。
大きく分けてイメージの作成とインスタンスの構築で分けています。
特にカスタマイズしたいものがない場合（常に初期設定の状態でインスタンスを立ち上げたい場合）は、カスタムイメージの作成の工程はスキップで良いです。
余談ですが、WorkSpaces ApplicationsサービスのUIは執筆時点では日本語が非対応なので、最後まで英語表記となります。
カスタムイメージを作成する
まずはベースとなるイメージをImage Builderで作成します。
Image Builderとは、名前の通りですが「WorkSpaces Applicationsで使うための、カスタマイズされたイメージを作る仮想マシン」です。
WorkSpaces Poolsでは稼働中のインスタンスからイメージを作るのが主流でしたが、Applicationsはこの手順を踏んで作る形に変更されています。
Image Builders - Amazon WorkSpaces Applications
制御できていることを確認する指標として、ローカルGPOでRegistryEditorを編集できないような制御を行ってみようと思います。
Image Builderを起動させる
カスタムイメージを作るためにImage Builderを起動させます。
ベースイメージの選択
カスタムイメージの元となるイメージを選びます。
Linuxをベースとしたいならば、RHEL などを選ぶと良いかと思います。
また、GPU有無でイメージが分かれていますが今回の検証ではGPUは不要なので、
汎用（General Purpose）のイメージを選びます。
インスタンス設定
Image Builderで使うインスタンスの設定を行います。
※この後作るApplicationsの設定は別途行います。
InstanceTypeは stream.standard.medium（Mem4GB、CPU 2GB）を選択しました。
もっと小さい small（Mem 2GB） を選択可能ですが、OSの推奨スペックとしてメモリーが4GBはあった方が良いとされているためです。
Storageは最小値、ApplicationのライセンスはOfficeは今回不要のためスキップ。
画像に入ってないですが、その他IAMロール、VPCエンドポイントがありました。
IAMロールは今回は不要、今回はインターネットからアクセスさせるため不要としました。
ネットワーク設定
特筆すべき点はありませんが、ネットワーク設定は適当に次の条件で設定しました。
- IGWがあるSubnet
- インバウンドルールが一つも定義されていないなSG
確認
今回作成するパラメータはこんな感じ。
Lanch Image Builderで作成します。
ここまで来れば、Image Builderのインスタンスが作成されるので待ちます。
Image Builderへ接続
Image BuilderのインスタンスがRunningになったら、Connectしてインスタンスに接続していきます。
Connectすると、最初にログインユーザを選べます。
いくつかありますが、今回はRegistryEditorの制御を行うため、管理者権限を持つAdminを選択しました。
各ユーザは以下のユースケースごとの違いがあるみたいです。
| ユーザー | ユースケース |
|---|---|
| Admin | アプリケーションのインストールなど、ローカル管理者権限が必要なその他のタスクを実行する場合 |
| Template User(Windowsのみ) | アプリケーションの初期設定情報など、Windowsの各種設定を行いたい場合 |
| Test User | アプリケーションを開いて設定を確認する場合 |
WorkSpaces Applications Console (Web Connection) - Amazon WorkSpaces Applications
ログインできると、見慣れた画面（Windows）が表示されます！
カスタムを入れ、ローカルGPOが効いているか確認
Registryの制御を入れる
Registry Editorの制御が可能なので、それを試します。
デフォルトの設定を確認
まず、TestUserでは開くことは可能です（デフォルト値は開ける）
設定を変更し、アクセスできないようにする
次に、Edit Group Policy（gpedit.msc）でRegistryEditorの制御を司る、次の設定を変更します。
User Configuration > Administrative Templates > System > Prevent access to registry editing tools
デフォルトはDisabledになっているため、 Enabledに変更します。
ADMX_ShellCommandPromptRegEditTools Policy CSP | Microsoft Learn
Registry制御結果の確認
Adminを一度ログアウトし、
その後TestUserでログインし直した後、改めてRegistry Editorにアクセスしてみると、エラーとなりました。
カスタムイメージを作成する
ベースとなる設定を行ったため再度ログインユーザをAdminに変更、Image AssistantからImageを作成します。
余談ですが、操作権限がAdminじゃないとこのように怒られます（１敗）
1. Add APP、2. Configure App
- 既定のアプリケーションを追加
- テンプレートユーザにおける既定のアプリケーションを確認
ができます。
今回はDesktopモードを前提として利用するため設定する必要がないのですが、仕様上最低一つ設定する必要があるため適当にnotepadを指定しておきます。
なお、notepadのフルパスはこれでした。
C:\Windows\notepad
3. TEST
AD周りのテストをすることができます。
前述の手順ですでに実施済みなのでここでは特に何もせずにNextへ進みます。
4. Optimize, 5.Configure Image
1で設定したアプリケーションの起動テストができます。
Notepadの起動テストは不要かもしれませんが、一旦やっておきます。
6. Preview
内容を確認し、Disconnect and Create Imageを実行します。
すると切断され、スナップショットの作成待機になります。
切断後〜カスタムイメージが作成されるまで
30分程度でできました。
ドキュメント上は45分以内に完了するとのことなので、若干早かったようです。
ほとんどの WorkSpace イメージは、45 分以内に利用可能になります。
また、作成完了後、Image BuilderのInstanceはStoppedになりました。
Image作成完了後に元のステータス（Running等）に戻ってコストが発生し続けることを懸念していましたが、
自動で停止してくれるなら目を離していてもコストの無駄が発生せず安心できますね。
作成されるとImage Registryタブに作成したものが追加されます。
こちらが詳細画面です。
EC2にあるAMIと似た感覚ではありましたが、AMIとは違い、この辺りをしっかり明記してくれるのが特に嬉しいと思いました。
- BaseにしたOSの表記
- 対象Applicationの明記
WorkSpaces Applicationsの作成
ここからはWorkSpaces Applicationsのインスタンスを作成していきます。
最低限構築に必要なのは、以下二つです。
- WorkSpaces Fleets
- WorkSpacesとして起動するインスタンスのスペックやイメージ、台数などを管理
- WorkSpaces Stacks
- 各ユーザのアクセスや入力周りの制御
- アプリケーション等の設定を保持する場所の設定（オプションで有効にした場合のみ）
WorkSpaces Fleetsの作成
ここまででイメージを作成しました。
Fleet Type
それぞれ次の違いがあります。
| 観点 | Always-On | On-Demand | Elastic |
|---|---|---|---|
| インスタンス管理方式 | 上限・下限(Auto Scaling)で管理 | 上限・下限(Auto Scaling)で管理 | 上限・下限管理は不要、最大同時接続数で管理 |
| 起動状態 | 常時起動 | 利用時のみ起動(未使用時はStopped) | AWSがプールを管理し、必要時に割り当て |
| 課金タイミング | 常時課金(未使用でも稼働課金) | 未使用時は低額のStopped課金、使用中は通常課金 | 利用中のみ課金 |
| 向いているケース | 即時性最優先、利用者数の変動が少ない | 通常の業務利用、多少の起動待ちが許容できる | アクセス数の予測が困難な場合 |
今回は自分以外はアクセスを行わないことから、On-Demandで作成します。
Amazon WorkSpaces アプリケーションの機能 - Amazon WorkSpaces Applications
Image
前述で作成したイメージを選択します。
今回はカスタムイメージを選択していますが、作っていない場合はベースイメージを選択すればOKです。
Fleet設定
InstanceTypeはImage Builderの時同様、WindowsServerなので推奨スペックを所有しているMediumを選択しています。
しかし、Mediumでの動作確認では若干のレスポンス遅延が見られたため、用途によってはLargeの選択も検討の余地があります。
ちょうど見切れていますがFleetCapacityでマルチセッションの設定が可能です。
今回は使用しないのでFalseにしていますが、複数ユーザかつコストを抑えたい場合はTrueにして良いと思います。
また、Stream viewはApplication or Desktopから選べますが、今回はDesktopモードを使いたいため、Desktopを選択しています。
ネットワーク設定
Image Builder同様の設定にします。
SGは分けていますが、中身はImage Builderの時と同じでインバウンドをNullとしたSGです。
確認画面
こんな感じで作成します。
作成できました。
WorkSpaces Applications Stacksの作成
Stacksの概要設定
基本はデフォルトで、Nameのみ入力
の状態で進めていきます。
保存先ディレクトリ設定
Storageを各種から選べますが、今回はS3をHomeDirectoryとして保存を選んでみます。
なお、画面に記載されているとおり、S3はこちら側で明示的に作ったりする必要はなく、内部で自動的に作成と設定が行われます。
禁止事項
次のように設定しました。
制限を強める必要はありませんが、ClipBoardとファイル転送の両方を禁止にしています。
ADはUI上、両方をFalseにするとバリデーションの都合で通らなかったため、片方Trueにしていますが、
今回は不使用です。
確認画面
内容を確認し、Stackを作成します。
FleetsをStacksに関連づける
最後の手順です。
作成したFleet（インスタンスの設定）とStack（ユーザの制限・制御）を、Stacksの画面から関連付けます。
先ほど作成したFleetを関連付けます。
これにより、Stackにアクセスすると、関連付けされているFleetで管理しているインスタンスへ転送してくれるようになります。
接続確認
Streaming URLの作成
Fleetの関連付けが終わったStackから行います。
UserIDはWindowsOS内部で作られるユーザの名前というものではないため、適当な文字列を入れています。
URL失効期限は次のように選べました。
URLが作成されました。
余談ですが、ここで作成された同一のURLを複数のユーザで使いまわした場合、内部的には同じユーザでログインすることになるため、設定が共有されます。
例えばデスクトップにあるアプリケーションの場所を変更すると、他のユーザにもその変更が動的に加わります。
そのため、マルチセッション等を用いて複数人で作業する場合はユーザごとにURLは払い出す形が望ましいと思います。
Streaming URLからアクセスする
上記で発行したURLにアクセスするとこのように出ました。
Desktopにアクセスしてみます。
ログインできました。
動作確認
あらかじめローカルGPOで制御を設定していたRegistryEditorを開いてみると、アクセス禁止が効いていることを確認できました。
最後に
個人的には、WorkSpaces Poolsに比べ、StacksとFleetsに機能が分けられており、構造がわかりやすく感じました。
DesktopのみではなくApplicationのみ共有も可能なので、自作のアプリケーションを他の人にも手軽に共有できるのが強みと思いました。
途中詰まったこと
備忘録として記しておきます。
AmazonAppStreamServiceAccessという名前のサービスロールがない
Image Builder構築時にサービスロールが存在せずエラーになった。
WorkSpaces Applications encountered an error because your service role 'arn:aws:iam::XXXXXXXXXXXXX:role/service-role/AmazonAppStreamServiceAccess' is invalid
確認してみると、AmazonAppStreamServiceAccess自体が存在せず、そこをImage Builder構築で参照しようとしてエラーになっていたようでした。
公式に載っているとおりですが、GetStartedで作られるそうなのでGetStartedを押下し、作成しました。
