リージョン間カスタムイメージコピーが実装されたので、WorkSpacesのDR構成を作成してみました。

記事タイトルとURLをコピーする

こんにちは、技術3課の城です。
先日、下記のドキュメントが更新されていることに気づきました。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/copy-custom-image.html

そう、WorkSpacesのカスタムイメージコピー(リージョン間も!!)が出来るようになっていたのです!!

これまではリージョンレベルの障害に対してのDiserster Recovery(以降、DR)を意識したWorkSpaces運用をする場合、DR先のリージョンで一からイメージを作成しておく必要がありました。
これからは数クリックでカスタムイメージ自体をコピーできるとなると、かなりハードルが下がった気がします。
早速、DR構成を試してみます。

1.前提

メインリージョンは東京リージョン(ap-northeast-1)とし、DR先をシンガポールリージョン(ap-southeast-1)とします。

2.構成

構成としては定石通り、東京リージョン側はアベイラビリティゾーン(以降、AZ)を2つ利用し可用性を担保します。
Active Directory(以降、AD)on EC2をそれぞれのサブネットに配置し、レプリケーションさせます。
東京リージョン側のAD Connectorについてはこちらの2台のADをDNSサーバーとして登録します。
DR先のシンガポールリージョンのVPCとはVPCピアリングを利用してVPC間を通信可能にします。
シンガポールリージョンのVPCにもADを配置し、東京リージョン側と同一ドメインのドメインコントローラーとして稼働させ、レプリケーションします。
シンガポールリージョンのAD ConnectorについてはシンガポールリージョンのADをDNSサーバーとして登録します。
利用者は別リージョンのWorkSpacesを利用したい場合はレジストレーションコードを変更してアクセスします。

全てをホットスタンバイさせるのはコストが高くつくので、RTOが1時間程度許容され、かつ、障害時に構築することが可能であれば、障害発生後にAD Connector及び、WorkSpacesを作成する方針でもよいかと思います。
また、AD Connector + AutoStopのWorkSpacesを1台だけ作成しておく、など状況に応じて選択するかなと思います。

3.WorkSpacesイメージの作成

下記公式ドキュメントに沿って、東京リージョン側でWorkSpacesイメージを作成します。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/create-custom-bundle.html

豆知識ですが、Windows Updateされていないとイメージ作成に失敗するので、イメージ作成前はWindows Updateの確認 + 再起動をしておくと幸せになれます。

4.イメージのコピー

冒頭のドキュメントに沿って、イメージをシンガポールリージョンにコピーします。

マネジメントコンソールのWorKSpacesの画面にて左側サイドバーの[イメージ]をクリックします。
コピー元となるカスタムイメージにチェックし、[アクション]⇒[イメージをコピーする]とクリックします。

[対象を選択する](コピー先のリージョン)、[コピーの名前]、[説明]を入力し、[イメージをコピーする]をクリックします。

なお、コピー先にDirectory ServiceやWorkSpacesなどのリソースを作成していなくても、イメージコピーは可能なようです。

5.イメージの確認

シンガポールリージョンにイメージがコピーできているか確認します。
コピーを開始してすぐはステータスが「PENDING」となっていましたが、10分はかからず「AVAILABLE」となりました。

6.バンドルの作成

シンガポールリージョンにて、コピーしたイメージからバンドルを作成します。
コピーしたイメージにチェックし、[アクション]⇒[バンドルの作成]とクリックします。

必要な項目を入力し、[バンドルの作成]をクリックします。

7.WorkSpacesの作成

下記ドキュメントを参考にシンガポールリージョンにて、WorkSpacesを作成します。
バンドルの選択の際に、作成したカスタムバンドルを選択して作成します。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/launch-workspace-ad-connector.html#create-workspace-ad-connector

8.アクセス確認

ユーザーから東京、シンガポール、それぞれへのアクセスを制御するものとしては、「レジストレーションコード」となります。
東京、及び、シンガポールリージョンのWorkSpacesのレジストレーションコードを登録し、ログインしてみます。
詳細なログイン方法についてはこちらのブログでもご紹介しておりますので、不明点ある場合はご覧ください。

WorkSpacesクライアントを起動し、[歯車マーク]⇒[登録の管理]とクリックします。

東京リージョン側のWorkSpacesのレジストレーションコードを入力し、[登録]をクリックします。

[ユーザー名]、[パスワード]を入力し、[サインイン]をクリックします。

ログインできました。
Powershellで下記コマンドを実行して、メタデータを取得しAZを確認してみます。

Invoke-RestMethod -Uri "http://169.254.169.254/latest/meta-data/placement/availability-zone" -Method GET

このWorkSpaceはap-northeast-1cに配置されていることが分かります。

WorkSpacesクライアントのレジストレーションコードを変更し、シンガポールリージョン側のWorkSpacesも同一ユーザーでログインし確認してみます。
こちらのWorkSpaceはap-southeast-1aに配置されていますね。
WorkSpacesのDR構成ができました。

9.おわりに

WorkSpacesのDRというと、ハードルが高いものと感じていましたが、イメージコピーができるようになって、少し緩和された気がします。
ただし、今回作成してみた構成においてはユーザー領域のデータについては同期されていないので、WorkSpacesの外部にデータを持たせる設計にするなど、少し工夫が必要かと思います。
必要な要件に応じて、適切な設計ができるといいですね!

どなたかの助けになれば、幸いです。

城 航太 (記事一覧)

営業部カスタマーサクセス課・課長

AWSへの移行、AWSアカウントセキュリティ、ネットワーク広く浅くといった感じです。最近はAmazon WorkSpacesやAmazon AppStream2.0が好きです。APN Ambassador 2019,2020