Amazon WorkSpacesのバンドル間Migration機能がリリースされました。

AWS運用自動化サービス「Cloud Automator」

こんにちは、技術四課の城です。
2020年のブログ書初めです
新年早々気になるWorkSpacesの機能リリースがありました。
Amazon WorkSpaces Migrate Enables Migration to the Windows 10 Desktop Experience and the New WorkSpaces Streaming Protocol in Beta

ドキュメントを読んで分かったこと、実際やってみてどうだったのかについてレポートしたいと思います。

1. Migrate a WorkSpace(WorkSpaceの移行)とは

ユーザーボリュームを保持したまま、別のバンドルでWorkSpaceを作り替える機能のようです。
Migrate a WorkSpace

これまでは別バンドルに移行する際は、次のように行う必要がありましたが、だいぶ楽になりそうです。
①既存WorkSpaceのユーザーボリュームのデータをバックアップ、WorkSpace外に退避
②既存WorkSpaceを削除
③新しいバンドルにてWorkSpaceを作成
④ユーザーボリュームのデータをインポート

いくつか制限や注意事項があるようですので、説明していきます。

1.1 制限(2020年1月12日現在)

制限内容としては次の通りです。

  • Windows 7 バンドルへの移行は不可
  • BYOLバンドルの移行先はBYOLバンドルのみ
  • BYOLバンドルの移行元はBYOLバンドルのみ
  • Microsoft Officeなどのプラスバンドルと非プラスバンドル間の移行は不可
  • Linux WorkSpacesの移行は現在はサポートされていない
  • 異なる言語設定のバンドル間での移行は可能
  • 同一バンドルへの移行は不可(リビルドを使ってください)

Migration Limits

1.2 移行の詳細

ユーザーボリュームについては保持されます。
ただし、そのまま移行されるわけではなく、最終スナップショットから再作成されますので、最大12時間のロールバックの可能性があります。

また、D:\Users\%USERNAME%フォルダーについて、初回起動時にD:\Users\%USERNAME%MMddyyTHHmmss%.NotMigratedフォルダーに移動され、新しいD:\Users\%USERNAME%\フォルダーが作成されます。
新しいユーザープロファイル(D:\Users\%USERNAME%)が作成されると、次のフォルダーについては.MotMigratedフォルダーから新しいユーザープロファイルに移動されます。

  • D:\Users\%USERNAME%\Desktop
  • D:\Users\%USERNAME%\Documents
  • D:\Users\%USERNAME%\Downloads
  • D:\Users\%USERNAME%\Favorites
  • D:\Users\%USERNAME%\Music
  • D:\Users\%USERNAME%\Pictures
  • D:\Users\%USERNAME%\Videos

ということですので、.NotMigratedフォルダーに残っているフォルダー、ファイルについては、必要に応じて手動でコピーする必要がありそうです。

ルートボリュームについては、移行先のバンドルのものが適用されますので、必要に応じて手動で対応が必要となります。

What Happens During Migration

1.3 事前に対応、確認すべきこと

下記、推奨事項となりなります。

  • ルートボリュームに含まれる重要なデータのバックアップ
  • データロストを避けるため、コンソールの【WorkSpacesの移行】のページにて最後のスナップショットの時刻を確認し、最終変更時刻より後であることを確認する
  • WorkSpaceのステータスがAVAILABLE、STOPPED、または、ERRORであることを確認する
  • WorkSpaceのサブネットの利用可能IPアドレスが枯渇していないことを確認する
  • スクリプト等で複数のWorkSpacesを移行する場合には1回につき25台以下とする

Best Practices

2. 実際に移行してみる

今回Standard with Windows 7のバンドルからStandard with Windows 10のバンドルへ移行してみます。
移行元となるWorkSpacesについてはこちらです。

確認用にユーザーのドキュメントフォルダーやDドライブ直下にファイルなどをおいてみました。

また、追加でChromeをインストールしておきました。
こちらは移行先には残らない想定です。

余談ですが、スナップショットの前回取得時間が直前だったので、泣く泣く12時間後に再開することにしました。

対象のWorkSpaceにチェックを入れ、[アクション]、[WorkSpaceを移行]とクリックします。

移行先のバンドルを選択し、[WorkSpaceの移行]をクリックします。
上部のタブでフィルターをかけることが出来るので、上手く利用しましょう。

PENDING状態に移行します。しばらく待ちましょう。

状態がAVAILABLEとなり、問題なく、移行できました。

再作成なので、WorkSpace ID、IPアドレス、コンピューター名は変更されています。

3.移行後の確認

移行後の状態をログインして確認してみます。
Chromeはインストールされておらず、ドキュメント通りの結果でした。

また、ユーザーボリュームについてもドキュメントの説明通りで、中身は次の画像のようになっていました。

なお、.AppDataは.NotMigratedフォルダーに残されているので、ためしにChromeをインストールし、.AppData\Local内のGoogleフォルダーを.NotMigratedフォルダーからユーザープロファイルへ移動したところ、想定通り、Chromeの設定は復元できました。

さいごに

とても求められていた機能がリリースされました。
もうちょっと早ければ・・・という声は聞こえてきそうですが、Windows 7、Windows 2008R2等のサポート切れ対応にも効果的な機能ではないでしょうか。
また、AWS公式のブログポストにもありますが、WSP(WorkSpaces Streaming Protocol)の対応バンドルへの移行にも利用できそうです。

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

AWS運用自動化サービス「Cloud Automator」