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ポリシーがあるのだから、適切に使っていきたいですね。

AWS MGN は PowerUserAccessだとパワーが足りない