Amazon WorkSpaces Web を試してみた #reinvent
しばたです。
re:Inventで発表されたAmazon WorkSpaces Webを実際に試してみたので本記事で解説します。
Amazon WorkSpaces Web とは
従来からWorkSpacesにはWebブラウザからのアクセスを行う「Amazon WorkSpaces Web Clinet」が存在しています。
では今回発表された WorkSpaces Web はWeb Clientの仲間なのかというとそうではありません。
WorkSpaces Web Client (従来) と WorkSpaces Web (今回) は全然違うサービスです。
それどころかWorkSpacesですらなく「お前、平田AppStream 2.0だろ！」という感じでAppStream 2.0の派生と考えるほうが適切です。
WorkSpaces Webは通常のWorkSpacesとは異なり、自分で仮想マシンイメージを作ることはせずAWSが用意したWEBブラウザ(Chrome)入りのイメージを利用します。
そして利用者のクライアント環境のWEBブラウザからイメージ内部のWEBブラウザを使いユーザー企業内イントラサイトなどのリソースへアクセスする仕組みとなります。
また、ユーザー認証にAcitive Direcotryを使わず外部のIdP(AWS SSO,Azure AD,Okta 等)でSAML認証が必須となっています。
具体的なイメージについては既に先駆者様がいる[1]ので以下の資料を参考にしてください。
利用可能リージョン
本日時点でWorkSpaces Webは以下のリージョンで利用可能です。
- バージニア北部 (
us-east-1) - オレゴン (
us-west-2) - アイルランド (
eu-west-1)
まだ東京では使えませんが来年以降順次リージョンは拡張していくそうなので期待して待ちましょう。
利用料金
前述の通りWorkSpaces Webは自分でイメージを作らない仕組みのため利用ユーザー数ベースの課金となります。
料金ページから引用すると
With Amazon WorkSpaces Web, you pay based on your monthly active users (MAUs), at a rate of $7 per month for up to 200 streaming hours. A user is counted as a MAU if, within a calendar month, the user connects to WorkSpaces Web.
If a unique user streams for more than 200 hours, you are charged $0.035 for each additional hour of streaming.
You are not charged for inactive users within that calendar month.
とのことで
- ユーザー一人あたり 7 USD/month (200時間の利用まで)
- 200時間を超える利用は 0.035 USD/hour の追加料金が発生
- 利用の無い月は課金されず
となっています。
今のところリージョンによる差異はない模様です。
前提条件
WorkSpaces Webを利用するための前提条件は大きく2点あります。
1. SAML認証のできるIdP
最初に述べたとおりWorkSpaces WebではActive Directoryは使いません。
SAML認証のできるなんらかのIdPが必要となります。
ユーザーガイドでは以下の4サービスでのセットアップ方法が紹介されているのでこれらのいずれかを選択すると良いでしょう。
2. ネットワーク要件
ネットワーク要件としては従来のWorkSpacesと同様に
- 2つのAZに分かれる2つのサブネット
が必要となります。
加えてサブネットがPrivateの場合は「S3」と「KMS」のサービスエンドポイントにアクセス可能にしておく必要があります。
こちらはインターネット経由のアクセス、VPC Endpoint経由のアクセスどちらでも構いません。
試してみた
ここまでを踏まえて実際に環境を作っていきます。
先駆者様のブログで結構詳しい手順が載っているので本記事ではあっさり目の解説にしようと思います。
0. 前提条件
私の検証アカウントの北米リージョンで環境構築を行います。
VPC環境は事前に構築済みでWorkSpaces Web環境を作るサブネットからインターネットアクセス可能としています。
1. WorkSpaces Webポータルの初期構築
今回はAWS CLIからWorkSpaces Webポータルを作成してみます。
AWS CLI Ver.2.4.4(Ver.1.22.17)以降でWorkSpaces Web関連の機能が追加されており、今回はVer.2.4.4を使っています。
# AWS CLI on PowerShell 7.2 で実施
C:\> aws --version
aws-cli/2.4.4 Python/3.8.8 Windows/10 exe/AMD64 prompt/off
C:\> $PSVersionTable | Select-Object -ExpandProperty PSVersion
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 2 0
Webポータルの作成はaws workspaces-web create-portalコマンドで行います。
今回はバージニア北部に作りますので--regionパラメーターを明示しています。
# リージョンを明示してWebポータルを作成
aws workspaces-web create-portal --display-name 'my-first-web-portal' --region 'us-east-1'
作成したポータルにネットワーク情報を紐づけるにはaws workspaces create-network-settingsおよびaws workspaces-web associate-network-settingsコマンドを使います。
# WebポータルのArn取得
$displayName = 'my-first-web-portal'
$portalArn = aws workspaces-web list-portals --query "portals[?displayName==``$displayName``].portalArn" --output text --region us-east-1
# まずは aws workspaces create-network-settings コマンドでネットワーク設定を作成
$vpcId = 'vpc-1234567890' # Set your VPC Id
$subnetId1 = 'subnet-1234567890' # Set your subnet Id1
$subnetId2 = 'subnet-1111111111' # Set your subnet Id2
$sgId1 = 'sg-1234567890' # Set WorkSpaces Web security group Id
$nwsettingsArn = aws workspaces-web create-network-settings --vpc-id $vpcId --subnet-ids "$subnetId1" "$subnetId2" --security-group-ids "$sgId1" `
--query "networkSettingsArn" --region us-east-1 --output text
Write-Output $nwsettingsArn
# aws workspaces-web associate-network-settings コマンドでネットワーク設定とWebポータルを紐づけ
aws workspaces-web associate-network-settings --network-settings-arn $nwsettingsArn --portal-arn $portalArn --region us-east-1
エラー無くコマンドが成功するとこんな感じでポータルサイトが作成されます。
ポータルを作ったものの、まだIdPとの連携をしていないためステータスが「Incomplete」となっています。
このためポータルの編集画面からメタデータファイルをダウンロードして、IdPに登録してやる必要があります。
「Download metadata file」ボタンをクリックしてServiceProviderMetadata.xmlをダウンロードします。
ちなみにCLIからはaws workspaces-web get-portal-service-provider-metadataコマンドを使います。
# aws workspaces-web get-portal-service-provider-metadata コマンドでメタデータを取得
aws workspaces-web get-portal-service-provider-metadata --portal-arn $portalArn --query 'serviceProviderSamlMetadata' --output text --region us-east-1 > .\ServiceProviderMetadata.xml
2. Azure ADとの連携
今回IdPにはAzure ADを使います。
一応私はまだMicrosoft MVPなので検証環境を用意しやすいのと、あとはAWS SSOはお気軽に準備できるものではないので...(AWS SSOは別の機会に試したいです)
Azure ADの当該テナントから新しい「エンタープライズアプリケーション」を作成します。
WorkSpaces Web用のテンプレートは無いので「独自のアプリケーション」を作成する必要があります。
今回は「My Amazon WorkSpaces Web」という名前のアプリケーションを作っています。
このアプリケーションの「シングルサインオン」でSAMLベースのサインオンを選びメタデータファイルServiceProviderMetadata.xmlをアップロードしてやります。
(ServiceProviderMetadata.xmlをアップロード)
SAML構成の確認が行われるので、「識別子(エンティティID)」と「応答URL (Assertion Consumer Service URL)」がAWS側設定のものと確かに一致しているか確認して「保存」します。
※AWS側設定はWebポータルから「SP Entity ID」および「SP ACS URL」で確認できます
これでAzure AD側設定が終わりましたので、今度は「フェデレーションメタデータXML」をダウンロードしてAWSにアップロードしてやります。
<エンタープライズアプリケーション名>.xmlという名前でダウンロードできるはずです。
3. WorkSpaes Webポータル各種設定
AWS側、WorkSpaces Webのポータル編集画面から「Identity provider (IdP) details」欄を表示しフェデレーションメタデータXMLをアップロードしてやります。
↓
アップロード後設定を保存するとWebポータルのエンドポイントが生成され、ポータルのステータスが「Active」になります。
これで最低限WorkSpaces Webが利用可能になります。
その他Webポータルから設定可能な項目としては、Chromeのポリシー設定(スタートアップURLやブックマーク設定など)やクリップボードの使用可否、ファイルアップロード・ダウンロード設定があります。
これらの設定は要件に応じて設定してください。
4. 接続確認
これで準備ができましたので、エンドポイントに実際に接続してみます。
クライアント環境のブラウザからエンドポイントURLにアクセスすると以下の様なサインイン画面になります。
サインインの方法を選ぶボタンが「AmazonSSO」と若干おかしいですが気にせずクリックします。
今度はちゃんとAzure ADのサインイン処理になりますのでエンタープライズアプリケーションに登録したユーザー情報でサインインします。
無事サインインできたあとしばらく待つと下図の様にAppStream 2.0風の画面の内部にWEBブラウザ(Chrome)が表示されます。
この画面内ブラウザはVPC内部のサブネットに存在する形になるので企業内イントラネットにあるサイト等に接続してVDIとしての役割を果たす形になります。
ちょっと気を付けるとわかりますがブラウザのタイトルに思いっきり「AppStream 2.0」とあります...
やっぱりAppStream 2.0じゃないか、お前！
補足1 : WorkSpaces WebはどこまでAppStream 2.0なのか
WorkSpaces Webのイメージ内部を調べると、どうやら実体としては先日リリースされたAppStream 2.0 Elastic Fleetsを使っている様です。
Amazon Linux 2ベースイメージにGoogle Chrome (本日時点ではVer.96.0.4664.45) を公開する形で実現されています。
加えてAppStream 2.0では従来からSAML 2.0を使った認証がサポートされており、WorkSpaces Webもこの仕組みをより簡素にまとめ上げたものと思われます。
- 参考
このため内部的にはほぼAppStream 2.0なんだと予想されます。
利用者目線でみればIdPとの連携が若干手間ですがそれ以外はかなり手軽にセットアップでき、よりマネージドな形でAWSにお任せできる点がWorkSpaces Webの存在価値になるでしょう。
補足2 : 制限事項
Amazon Linux 2ベースイメージを使っているため、現時点では
- 日本語フォントが無く日本語の表示が文字化けする
- 日本語の入力メソッドが未実装 + AppStream 2.0のRegional Settingsも非サポート
となっています。
(日本語フォントがイメージ内部に無いため□の嵐に...)
残念ながら現時点では日本人が実用することは無理だと思います。
こちらは将来の改善に期待したいところです。
最後に
以上となります。
AppStream 2.0な部分を全然隠す気が無くまだまだ荒削りであるもののサービスとしてはとても面白いと感じました。
これからより洗練されて東京リージョンで使える日が来るのが楽しみです。
正直くやしい...でも良くまとまっており非常に参考になります ↩︎
