AWS MGN とは
AWSのサービスの1つであり、Application Migration Service の略称です。
参考：AWS Application Migration Ser vice (AWS MGN) 概要
オンプレミスの仮想マシンにMGNエージェントをインストールすると、少量のCPUリソースで動作します。接続されたストレージ機器がiSCSIであろうがSANであろうが、OSがローカルディスクとして認識していれば丸々AWSにコピーして、EC2＆EBSにしてくれます。
VMWareではエージェントレスの選択肢もあります。
PowerUserAccess とは
IAMポリシーの1つです。
パワーの文字が付いているように、ほぼすべてのサービスにフルアクセスする権限を持っています。
このIAMポリシーをアタッチしたIAMユーザーはいろんな操作ができて、強いです。
PowerUserAccess で AWS MGN を実行
では、PowerUserAccessポリシーを持ったIAMユーザーを使って、有り余るパワーでMGNを実行してみましょう。
Getting Started!!
そのAWSアカウントで初めてMGNを触る場合、初期化が必要です。
使用を開始(Getting Started)のボタンを押してみましょう。
・・・はい、早速失敗しました。😨
AWSのAWS MGNのドキュメント に書いてました。
AWS MGNs can only be initialized by the Admin user of your AWS Account.
初期化は、AdministratorAccessポリシーのIAMユーザーで実施しましょう。
移行元サーバーの認識から同期の完了まで実行!!
初期化の処理はIAMロールの作成が動くために、まあPowerUserAccessでは足りないのは仕方がない。
ここさえ通過したら、あとはOKだろう。（と思っていた）
PowerUserAccess のIAMユーザーで、ポチポチと進めていく。
- レプリケーションテンプレート・起動テンプレートの設定
- MGNエージェントのインストール (OS内の作業)
- MGN上での移行元サーバーの認識
- 同期の実行
これらが進み、同期が完全に完了するとテストインスタンスの起動が可能になる。
テストインスタンスを起動!!
これも強い権限の PowerUserAccess のIAMユーザーで実行だ。
あれ・・・反応が無い・・・
次のアクションの表示が進んでいない・・・
起動履歴を見てみよう。
・・・はい、失敗していました。😨
イベントログではシンプルに「変換に失敗しました」と表示されているだけです。（英語では "Conversion Failed"）
これだけだと、何が原因なのか見当が付きませんね。
以下の方の投稿では、 起動テンプレート の設定ミスが原因とありました。これも可能性の1つなので、まずはMGNの設定ミスを疑いますよね。
EC2起動テンプレートでやりがちなミスに関して言うと、テンプレートのバージョンを上げた時に、デフォルトバージョンを最新バージョンに切り替え忘れるのも、やりがちと思います。
デフォルトバージョンを最新バージョンに変え忘れた例：
MGNの周りであれこれみて、設定ミスが見つからない。
そうなると、もしかして、仮想マシン、ハイパーバイザー、ネットワークアダプターが特殊だったかな、とか、オンプレミス側の構成の問題を疑ってしまうかもしれません。
オンプレミス側の設定を見始めると、泥沼です。
でも、PowerUserAccessのIAMユーザーで作業していたのなら、原因はそっちではなく、IAMポリシー なんです。
適切なIAMポリシー
MGN操作には、適切なIAMポリシーがあります。
AWSApplicationMigrationFullAccess ＋ AWSApplicationMigrationEC2Access の2つのIAMポリシー（以下、AWSApplicationMigrationXXX）を持つIAMユーザーを使っていればよかったのです。
「え？なんで？ AWSApplicationMigrationXXX の方が強いの？ PowerUserAccess がそれも全部含んでんと違うの？」
そう言いたくなりますが、AWSApplicationMigrationXXX の許可アクションが全て PowerUserAccess に含まれているわけではないのです。
ベン図で表現するとこうなります。
この斜線部分は、AWSApplicationMigrationXXX の許可アクションに存在するが、PowerUserAccess の許可アクションに含まれていないものです。
具体的には、
- IAM の PassRole
- Organization の DescribeAccount, ListAccounts, ListAWSServiceAccessForOrganization, ListDelegatedAdministrators
です。
テストインスタンス起動では、このうちiam:PassRole が足りておらず、具体的には
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::*:role/service-role/AWSApplicationLaunchInstanceWithSsmRole",
"arn:aws:iam::*:role/service-role/AWSApplicationLaunchInstanceWithDrsRole",
"arn:aws:iam::*:role/service-role/AWSApplicationMigrationReplicationServerRole",
"arn:aws:iam::*:role/service-role/AWSApplicationMigrationConversionServerRole"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
のIAMポリシーが足りていないため、変換に失敗していたのでした。
変換処理のために一時的に起動するEC2があって、そのEC2のIAMロール（≒インスタンスプロファイル）の設定時に権限が足りずに内部的にエラーとなっていると思われます。
是非AWSには、「変換に失敗しました」の所にエラーの理由も出すような改善が欲しいところです。
原因が分かったので、AWSApplicationMigrationXXX のIAMポリシーを割り当てて、再実行します。
はい、変換できました！😊
PowerUserAccessのパワー不足
PowerUserAccessって最強！これ付けていればなんでもできる！と思ってしまいますが、思わぬところでIAMの変更系のアクションが必要になって、パワー不足になったりします。
せっかくAWSが用意してくれているマネージドのIAMポリシーがあるのだから、適切に使っていきたいですね。