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

# AWS MGN とは

AWSのサービスの1つであり、Application Migration Service の略称です。
参考：[AWS Application Migration Ser vice (AWS MGN) 概要](https://www.youtube.com/watch?v=HktS_jCIv9Q)

オンプレミスの仮想マシンに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)のボタンを押してみましょう。

![MGN_GettingStartError.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/9ba93e17-7711-0c0e-8b68-6e24fa09ac0c.png)

・・・はい、早速失敗しました。😨

[AWSのAWS MGNのドキュメント](https://docs.aws.amazon.com/mgn/latest/ug/mgn-initialize-console.html
) に書いてました。

```
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ユーザーで実行だ。
あれ・・・反応が無い・・・
次のアクションの表示が進んでいない・・・

起動履歴を見てみよう。

![mgn_joblog_conversion_failed.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/297af076-823f-0e01-b1a7-3c54d7a59705.png)

・・・はい、失敗していました。😨

イベントログではシンプルに「変換に失敗しました」と表示されているだけです。（英語では "Conversion Failed"）
これだけだと、何が原因なのか見当が付きませんね。

以下の方の投稿では、 **起動テンプレート** の設定ミスが原因とありました。これも可能性の1つなので、まずはMGNの設定ミスを疑いますよね。

https://qiita.com/konyakun/items/945b8f33c617505b7ad0

EC2起動テンプレートでやりがちなミスに関して言うと、テンプレートのバージョンを上げた時に、デフォルトバージョンを最新バージョンに切り替え忘れるのも、やりがちと思います。

デフォルトバージョンを最新バージョンに変え忘れた例：

![EC2_launch_template_mistaken.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/06f98190-c43e-00fb-0f5e-829daf32fd98.png)


MGNの周りであれこれみて、設定ミスが見つからない。
そうなると、もしかして、仮想マシン、ハイパーバイザー、ネットワークアダプターが特殊だったかな、とか、**オンプレミス側**の構成の問題を疑ってしまうかもしれません。
オンプレミス側の設定を見始めると、泥沼です。

でも、PowerUserAccessのIAMユーザーで作業していたのなら、原因はそっちではなく、**IAMポリシー** なんです。

# 適切なIAMポリシー

MGN操作には、適切なIAMポリシーがあります。

**AWSApplicationMigrationFullAccess** ＋ **AWSApplicationMigrationEC2Access** の2つのIAMポリシー（以下、AWSApplicationMigrationXXX）を持つIAMユーザーを使っていればよかったのです。

「え？なんで？ AWSApplicationMigrationXXX の方が強いの？ PowerUserAccess がそれも全部含んでんと違うの？」

そう言いたくなりますが、AWSApplicationMigrationXXX の許可アクションが全て PowerUserAccess に含まれているわけではないのです。

ベン図で表現するとこうなります。

![AccessDiff.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/8ae24638-9e9d-605a-032e-33443b8433ad.png)


この斜線部分は、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ポリシーを割り当てて、再実行します。

![mgn_joblog_conversion_success.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/3bb2dfb8-05f6-dd60-81be-14d6cd47ea64.png)

はい、変換できました！😊

# PowerUserAccessのパワー不足

PowerUserAccessって最強！これ付けていればなんでもできる！と思ってしまいますが、思わぬところでIAMの変更系のアクションが必要になって、パワー不足になったりします。

せっかくAWSが用意してくれているマネージドのIAMポリシーがあるのだから、適切に使っていきたいですね。