事象
罠に引っかかるまでの流れを記します。
■準備段階
①検証アカウントで、既に存在していた「AWSDataLifecycleManagerDefaultRole」のARNを確認
②DLMの設定をデプロイするためのCloudFormationテンプレートに①で確認したARNを記載。
※アカウントID部分は本番アカウントIDに置換しました。
■構築時
③新規の本番アカウントでCloud ShellからAWS CLIでAWSDataLifecycleManagerDefaultRoleを事前に作成
④新規の本番アカウントで②で準備したCloudFormationテンプレートをデプロイ
■試験時
⑤構築翌日にDLMの実行がエラーになっていることを確認
入念にCloudFormationテンプレートの中身は確認していたので、単なる誤字脱字ではありませんでした。
皆さんはこの事象が起きた原因が何かわかりますでしょうか。
そもそもIAMサービスロールってなんだっけという方は、以下の記事のIAMサービスロールとIAMロールの違いをまとめた表がわかりやすかったです。
IAMサービスロールとIAMロールの違い
原因
単刀直入に述べると
CloudFormationテンプレートのDLM設定に記載したIAMロールのARN（①で確認したARN）が正しい文字列でなかったこと
が原因でした。
ではなぜ間違っていたか。
それは以下のようにIAMサービスロールの作成方法が異なることが根本の原因でした。
- 検証アカウントの「AWSDataLifecycleManagerDefaultRole」→ AWSコンソールで作成されたIAMサービスロール
- 本番アカウントの「AWSDataLifecycleManagerDefaultRole」→ CloudShell（AWS CLI）で作成されたIAMサービスロール
具体的には以下のように異なるようです。
| 作成方法 | ARN形式 |
|---|---|
| AWSコンソール | arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole |
| AWS CLI | arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole |
AWS公式：Amazon Data Lifecycle Manager のデフォルトのサービスロール
話を戻すと、本番アカウントでは新規にCloudShell（AWS CLI）で作成されたIAMロール、つまり /service-role/のパスがつかないIAMサービスロールが作成されたにもかかわらず、
CloudFormationテンプレートのDLMの設定部分では /service-role/のパスがついたIAMサービスロールのARNを指定してしまっていたことにより、エラーが起きたようでした。
あとがき
日頃、事前準備時にリソースに必要なパラメータなどは準備しておくことが多いですが、本番のリソースをどのように作成するかで今回のようにIAM ARNが変わるといったこともあるので、構築の流れを見据えて準備するべきだと学んだ一件でした。
どなたかの役に立ちますように。