roleにpolicyをアタッチする時のmanaged_policy_arnsとはsellAWS,Terraformはじめにterraformを使ってAWSのIAMを管理する際、ロールに管理ポリシーをアタッチする際にはaws_iam_role_policy_attachmentを使用していましたが、aws_iam_roleのmanaged_policy_arns引数を利用してもアタッチができるため、両者の違いは何か調べてみました。aws_iam_role_policy_attachmentを用いたポリシーのアタッチaws_iam_role_policy_attachmentを用いてロールにポリシーをアタッチする方法は以下の通り。aws_iam_policy.policy.arn}aws_iam_role、aws_iam_policyをそれぞれ定義した後、aws_iam_role_policy_attachmentにてそれらを紐づけるといった流れです。managed_policy_arnsを用いたpolicyのアタッチaws_iam_roleのmanaged_policy_arns引数を用いてロールにポリシーをアタッチする方法は以下の通り。]}EOF}aws_iam_roleの引数にmanaged_policy_arnsを追加し、ポリシーを指定することでアタッチができます。何が違うかどちらの方法もロールに管理ポリシー(AWS管理ポリシー、カスタマー管理ポリシー)をアタッチすることが可能ですが、これらには互換性がなくterraform内では明確に異なるものとして認識されるようです。difference.しかしながら、マネジメントコンソールでのポリシーアタッチなどterraform管理外でリソースを変更した際の挙動に違いがありました。applyを実行すると以下のような挙動となりました。policy_bをデタッチmanaged_policy_arnsで定義した場合のみ外部での変更を検知した際に、事前に定義した状態に戻りました。applyを実行すると以下のような挙動となりました。policy_aを再アタッチデタッチの場合は両者ともに事前に定義した状態に戻りました。上記2つの結果から、managed_policy_arnsは外部での変更があった場合terraformの定義状態に戻るのに対し、aws_iam_role_policy_attachmentでは外部での追加は許容する挙動となることがわかります。上記方法の両方を利用してロールにポリシーをアタッチした場合の挙動を調べました。この2つの管理方法を併用することは推奨されておりませんので、本番環境等では利用しないでください。両方で同一のポリシーをアタッチした場合エラーなく、ポリシーがアタッチされます。両方で同一のポリシーをデタッチした場合エラーなく、ポリシーがアタッチされます。両方で同一のポリシーをアタッチ後、managed_policy_arnsのみ当該ポリシーをデタッチした場合apply1回目:当該ポリシーをデタッチapply2回目:当該ポリシーをアタッチapply3回目:当該ポリシーをデタッチapply4回目:当該ポリシーをアタッチ・・・・・アタッチとデタッチを繰り返します。change2回applyを実施した段階で定常状態へと遷移します。おわりにterraformにてロールに管理ポリシーをアタッチする方法としてmanaged_policy_arnsとaws_iam_role_policy_attachmentの2種類の方法があり、両者の挙動には明確な違いがあることがわかりました。terraformでの定義状態を遵守したい場合にはmanaged_policy_arnsを、定義状態+αな変更を許容する場合にはaws_iam_role_policy_attachmentでよいのかなと思います。applyの結果が循環してしまう等想定外の結果を招いてしまうことがわかりました。参考文献この記事は以下の情報を参考にして執筆しました。