OneLoginを使ってAWS WorkSpaces Poolsを構築する手順メモ

はじめに

こんにちは、elephantnodeです。
普段は都内で社内情シス兼Webエンジニアとして働いています。

先日、OneLoginをIdP（Identity Provider）として利用するAWS WorkSpaces Pools環境を構築する機会がありました。今回は、その構築手順と注意点を備忘録としてまとめます。

勤め先ではAWS WorkSpacesを使い、アクセス制限付きの社内アプリを提供していました。コロナ禍では在宅勤務者が多く利用も活発でしたが、その後は利用頻度が減少し、長時間利用するケースも少なくなりました。

そんな中、2025年のAWS Summit JapanでAWS WorkSpaces Poolsを見かけ、コスト見直しを目的に構築を試してみたので、その手順と気づきを共有します。

AWS Workspaces Poolsの特徴

2024年7月にリリースされたAWS WorkSpaces Poolsは、1つのWorkSpaceイメージからユーザーごとにセッション単位で使い捨て環境を起動できるサービスです。

従来の「ユーザーごとにWorkSpacesを割り当てる方式」と比べ、利用時間や運用コストを抑えられる点が大きな特徴です。

主な特徴は以下の通りです。

• 非永続環境

セッション終了時に環境がリセットされます。アプリの追加インストールやローカル保存はできません（※一部S3保存機能あり。後述）。

• Dockerのイメージとコンテナの関係に近い利用感
• AD不要

従来のWorkSpaces（現Personal）ではActive Directoryが必須でしたが、PoolsはSAML 2.0対応IdPのみで利用可能。

構築に使用したIdP

IdPとしては、Azure AD・Okta・Auth0なども利用できますが、勤め先ではOneLoginを使用しています。今回はOneLoginを利用してPools構築を進めていきます。

参考記事

構築時に参考にした記事はこちらです。

ステップ概要

本記事では以下の流れで解説します。

1. OneLoginでアプリ追加
2. AWSでPools用ディレクトリ作成
3. IAMでIDプロバイダ作成
4. IAMロール作成
5. OneLoginでRole・RelayState設定
6. OneLoginでユーザー割当
7. AWS WorkSpaces Pools作成
8. 動作検証
9. S3保存の挙動確認

1. OneLoginでアプリを追加

まず、OneLoginに管理ユーザーでログインし、連携用アプリを追加します。

1. [Add App] をクリック

2. workspaces で検索し、SAML 2.0 コネクタを選択

3. 必要項目を設定し「Save」で追加

4. 追加されたアプリケーションをクリック。

追加後、SSOタブを開き、以下を取得します。

• SAML 2.0 Endpoint (HTTP) → 後ほどAWSに設定
• SAML Metadata → XMLをダウンロード

2. AWSでPools用ディレクトリ作成

AWSマネジメントコンソール → WorkSpaces → ディレクトリ → [ディレクトリの作成]

いくつか設定項目が別れているので、それぞれに解説します。

WorkSpaceタイプ：プール

• ユーザーIDソース：OneLoginで取得した SAML 2.0 Endpoint (HTTP) を入力
• リレー状態パラメータ名：RelayState

ポイント
• ディレクトリ名は一意にする（例：corp.example.com）

VPC/サブネットは本番用に専用作成推奨（参考記事）

セキュリティグループは作成から進めれば、デフォルトの設定で、インバウンドルールは無効、アウトバウンドルールはIPv4をすべて許可で作成できるので、そのような設定であれば使用できますが、制限をかけたい場合はここで設定すると良さそうです。

オプションとしてActive Directory（AD）の使用設定があります。今回は利用しないので、そのままにしておきますが、一度作成してしまうと、ADは再設定できないようなので、利用する場合は注意しましょう。

ホームフォルダを有効化するとS3にユーザーデータ保存可能（後述のアプリケーションパーシステンスにも影響）

IAMロールは、WorkSpace内部からAWS APIなどを利用する場合にIAMロールを設定できます。あとから追加も可能ですが、今回は使わないので、ブランクで。

設定が終わったら[ディレクトリの作成]で作成します。

作成したディレクトリの詳細を開きます。

作成したディレクトリのディレクトリIDと登録コードを控えておきます。

3. IAMでIDプロバイダ作成

AWSコンソール → IAM → IDプロバイダ → [プロバイダを追加]

プロバイダのタイプはSAMLを選び、プロバイダ名を入力。メタデータドキュメントは先程OneLoginの管理画面でダウンロードしたxmlファイルをアップロードします。

設定が完了したら[プロバイダを追加]で作成します。

作成後、ARNを控えます。

4. IAMロール作成

次に、OneLogin側からAWSのIDプロバイダを使用するためのIAMロールを作成します。これは後ほどOneLoginのアプリ側の設定で必要になります。

1. AWSコンソール → IAMロール → [ロールを作成]

ウィザードが開始されるので、順を追っていきます。

信頼されたエンティティタイプ：SAML 2.0 フェデレーション

プロバイダ：先ほど作成したIDプロバイダ
アクセス許可：プログラムアクセスのみ許可
属性：SAML:sub_type
値：　persistent

許可を追加の画面に進みますが、後ほど設定するので、そのまま次へ進めます。

ロールの詳細でロール名を設定し、[ロールの作成]でひとまず作成します。

作成したロールを検索して、詳細の設定をしていきます。

信頼関係>信頼ポリシーを編集に進みます。

編集画面でjsonを編集し、Actionに"sts:TagSession"を追加して、ポリシーを更新します。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Federated": "arn:aws:iam::<アカウントID>:saml-provider/<プロバイダ名>"
			},
-			"Action": "sts:AssumeRoleWithSAML",
+			"Action": [
+				"sts:AssumeRoleWithSAML",
+				"sts:TagSession"
+			],
			"Condition": {
				"StringEquals": {
					"SAML:sub_type": "persistent"
				}
			}
		}
	]
}

続いて、許可タブで先ほど設定しなかったロールの許可ポリシーを追加します。

右上の許可を追加のプルダウンからインラインポリシーを作成に進みます。

ポリシーエディタでJSONを選択して、許可するポリシーをエディタから下記のように設定します。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "workspaces:Stream",
			"Resource": "arn:aws:workspaces:ap-northeast-1:<アカウントID>:directory/<ディレクトリID>",
			"Condition": {
				"StringEquals": {
					"workspaces:userId": "${saml:sub}"
				}
			}
		}
	]
}

Resourceにはarn:aws-us-gov:workspaces: <region-code> : <account-id> :directory/ <directory-id>となるように設定します。

<region-code>にはWorkSpace Pool ディレクトリを作成したAWS リージョンのコード、<account-id>はAWS アカウント ID、<directory-id>は先程作成したディレクトリのIDです。

ポリシー名を設定したら作成してください。

最後にIAMロールのARNを控えておきます。この次の手順で、先ほどのIDプロバイダのARNと合わせて使用します。

5. OneLoginでRole・RelayState設定

再度、Oneloginの管理画面に戻り、連携アプリの設定をします。

Amazon Workspacesアプリの設定でParameters>Roleを選択します。

AWS側のロール設定を入力するポップアップウィンドウが表示されるので、ValueにAWSコンソールで追加したIAM IDプロバイダとIAMロールそれぞれのARNを下記の形式で設定します。

<AWS IAMロールのARN>,<AWS IAM IDプロバイダのARN>

例：arn:aws:iam::<account-id>:role/<role-name>,arn:aws:iam::<account-id>:saml-provider/<provider-name>

注）oneloginは前後にダブルクォーテーションなどを入れない

Roleの下にある、Role Session Nameをクリックします。

Valueにuser.userprincipalnameを入力し、SAVEします。

念の為、右上の「SAVE」で保存します。

次にConfigrationでRelayStateの値を設定します。

RelayStateは、OneLogin側でログインが成功した場合に移動するリダイレクト先の設定に相当します。

RelayStateの値は下記の内容で作成します。

https://<リージョンエンドポイント>/sso-idp?registrationCode=<登録コード>

<relay-state-region-endpoint>はAWSの下記ドキュメントでリージョンごとの値を参照して設定します。

例（東京リージョン）：

https://workspaces.euc-sso.ap-northeast-1.aws.amazon.com/sso-idp?registrationCode=wsnrt+*****

6. OneLoginでユーザー割当

Rolesを作成し、アプリのAccess設定から対象ユーザーを紐付けます。

これでディレクトリとIdPの準備が整ったので、Poolsの構築に進みます。

7. AWS WorkSpaces Pools作成

AWSコンソール → WorkSpaces → プール → [WorkSpacesの作成]

ワークスペースをユースケースからオプションを選定してくれるウィザードが用意されていますが、今回は使用しない方法で進めます。

WorkSpaceの設定

WorkSpaceの設定を進めていきます。

• タイプ：プール
• WorkSpaceの名前と説明を入力

• バンドル：標準提供のWindows10（今回はValueバンドル）

実運用ではおそらく追加のアプリケーションなどがあると思いますので、独自のカスタムバンドルを利用することになると思いますが、この記事ではWorkSpacesの標準バンドルを使用します。

最長セッション時間やアイドル切断タイムアウトは説明が書いてあるままですが、切断タイムアウトはすこし注意が必要です。

WorkSpaces Pools環境ではセッションの中断と終了が存在します。

非永続的環境なので、セッションを終了すると、WorkSpace内の更新は破棄されるのですが、中断の状態であれば、この切断タイムアウトの設定分だけ、WorkSpaceの更新内容を中断中も維持してくれます。

アプリケーションパーシステンスは、ディレクトリの設定でもありましたが、一部のアプリケーションの設定やWindowsの設定などをs3フォルダに記録し、次のセッションでもその設定を使うようにできます。

費用節約のための自動停止を設定できるのでONにします。
なお、自動停止をONにすると、ユーザーのセッションごとに1~2分ほど起動時間が発生するようになります。またユーザーセッションが発生したときにのみ課金が発生しますが、ストリーミングをしていない確保分のインスタンス（次の項目で設定）ごとに小額の料金が時間単位で発生します。

容量とスケーリングの項目では、実際に使用するユーザーの人数に関する設定です。最小容量は普段同時に使う予定のある人数を、最大容量は最小容量に+5~10程度を設定すると良いようです。

スケールはさらにスケジュールやマニュアルでの設定も追加できます。ここもうまく使うことで、必要なインスタンスの量を細かく調整できそうです。

今回はデフォルトで進めますので、特に設定していません。

最後にプールを作成するディレクトリを選択します。

プールの設定が終わって、プールのWorkSpaceの作成が始まります。しばらくすると、停止済みの状態になるので、起動します。初回の起動には時間（20分程度？）がかかるので、しばらく待ちましょう。

実行中になったので、接続を試してみます。

8. 動作検証

今回はOneLoginのユーザーアプリから接続してみます。

登録したアプリをクリック。

ブラウザで別タブが開き、WorkSpacesのセッション開始をアプリもしくはブラウザで開くか選択画面がでます。まずはアプリで試してみます。

アプリが開き、WorkSpacesへのサインインを続行のボタンが表示されるのでクリックします。

再度アプリへの接続がブラウザで表示されるので、開くをクリックします。

WorkSpaceの初期化画面に移り、起動までの所要時間が表示されるので、開始まで待ちます。

WorkSpaceの画面が表示されました。

しばらく放置していたので、アイドル時間が過ぎて、セッションが切断されました。

いったんセッションを中断し、再度ブラウザからの接続をテスト。

ブラウザからのセッションも問題なさそうです。

9. S3保存の挙動確認

ホームフォルダ

ホームフォルダはWorkSpace内のD:\PhotonUser\My Filesに設定されます。

このフォルダに保存したファイルは、s3にwspool-home-folder<リージョン名>-<アカウントID>-ランダムIDで作成されるバケット内部の/user/federated/以下に、ユーザーごとNameIDからハッシュ値生成された、小文字の SHA-256 ハッシュ 16 進文字列を使用して作成されるディレクトリへ保存されます。

特別、SMBなどを構築しなくても手軽にファイルを保存できるので、次回のセッション時にもファイルを利用したい場合などに便利です。
ただし、ローカルマシンではユーザーごとにS3へのアクセス方法を確保しなければならないので、ファイル転送には工夫が必要です。また保存に時間がかかる場合もあるので、頻繁にアクセスや更新が必要なファイルの運用には向いていません。

このホームフォルダはユーザーとWorkSpaceのOSが全く同一であれば、異なるディレクトリに構築されたWorkSpaceでも同じS3のバケットに接続されました。

WorkSpaceの設定項目「アプリケーションパーシステンス」はWorkSpace内のアプリの設定を、セッションの終了時にs3内のバケットに保存してくれる機能です。

ただし、アプリの設定と言ってもブックマークや、エクスプローラーの設定などがメインで、ブラウザやアプリのログイン情報などはセッション終了後にインスタンスとともに削除されますので、過度に期待しないほうが良さそうです。
ユーザーで共有したいファイルや設定などはあらかじめ、別のWorkSpaces Privateを構築して、必要なアプリやブックマークの設定を施したイメージを作成＞バンドルを作成し、最初から設定済みのWorkSpaces Poolsを作成する必要があります。

Poolsのセッションについて

またセッションには中断と終了があります。

Disconnectはセッションを切断するのみで、セッション自体は切断タイムアウトの時間内であれば、再度おなじセッションに接続し、前回の作業を継続できます。

セッションの終了を選んだ場合は、すべての変更が失われる警告が表示されます。

セッション終了後はインスタンスの破棄と、設定のS3への保存などが行われるため、すぐには新しいセッションを始めることができません。しばらく経って裏の作業が終わったら新規セッションを始められるようになります。

10名規模での費用比較（Personal vs Pools）

AIによる比較ですが、費用面に関して。

料金モデルの違い（概要）

• WorkSpaces Personal（永続型）

  • 毎月定額のAlwaysOn（月額固定）方式：常時利用者向け
  • AutoStop（時間課金）方式：接続時のみ課金、断続利用者向け
  • Windowsバンドルには RDS SAL（$4.19／ユーザー・月）が含まれる（BYOLで不要)

• WorkSpaces Pools（非永続型）

  • AlwaysOn（プールが稼働中は課金）
  • AutoStop（User 接続時のみ課金 + 未接続は停止中料金）：短時間／断続利用に強い

• Windows ライセンス費用（RDS SAL）

  • Windows 非 BYOL の場合、Poolsでも $4.19／人・月 の追加費用がかかる

---

利用パターン別：ざっくり判断マトリクス（10名想定）

利用パターン	推奨方式	理由
毎日ほぼ常時使用（7〜8h／日 × 20日）	Personal（AlwaysOn）	月額固定で安定利用に最適
断続的／短時間利用（週数回、1–2h／日）	Pools（AutoStop）	接続時のみ課金、停止時のコスト抑制
中程度利用（60–80h／月）	時間課金Personal vs AutoStop Pools	同時接続数や停止コスト次第で Pools が有利に
長時間常時利用（140–160h／月）	Personal（AlwaysOn）	使用時間が多いため、固定費の方が安くなる傾向
BYOL適用可	Personal／Poolsともに有利	RDS SAL 分（$4.19／人・月）が不要になるため

---

料金計算の基本式（10名ベース）

N = 10
H = （1名あたりの月間利用時間）
B = Personal（時間課金）のベース料金（$/月／人）
P = Personal（時間課金）の時間単価（$/h／人）
M = Personal（月額固定）の料金（$/月／人）
S = Pools（AutoStop）の時間単価（$/h／人）
Q = Pools停止中インスタンスの時間単価（$/h／インスタンス）
R = RDS SAL（月額 $4.19／人；BYOL時は 0）
C = Poolsの最小確保インスタンス数（同時接続想定）

• Personal（時間課金）合計
  Cost_personal_hourly = N × (B + P × H + R)

• Personal（月額固定）合計
  Cost_personal_monthly = N × (M + R)

• Pools（AutoStop）合計
  Cost_pools = (N × S × H) + (C × Q × 720) + (N × R)

• 利用シーン別：傾向まとめ

• 短時間・少人数の利用 → Pools（AutoStop） のコスパが圧倒的
• 中程度（60–80h／月） → 同時接続数を抑えれば Pools が有利になる可能性あり
• 重めの利用（140–160h／月） → Personal（月額固定） がコスト的に安定
• BYOL可の場合 → どちらでも RDS SAL 分（$4.19）が省けてさらに割安

---

• **実利用の「1ユーザーあたりの月間接続時間」と「同時接続数」**を可視化してから、上記式に単価を当てはめて計算すると判断がしやすいです。
• AWS Pricing Calculator を使えば、具体的なバンドル／リージョンでの見積もりが簡単にできます。
• 実際の料金はリージョンやバンドルタイプ（Value, Standard, Performance など）によって変わるため、移行時は必ず最新情報を確認してください。

まとめ

まとめになります。

• AWS WorkSpaces Poolsは非永続環境でコスト削減に有効
• OneLogin連携はSAML 2.0設定でAD不要
• ホームフォルダ＋アプリケーションパーシステンスにより最低限の永続化が可能
• カスタムバンドルを使用すれば、より柔軟な運用が可能
• VPCや容量設定は運用前に十分検討を

従来のWorkSpacesと比較すると、ブラウザの挙動とファイルの保存などが大きく変わり、おなじ運用方法はできないため、ユーザーによっては完全移行できない場合もありそうでした。

とはいえ、不特定多数のユーザーが使うことを考えれば、運用コストと整備コストだけでなく、IdPでユーザーを管理することで、単なるパスワード管理になりがちだったID管理もセキュリティが向上します。

ヘビーユーザーは従来のWorkSpaces Personalを維持しつつ、ライトユーザーはPoolsへ移行させることでしばらくは運用をやってみたいと思いました。

ファイルフローについては、結局S3のローカル＋WEBアプリを作って解決することにしましたので、また別の記事で紹介したいと思います。

以上、OneLoginを使ってAWS WorkSpaces Poolsを構築する手順メモでした。
ここまでお読みいただきありがとうございました。