はじめに

皆様こんにちは、あかいけです。

適当にAWSサービスを使いたいだけなのに、まずIAMロールを作らないといけない…。
この地味な足止めを肩代わりしてくれる「role manager(ロールマネージャー)」が提供されるようになったので、実際に使ってみます。

アップデート概要

role managerは、AWSサービスが必要とするIAMロールをコンソールの操作フローの中で自動的に用意してくれるIAMの新機能です。
対応サービスでリソースを作成すると、必要なロールを自動で作成するか、要件に合致する既存ロールを再利用します。

https://aws.amazon.com/about-aws/whats-new/2026/08/aws-iam-role-manager/

role managerの仕組み

role managerが有効なとき、対応サービスのコンソールでリソースを作成すると、サービスとユースケースに合ったロールテンプレートが適用されます。
ロールテンプレートとは、信頼ポリシーと権限をまとめたロールの設計図です。

処理の流れは以下のとおりです。

内部的にはAcquireRoleというAPIが呼ばれ、テンプレートが必要とするIAMアクションを利用者の権限に照らして評価したうえで、上図のロールを返します。

role managerが作成したロールは、自分で作った普通のロールと変わりません。
閲覧も編集も削除もできますし、各ロールには元になったテンプレートが記録されるので、role manager由来のロールを識別できます。
また、作成時にはAcquireRoleイベントがCloudTrailに記録されるため、いつ誰がどのように作ったかを監査できます。

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_role-manager.html

対応サービス

現時点では、以下6つのサービスコンソールに対応しています。
対応サービスは今後も追加されていく予定とのことなので、今後に期待したいですね。

• AWS Elastic Beanstalk
• Amazon EventBridge
• AWS Lambda
• Amazon SageMaker Unified Studio
• AWS Secrets Manager
• AWS Step Functions

ロールテンプレートについて

各サービスがどのテンプレートを使うかは、公式ドキュメントに一覧があります。

テンプレートのバージョンはイミュータブルで、AWSがテンプレートを更新するときは既存バージョンを変更せず新しいバージョンを発行します。

なお、PowerUserRoleTemplateのように「自分のコードを動かす」といった用途のテンプレートは、あらかじめ必要な権限を特定できないため、広めの権限を付与します。

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_role-template.html

運用時のポイント

有効化の方法から権限の絞り込み、組織単位での制御まで、運用で押さえておきたい点をまとめます。

有効化と最小権限化の考え方

role managerの有効/無効は、IAMコンソールのAccount settingsページで切り替えます。
有効化/無効化にはiam:PutAccountProperties権限が必要で、AWS管理ポリシーIAMFullAccessに含まれています。

また前述の通りrole managerが作るロールは、素早く使い始められるようにデフォルトで広めの権限を持っています。
そのため公式ブログでも、リソースが実際に必要とする権限が分かってきた段階で、権限を絞り込んでいくのが推奨されています。

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_role-manager_least-privilege.html

組織での制御

AWS Organizations環境では、SCPでrole managerの利用を制御できます。
たとえばiam:PutAccountPropertiesを拒否すればメンバーアカウントでの有効化自体をブロックできます。

またiam:RoleTemplateARNコンテキストキーを使えば、テンプレートベースのロール作成だけを拒否する、逆にrole manager経由以外のロール作成を拒否する、といった制御も可能です。

マルチアカウント環境でガードレールを敷きたい場合は、このあたりを検討することになりそうです。

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_role-manager_enable-use.html

試してみた

ここからは実際にrole managerを動かして確認していきます。

1.role managerを有効化する

IAMコンソールの「アカウント設定」を開くと、「Role manager」セクションが増えていました。
デフォルトでは「無効」になっています。

右上の「有効化」ボタンを押すと、表示が「有効」に変わりました。
これでこのアカウントでrole managerが動く状態になります。

2.Lambda関数を作成してロールが自動作成されるか確認する

次にLambda関数をコンソールから作成します。

「その他の設定」を開くと「カスタム実行ロール」はデフォルトでオフのままで、明示的にロールを指定しなくても関数を作れるようになっていました。

実際にロールの作成画面を見ると、権限の選択肢が 「Automatic permissions」 「Use existing role」 「Create new role」 の3つに分かれており、Automatic permissionsがデフォルトで選択 されていました。
説明にも「This is the default because your account currently has Role Manager enabled.」とあり、role managerを有効にしたことでこの挙動になっていると分かります。

3.作成されたロールを確認する

関数作成後、Lambda側の「設定 > アクセス権限」を見ると、実行ロールにPowerUserRoleというロールが割り当てられていました。
リソースの概要にはPowerUserAccess由来のアクションが並んでおり、かなり広い権限を持っていることが分かります。

IAMコンソールでPowerUserRoleの詳細を確認します。
説明は「Power user role for lambda.amazonaws.com」となっており、アタッチされている許可ポリシーはPowerUserAccessでした。
対応サービス表にあったLambdaのテンプレートPowerUserRoleTemplateが、そのままPowerUserRoleとして作成されていますね。

4.CloudTrailでAcquireRoleイベントを確認する

ロール作成時のログをCloudTrailで探すと、AcquireRoleイベントが記録されていました。
イベントソースはiam.amazonaws.comで、ロール作成の時刻(10:43:19)と一致しているので、このイベントでしょう。

※ IAMはグローバルサービスなのでこのイベントはバージニア北部(us-east-1)に記録されていました

さいごに

以上、IAMロールを自動的に設定するrole managerの紹介でした。

「まず動かして、後からAccess Analyzerで絞り込む」という流れを前提に設計されているようなので、初めて触るAWSサービスのキャッチアップや検証での利用すると便利そうです。