Amazon WorkSpaces の制限

VPCにクローズドな開発環境を構築しようとした場合、メンバーの開発端末をどこに用意するかが問題となる。
Direct ConnectなどでVPNを張ってしまえば社内の開発端末がそのまま使えるが、アウトソーシングしている場合は各拠点から接続が必要になったりで結構大変。そこでVPC内にVDIを立てることを検討した。

さてAWSのVDIソリューションを調べたところ、Citrix Xen DesktopとAWS WorkSpacesがあるらしい。
AWS初心者向けWebinar AWSクラウドにおけるVDIソリューション

前者はEC2上にXen Desktopを構築してしまおうということで、後者はAWSのマネージドサービスとのこと。

Xen Desktopは使ったこともあるしVDI製品としてはよく使われている製品なので安心できる。

ただEC2上にイチから構築することを思うと、小規模、短期のプロジェクトにはリッチすぎるので、今回はWorkSpacesの利用を検討してみた。

要件

1. 開発拠点からのみアクセスできるように制限したい
2. クローズドな開発環境のため、データの持ち出しはNG
3. 24H365D利用可能なこと
4. Windows 7、Eclipse、Officeな既存環境の開発ソフトが利用可能なこと

アクセス元制限

~~これはできなかった。~~

WorkSpacesへの接続は、AWSが用意するアクセスポイントへ接続してからVPC内のWorkSpaceインスタンスへ振り向けられる様子。ソースIPは利用者のグローバルアドレスではなくAWS内部のアドレスになるため、WorkSpaceのインスタンスのセキュリティグループやネットワークACLでは制限できない。念のためAWSに問い合わせてみたところ、同じような要望は多いが対応していない。セキュリティを高めるにはMFAを利用してくださいとのことだった。

MFAは利用者の認証はできるけど場所縛りはできないんだよなあ。WorkSpacesクライアントはタブレット用もあるし、グローバルに考えれば職場に縛られて仕事をするのはナンセンスなのだろうか・・・。データ持ち出しはできないとは言え、画面は表示されるわけで、セキュリティ観点では制限したいところだけど。

2018/04/30より、待望のアクセス制限が実装！！（遅ればせながら更新）
詳細は公式かサーバーワークスさまのBlogへ！
WorkSpaces の IP アクセスコントロールグループ - Amazon WorkSpaces

WorkSpacesの接続元IPアドレス制限 – サーバーワークスエンジニアブログ

データ持ち出し

WorkSpacesのクライアントはデフォルトでクリップボード、プリンタのリダイレクトが有効になっているが、これらを無効にすることでデータ持ち出しはできなくなる。グループポリシーの修正は若干手間がかかるが、ウェブに丁寧に手順が載っているのでその通りにすれば問題なし。
グループポリシーを使用した Windows WorkSpaces の管理 - Amazon WorkSpaces

24H365D利用

WorkSpaces自体は作成時にMulti-AZになるように最低限2サブネットが必要になるので、AZレベルの障害対策はデフォルトでできている。ただし、毎週日曜の0時～4時がメンテナンス時間に設定されている。
よくある質問 - Amazon WorkSpaces（仮想クラウドデスクトップ） | AWS

どうも、必ずメンテナンス停止されるわけでもなく、されたとして4時間すべて利用不可というわけでもないようだが、メンテナンス有無は事前に連絡されない（されることもある）らしい。というわけで完全に24H365D利用することはできない。

こちらのブログに詳しい。
Amazon WorkSpacesの運用知見についてあれこれお答えします – サーバーワークスエンジニアブログ

開発ソフトの利用

大事なことは、WorkSpaceのOSは Windows 7 では無く、Windows Server 2008 R2 ＋デスクトップエクスペリエンスであること(Windows 10 は Windows Server 2016ベース)、そして 64bit しか選べないことだ。実質、Windows 7とWindows Server 2008 R2のアプリケーション互換性、さらに64bit OSでの32bitアプリの互換性について問題になることはあまり無いと思うが、気を付けておくべきところだと思う。

その他使ってみてわかったこと

初期バンドルから作成したWorkSpaceをカスタムバンドルに切り替えることはできない

開発メンバにWorkSpaceを展開するにあたっては、各自で開発ツールをセットアップするのではなく、共通の環境をセットアップ済みのマスターイメージをもとにして、メンバ人数分のWorkSpaceを作成していくことでメンバの手間を減らすことができる。

WorkSpacesでもカスタムイメージからバンドルを作成し、そのバンドル(仮にカスタムバンドルと呼ぶ)をもとにWorkSpaceを作成していくことができる。

最初の1台は、まだカスタムバンドルは作成していないので、当然デフォルトで用意されているバンドル（Standard Plus with Office 2013など。仮に初期バンドルと呼ぶ。)から選んで作成することになる。

カスタムバンドルの作成はおよそ以下の流れになる。

最初の1台をセットアップして、カスタムイメージを作成する。
カスタムイメージをバンドルに変換する
2台目以降のWorkSpaceをカスタムバンドルからLaunchしていく

また、カスタムバンドル自体をアップデートしたいときは次のようになる

利用者のだれかのWorkSpaceのカスタムイメージを作成する
既存のバンドルを、作成したカスタムイメージでアップデートする
作成済のWorkSpaceについては、再構築をすると新しいバンドルの状態で再構築される(再構築しなければ影響なし)。新規の利用者については、Launch時にアップデートされたバンドルの状態でWorkSpaceが作成される。

ここで注意したいことは、あるバンドルから作成されたWorkSpaceを、ほかのバンドルに切り替えることはできないということだ。
たとえば、最初に作成した1台は、初期バンドルをもとに作成されているため、再構築すると常に初期バンドルの状態に戻ってしまう。そしてWorkSpaceは、そのもとになったバンドル自体を切り替えることはできないため、作成したカスタムバンドルに変更することはできない。

そのため、カスタムバンドルを作成するために作る最初の1台については、月額課金ではなく、従量課金にしておいて、カスタムイメージ作成後に削除し作り直すことをお勧めする。

そのほかバンドル作成で気づいたこと

カスタムイメージからバンドルへの変換時にSysprepが実行される。WorkSpacesのWindows Serverは英語OSの日本語表示(MUI)なので、SysprepによってLocalizationがリセットされてしまう。そのためカスタムイメージからLaunchしたWorkSpaceは英語環境になっている。キーボードも英語キーボードになっているのでコントロールパネルの地域と言語から設定を変更する必要がある。
カスタムイメージの作成は、作成時にも説明が表示されるが45分程度かかる。作成の間はイメージを作成しているWorkSpaceは使えない。
カスタムイメージからバンドルへの変換は10分程度で終わる様子

費用面

月額課金(Always On)と時間課金(On Demand)を選べるとあるが、時間課金は完全従量ではなく、月額＋従量の形になっている。また、Plusバンドル(Office 2013)の15USD は月額課金になる。つまりStandard Plusの場合、(9.75 USD + 15USD) /月 + 0.26 USD/時となり、24.75USDは月額となる。月額分はWorkSpaceのLaunch毎に発生するので注意が必要。ただし、利用開始日によって月額部分は日割りされる。利用開始当初は何かとLaunchを繰り返すことになるので、月末の利用開始がおすすめ。月の最終日は何度Launchしても月額分は日割りにより0円になるらしい(On Demandの従量分は発生するかも？)。日割りについては前述のServerWorksさまのBlogが詳しい。

以前のバージョン（VSS）が使えない

WorkspaceのDドライブは「以前のバージョン」機能は使えない。自動でスナップショットがとられるが、Workspaceの再構築をすると「12時間以内のどこか」でとられたスナップショットに戻るだけ、CドライブやOSの設定もリセットされてしまうので、間違ってファイルを消してしまった時の備えにはならない。バックアップは別に考える必要がある。