Amazon WorkSpaces Poolsを試してみた

Takuya Shibata

2024.07.11

しばたです。
前の記事で紹介したAmazon WorkSpaces Poolsですが、本記事では実際に構築する手順を解説します。
https://dev.classmethod.jp/articles/amazon-workspaces-supports-workspaces-pools/
 検証環境今回構築する環境は下図となります。
私の検証用AWSアカウントの東京リージョンにVPCと各種リソースを作成します。

Microsoft Entra IDのテナントとVPC等のネットワークリソースは構築済みの状態をスタート地点とします。
 作ってみたそれでは早速作成していきます。
Amazon WorkSpaces PoolsではSAML 2.0で連携できるIdPの利用が必須であるため、まずはIdP周りの設定から始める必要があります。

こちらは手順の都合AWSとEntra IDを行き来する必要があり、かなり間違いやすいのでご注意ください。
 0. 前提条件 : Microsoft Entra ID今回IdPにMicrosoft Entra IDを使います。

検証用にFree版のテナントを一つ用意し、example.shibata.techのカスタムドメイン名を割り当てています。
 1. [AWS] Amazon WorkSpacesプールディレクトリ の仮作成最初にAWS上でAmazon WorkSpaces Pools用のプールディレクトリを作成します。
プールディレクトリの設定を完全に終わらすにはEntra ID関連の設定が事前に必要なのですが、その設定のためにはプールディレクトリのIDが必要であり、まずは最初にEntra ID関連以外の設定を行う形で仮作成します。
AWSのマネジメントコンソールから Amazon WorkSpaces → ディレクトリ → プールディレクトリ へ移動し「WorkSpacesプールディレクトリの作成」を行います。
プールディレクトリの作成画面に遷移しますが、最初は「ユーザーアクセスURL」に適当なダミー値を設定[1]し、「リレー状態パラメーター名」は未入力にします。

(Entra IDの設定後にこれらの値を更新します)
その他の設定に関しては「ディレクトリ名」や「ネットワーク」関連の設定を環境に応じて行います。

今回は以下の設定にしています。
ディレクトリ名 : example.shibata.tech
VPCとサブネット : WorkSpacpe環境を配置したいサブネットを指定
これは個人WorkSpacesと同様

セキュリティグループ : WorkSpaceにアタッチするセキュリティグループを事前作成のうえ指定
通常であれば「インバウンド通信全ブロック」「アウトバウンド通信全許可」で問題ない

今回「アクティブディレクトリ設定」は全て未設定のままとします。

(これはEntra IDとActive Directoryを同期している場合に使います)
「ストリーミングプロパティ」は環境に応じた内容にします。

今回は「ホームフォルダを有効化」以外は全てデフォルトのままにしています。
!後から気が付いたのですが、後述の作成エラーが出た時点でいくつかの設定値が無効になる様で「ホームフォルダを有効化」の設定が取り消されていました。

後述の 本登録 の時点で改めて各種設定が期待した内容になっているか確認しておくと良さそうです。
その他の設定もデフォルトのままです。

設定内容に間違いがないのを確認して「WorkSpacesプールディレクトリの作成」ボタンをクリックします。
ユーザーアクセスURLにダミー値を入れているのでエラーメッセージが表示されてしまいますが、これは意図したものなので問題ありません。
Pools ディレクトリを作成できませんでした。この問題が続く場合は、AWS Support Center にお問い合わせください。

ディレクトリ wsd-hbp37pfnq は正常に作成されましたが、値の設定中にエラーが発生しました。ディレクトリを調べて、正しくない設定をすべて編集してください。残りの手順は ModifySAMLProperties,ModifyTargetDomainAndOrganizationalUnits,ModifyStreamingProperties,ModifyIamInstanceRole,ModifyClientProperties です
現時点ではプールディレクトリが作成され、ディレクトリIDが取得できればOKです。
!このディレクトリのARNと登録コードが後で必要になります。
 2. [Entra ID] Entra IDエンタープライズアプリケーションの作成次にWorkSpaces Poolsの認証用にEntra IDのエンタープライズアプリケーションを用意します。

Entra IDのコンソールから「エンタープライズアプリケーション」を作成します。
現状ギャラリーにはWorkSpaces Pools用のアプリケーションは無い様なので「＋独自アプリケーションの作成」を選びます。
アプリケーション名は任意の名前でOKです。

今回は「AmazonWOrkSpacesPoolsApp」という名前にしています。
作成されたアプリケーションから「2. シングルサインオンの設定」を選び、
シングルサインオン方式の選択で「SAML」を選びます。
SAML設定画面に遷移するのでhttps://signin.aws.amazon.com/static/saml-metadata.xmlからダウンロードしたメタデータファイルをアップロードしてやります。
https://signin.aws.amazon.com/static/saml-metadata.xml
アップロードした結果はそのまま「保存」します。
続けてSAML証明書の「フェデレーションメタデータXML」をダウンロードします。
!このXMLファイルは次のステップで使います。
 3. [AWS] IAM IDプロバイダの作成次はAWSのマネジメントコンソールからIDプロバイダの登録を行います。

マネジメントコンソールから、IAM → アクセス管理 → IDプロバイダ を選び「プロバイダを追加」します。
プロバイダのタイプを「SAML」にし、プロバイダ名を任意の名称にします。(今回はEntraID-for-AmazonWorkSpacesPoolsにしています)

そして「メタデータドキュメント」欄に前節でダウンロードした「フェデレーションメタデータXML」をアップロードします。
この状態で「プロバイダを追加」ボタンをクリックして新しいプロバイダを作成してやります。
!このIDプロバイダは次のステップで使います。
 4. [AWS] IAMロールの作成続けてフェデレーション用IAMロールを作成します。

AWSのマネジメントコンソールからIAMロールを選択し「ロールを作成」します。
IAMロールの作成ウィザードが開始されるので、次の設定をしたうえで「次へ」進みます。
信頼されたエンティティタイプ : SAML 2.0 フェデレーション
SAML 2.0ベースのプロバイダー : 前ステップで作成したIAM IDプロバイダ (EntraID-for-AmazonWorkSpacesPools)
許可されるアクセス : 「プログラムによるアクセスのみを許可する」
属性と値 : 「SAML:sub_type = persistent」
!Amazon WorkSpaces PersonalのSAML 2.0連携では許可されるアクセスを「 どちらも選ばない(未指定) 」にする手順となっていますが、WorkSpaces Poolsの場合は「 プログラムによるアクセスのみを許可する 」を選んでください。
WorkSpaces Personal : Step 2: Create a SAML 2.0 federation IAM role
WorkSpaces Pools : Step 5: Create a SAML 2.0 federation IAM role
許可ポリシーの設定は未指定のまま「次へ」をクリックします。
ロール名を任意の名前にして一度作成します。

今回は「EntraID-for-AmazonWorkSpacesPools-Role」
一度作成した後でロールを編集しなおして、以下の様に設定を変更します。

(ウィザードで細かく設定できない部分のため一度作成してからの変更が必要)

信頼されたエンティティのJSON定義の「"Action"」に「"sts:TagSession"」を追加する

上図の様に"sts:AssumeRoleWithSAML"と"sts:TagSession"が許可されていればOKです。
信頼されたエンティティ定義
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::xxxxxxxxxxxx:saml-provider/EntraID-for-AmazonWorkSpacesPools"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:sub_type": "persistent"
                }
            }
        }
    ]
}

許可ポリシーに以下インラインポリシーを追加する

名前は任意
ポリシーのJSONは下記参照

許可ポリシー定義
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "<Amazon WorkSpacesプールディレクトリのARN>",
            "Condition": {
                "StringEquals": {"workspaces:userId": "${saml:sub}"}
            }
        }
    ]
}
これでIAMロールの設定は完了です。
 5. [Entra ID] エンタープライズアプリケーションのクレーム設定今度はEntra IDに戻ってエンタープライズアプリケーションのクレーム設定を行います。
エンタープライズアプリケーションのSAML設定から「属性とクレーム」を編集します。
既存の設定に対し下表の内容で更新とクレームの追加を行います。


作業
クレーム名
種類
値


内容の更新
一意のユーザー識別子 (名前 ID)
SAML
名前識別子の形式 → 「永続的 (persistent)に」, ソース属性 → user.userprincipalname に (※1)

追加
https://aws.amazon.com/SAML/Attributes/Role
SAML
"arn:aws:iam::<account-id>:role/<role-name>,arn:aws:iam::<account-id>:saml-provider/<provider-name>"

追加
https://aws.amazon.com/SAML/Attributes/RoleSessionName
SAML
user.userprincipalname (※2)

追加
https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email
SAML
user.mail

※1 : 環境によってはUPN以外にするケースもある模様 (詳細は下記ドキュメント参照)
※2 : スペースを含まない値であれば良く、メールアドレスでも構わない模様 (詳細は下記ドキュメント参照)
具体的な設定内容については以下のドキュメントを参照してください。
Step 7: Create assertions for the SAML authentication response
最低限
https://aws.amazon.com/SAML/Attributes/Role
https://aws.amazon.com/SAML/Attributes/RoleSessionName
https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email
の3クレーム増やす必要があり、Role属性に関しては「"<AWS IAM IDプロバイダのARN>,<AWS IAMロールのARN>"」の形式で値を埋めてやります。
Role属性の設定例
# 設定例
arn:aws:iam::xxxxxxxxxxxx:role/EntraID-for-AmazonWorkSpacesPools-Role,arn:aws:iam::xxxxxxxxxxxx:saml-provider/EntraID-for-AmazonWorkSpacesPools
 6. [Entra ID] エンタープライズアプリケーションのリレー状態設定つづけてエンタープライズアプリケーションの「リレー状態」を設定します。
エンタープライズアプリケーションのSAML設定から「基本的なSAML構成」を編集します。
編集画面下部にある「リレー状態」に以下の値を設定して保存します。
リレー状態の設定例
# 設定形式
https://<リージョン毎のリレー状態エンドポイント>/sso-idp?registrationCode=<プールディレクトリの登録コード>

# 設定例
https://workspaces.euc-sso.ap-northeast-1.aws.amazon.com/sso-idp?registrationCode=wsnrt+XXXXXX
エンドポイントの一覧は以下のドキュメントでご確認ください。
Step 8: Configure the relay state of your federation
 7. [Entra ID] エンタープライズアプリケーション利用ユーザーの登録あとはエンタープライズアプリケーションの利用ユーザーの設定を行ってください。
こちらの手順は割愛しますが、今回は織田信長ユーザーがこのアプリケーションを使う設定にしています。
これでEntra ID側の設定は完了です。
!次のステップで
Entra IDのテナントID
エンタープライズアプリケーションのアプリケーションID
が必要になるので控えておいてください。
 8. [AWS] Amazon WorkSpacesプールディレクトリ の本登録最後にダミー値にしていたWorkSpacesプールディレクトリのSAML 2.0設定の本登録を行います。
AWSのマネジメントコンソールからWorkSpacesプールディレクトリの「認証」を選び「SAML 2.0 アイデンティティプロバイダーの編集」をクリックします。
「SAML 2.0認証の有効化」にチェックを付け、次の内容を登録します。


項目名
設定値
備考


ユーザーアクセスURL
https://myapps.microsoft.com/signin/<エンタープライズアプリケーションID>?tenantId=<Entra IDテナントID>
IdP毎で設定内容は異なる

IdPディープリンクパラメータ名
RelayState (固定値)
IdP毎で設定内容は異なる

具体的な設定値については以下のドキュメントを参照してください。
Step 9: Enable integration with SAML 2.0 on your WorkSpace Pool directory
登録が完了し、ステータスが「有効」になっていればOKです。
これでディレクトリ設定は全て完了となります。
 動作確認これでやっとAmazon WorkSpaces Poolsの環境構築ができます。
AWSマネジメントコンソールのWorkSpaces欄から「プール」タブを選び「WorkSpaceの作成」をクリックします。
WorkSpace作成ウィザードが開始されるので、今回は「自分のユースケースに必要なオプションを把握している」を選び「次へ」進みます。
基本情報の入力欄ではタイプを「プール」にし、名前などは適当な値にしておきます。

今回バンドルはStandardタイプのWindows 10 (Windows Server 2022)にしています。
「設定」欄はプールされるWorkSpaceインスタンスのスケーリングに関する設定となり、おおむねAppStream 2.0フリートの設定と同じです。

今回は動作確認用なのでデフォルト値をそのまま設定しています。
!実運用においてはスケーリング設定を適切に行ってください。

おおむねAppStream 2.0フリートの場合と同じなので以下の記事の内容が参考になるはずです。
Amazon AppStream 2.0のスケーリング設定をおさらいする
次に使用ディレクトリを選ぶので先ほど作成したディレクトリを選択し「WorkSpaceプールの作成」ボタンをクリックします。
これでプールが作成されました。

初期状態では「停止」していますので、「起動」してやると実際に接続可能になります。
起動までAppStream 2.0同様10分程度[2]かかるので気長に待ちます。

最終的に状態が「起動中」になればOKです。
この状態でWorkSpaces Clientを起動しEntra IDのユーザーでログインしてやればWorkSpace環境を利用できます。
ブラウザが開きEntra IDのログイン処理が始まるので適切なユーザー情報を入力すると
WorkSpaces Clientへ戻り、
最終的にWorkSpace環境が利用できます。
OSユーザーがPhotonUserだったりするのは前の記事で紹介した通りです。
 その他補足など最後にAmazon WorkSpaces Poolsを試して気が付いた点をいくつか紹介します。
 自動作成されるS3バケットAmazon WorkSpaces Pools環境を構築するとwspool-で始まるS3バケットが自動で作成されます。
それぞれ
wspool-app-settings-<リージョン名>-<アカウントID>-ランダムID → ユーザープロファイル用VHDファイル等の置き場
wspool-home-folder<リージョン名>-<アカウントID>-ランダムID → ホームフォルダのデータ保存用
wspool-logs-<リージョン名>-<アカウントID>-ランダムID → セッションスクリプト利用時のログファイル置き場
となっています。
 設定保存とホームフォルダの扱い最初に「S3にVHDファイルを保存する」点に気が付いたせいでVHDファイル全体が永続保存されるのかと誤解していたのですが間違っていました。

VHDファイルはあくまでも「アプリケーション設定の保存用」であり、VHD内部の以下のフォルダは除外されて永続化されます。
Contacts
Desktop
Documents
Downloads
Links
Pictures
Saved Games
Searches
Videos
WorkSpaces Pools環境を試し始めた当初、デスクトップにファイルを保存したものの永続化されない事象が発生しかなりハマっていたのですがこの仕様によるものでした。
参考 : How Application Settings Persistence Works
代わりに利用者のデータは「ホームフォルダ」に保存します。

ざっくりAppStream 2.0のホームフォルダと同様と考えてもらえばOKです。
このホームフォルダは
通常利用時 : C:\Users\PhotonUser\My Files\Home Folder
実体としては C:\ProgramData\UserDataFolders\<ユーザーのSID>\My Files に存在する

Active Directory連携時 : C:\Users\%username%\My Files\Home Folder
にあり、ぱっと見では分かりにくい場所にあります。
このフォルダはS3バケットのユーザー毎のPrefixと同期されており、だいたい数分程度の間隔で同期されている様です。
アプリケーション設定のVHDとは異なりS3バケットに直接ファイルが保存される形となっています。

このためあまり激しいアクセスは想定されておらず、激しいI/Oがある場合はFSx for Windows等のファイルサーバーの利用が推奨されています。
参考 : Enable and Administer Persistent Storage for WorkSpaces Pools
ちなみにWorkSpaces Pools環境を削除してもS3バケット内のデータは残り続けます。

前述の参考資料によれば
As mentioned earlier, disabling home folders for directories does not delete any user content stored in the Amazon S3 bucket. To permanently delete user content, an administrator with adequate access must do so from the Amazon S3 console.
とのことです。
 DesiredUserSessionsスケーリング設定に関してAppStream 2.0のDesired capacityに相当する値としてDesiredUserSessionsが存在します。

ただ、この値はマネジメントコンソールのUI上は完全に隠蔽されており直接値を変更することはできない様です。
AWS CLIからはその内容が確認できるので参考にすると良いでしょう。
# AWS CLIからだと DesiredUserSessions を確認できる
$ aws workspaces describe-workspaces-pools --pool-ids wspool-xxxxxxxxx
{
    "WorkspacesPools": [
        {
            "PoolId": "wspool-xxxxxxxxx",
            "PoolArn": "arn:aws:workspaces:ap-northeast-1:xxxxxxxxxxxx:workspacespool/wspool-xxxxxxxxx",
            "CapacityStatus": {
                "AvailableUserSessions": 0,
                "DesiredUserSessions": 2,
                "ActualUserSessions": 1,
                "ActiveUserSessions": 1
            },
            "PoolName": "MyPool1",
            "Description": "My first WorkSpaces Pools",
            "State": "RUNNING",
            // ・・・後略・・・
        }
    ]
}
 セッション(=WorkSpace)の終了タイミングについてAppStream 2.0では公開アプリケーション(または公開デスクトップ)の利用が終了すると直ちにFleetインスタンスが破棄されましたが、WorkSpaces Poolsでは少し異なる様です。
WorkSpaces Clientを終了しても直ちにセッションが終了しWorkSpaceインスタンスが破棄されることは無く「NOT_CONNECTED」なステータスで残り続ける挙動をしました。

WorkSpaces Poolsの場合はCLI(およびAPI)で明示的に終了しない限り「切断タイムアウト」で指定した時刻まで(今回の場合だと15分間)セッションが残り続ける形になる様です。
# WorkSpaces Clientを終了しても ConnectionState = NOT_CONNECTED な状態でセッションは残り続ける
$ aws workspaces describe-workspaces-pool-sessions --pool-id wspool-xxxxxxxxx
{
    "Sessions": [
        {
            "AuthenticationType": "SAML",
            "ConnectionState": "NOT_CONNECTED",
            "SessionId": "c6309573-6c64-4645-918c-d4ab35c10ed2",
            "InstanceId": "i-xxxxxxxxxxxxxxxxx",
            "PoolId": "wspool-4h55tcgzv",
            "ExpirationTime": "2024-07-11T15:45:50.124000+09:00",
            "NetworkAccessConfiguration": {
                "EniPrivateIpAddress": "10.0.21.74",
                "EniId": "eni-xxxxxxxxxxxxxxxxx"
            },
            "StartTime": "2024-07-10T23:45:50.124000+09:00",
            "UserId": "xxxxxxxxxx@example.shibata.tech"
        }
    ]
}

# 15分待つとセッションが消えた
$ aws workspaces describe-workspaces-pool-sessions --pool-id wspool-xxxxxxxxx
{
    "Sessions": []
}
明示的にセッションを終了するにはaws workspaces terminate-workspaces-pool-sessionコマンドを使います。
# セッションIDを指定して終了
aws workspaces terminate-workspaces-pool-session --session-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 最後に以上となります。
SAML 2.0連携にかなりの手間がかかり疲れました...

一旦SAML 2.0連携ができてしまえば後はおおむねAppStream 2.0と同じなのでそこまで苦労することは無いと思います。
 参考ドキュメントAmazon WorkSpaces Pools環境を作りにあたり以下の公式ドキュメントが役に立つので参考にしてください。

(というかこれらを精読しないとハマりまくります...)
Configure SAML 2.0 and create a WorkSpaces Pools directory
まずはこのドキュメントを基本にしてください

Integrate SAML 2.0 with WorkSpaces Personal
従来のWorkSpaces(Personal)のSAML 2.0連携の手順も役に立ちます
ただし、WorkSpaces Poolsの手順と微妙に異なるので間違わない様に注意してください

Amazon WorkSpaces SAML Authentication Implementation Guide (pdf)
各IdP側の設定を確認するのに役立ちます


脚注
入力必須項目のため未入力にはできない ↩︎
気持ちAppStream 2.0より長くかかる様に感じられましたが厳密に計測はしてないので気がするだけかもしれません... ↩︎

Amazon WorkSpaces Poolsを試してみた

検証環境

作ってみた

0. 前提条件 : Microsoft Entra ID

1. [AWS] Amazon WorkSpacesプールディレクトリの仮作成

2. [Entra ID] Entra IDエンタープライズアプリケーションの作成

3. [AWS] IAM IDプロバイダの作成

4. [AWS] IAMロールの作成

5. [Entra ID] エンタープライズアプリケーションのクレーム設定

6. [Entra ID] エンタープライズアプリケーションのリレー状態設定

7. [Entra ID] エンタープライズアプリケーション利用ユーザーの登録

8. [AWS] Amazon WorkSpacesプールディレクトリの本登録

動作確認

その他補足など

自動作成されるS3バケット

設定保存とホームフォルダの扱い

DesiredUserSessions

セッション(=WorkSpace)の終了タイミングについて

最後に

参考ドキュメント

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社

作業	クレーム名	種類	値
内容の更新	一意のユーザー識別子 (名前 ID)	SAML	名前識別子の形式 → 「永続的 (persistent)に」, ソース属性 → user.userprincipalname に (※1)
追加	`https://aws.amazon.com/SAML/Attributes/Role`	SAML	"arn:aws:iam::<account-id>:role/<role-name>,arn:aws:iam::<account-id>:saml-provider/<provider-name>"
追加	`https://aws.amazon.com/SAML/Attributes/RoleSessionName`	SAML	user.userprincipalname (※2)
追加	`https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email`	SAML	user.mail

項目名	設定値	備考
ユーザーアクセスURL	`https://myapps.microsoft.com/signin/<エンタープライズアプリケーションID>?tenantId=<Entra IDテナントID>`	IdP毎で設定内容は異なる
IdPディープリンクパラメータ名	`RelayState` (固定値)	IdP毎で設定内容は異なる

検証環境

作ってみた

0. 前提条件 : Microsoft Entra ID

1. [AWS] Amazon WorkSpacesプールディレクトリ の仮作成

2. [Entra ID] Entra IDエンタープライズアプリケーションの作成

3. [AWS] IAM IDプロバイダの作成

4. [AWS] IAMロールの作成

5. [Entra ID] エンタープライズアプリケーションのクレーム設定

6. [Entra ID] エンタープライズアプリケーションのリレー状態設定

7. [Entra ID] エンタープライズアプリケーション利用ユーザーの登録

8. [AWS] Amazon WorkSpacesプールディレクトリ の本登録

動作確認

その他補足など

自動作成されるS3バケット

設定保存とホームフォルダの扱い

DesiredUserSessions

セッション(=WorkSpace)の終了タイミングについて

最後に

参考ドキュメント

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社

1. [AWS] Amazon WorkSpacesプールディレクトリの仮作成

8. [AWS] Amazon WorkSpacesプールディレクトリの本登録