AWS IAM role managerが変える、IAM ロール作成の出発点

本ブログは 2026 年 8 月 12 日に公開された AWS Blog「How AWS IAM role manager rethinks the starting point for IAM roles」を翻訳したものです。

Amazon Web Services (AWS) 上で新しいアプリケーションや機能を構築するとき、注力したいのは構築そのものです。しかし、サービスを稼働させる作業は、ほとんどの場合 AWS Identity and Access Management (IAM) から始まります。お客様に代わって動作する多くの AWS サービスには IAM ロールが必要です。IAM ロールとは、サービスが引き受けることで、定義されたアクセス許可のセットの範囲でお客様のリソースにアクセスするためのアイデンティティです。サービスがロールを引き受けられるように信頼ポリシーを作成し、ワークロードに必要なアクセス許可を選択してアタッチします。一般的なパターンに対するロールとポリシーの設定は繰り返し発生する作業であり、本来手作業で行う必要はないはずです。

IAM role manager は、この作業を代行します。Role manager を有効にすると、サポート対象のサービスコンソールで構築を進めるのに合わせて AWS が IAM ロールを作成・設定するため、背後のロールは AWS に任せて、すぐにサービスを使い始めることができます。必要なリソースを作成すると、role manager が同じフローの中で対応するロールをプロビジョニングしてアタッチします。そのため、まずは構築を進め、ワークロードの成熟に合わせてアクセス許可を絞り込んでいくことができます。

このステップが自動化されることで、開始までの時間は数分になります。AWS Lambda 関数を作成すると、実行ロールが既に作成・アタッチされた状態でコードの実行を開始でき、ロールを設定するためにコンテキストを切り替える必要はありません。ロールの作成は独立したステップではなく、アプリケーション構築の中に自動的に組み込まれた一部になります。

Role manager が特に役立つのは、サービスを立ち上げたい、概念実証 (PoC) を動かしたい、ロールの設定は開発プロセスの後半まで先送りしたい、といった使い始めの場面です。使い始めるにあたって IAM の事前知識は必要ありません。また、作成されるロールは、自分で作成したロールと同じように表示・編集・削除できる通常の IAM ロールであるため、何が作成されるかを完全にコントロールし続けられます。ロールを絞り込みたくなったときは、AWS IAM Access Analyzer がロールの使用状況をレビューし、必要なアクセス許可のみにスコープを絞ったポリシーを推奨します。

Role manager を有効にする方法

Role manager には、有効と無効の 2 つの状態があります。アカウントで有効にすると、そのアカウント内でのロール作成を AWS に許可することになります。組織で利用する場合、管理者はサービスコントロールポリシー (SCP) を使用して、メンバーアカウントが role manager を有効化・使用できるかどうかを制御できます。有効にする手順は次のとおりです。

1. IAM コンソールを開き、アカウント設定 を選択します。
2. Role manager のセクションで、有効化 を選択します。

一部の AWS サービスは、ロールを必要とするリソースを作成する際に、従来からロールを自動的に作成します。Role manager はこの動作を変更しません。それらのサービスは引き続き自動的にロールを作成し、既に作成済みのロールもそのまま機能し続けます。Role manager が追加するのは、アカウントレベルの単一のコントロールと、組み込みのフローでは対応できないケース、つまり必要なアクセス許可を AWS が事前に判断できないタスク (お客様自身のコードの実行など) への対応です。そのようなタスクに対して、role manager は後から絞り込めるロールをプロビジョニングします。

例: Amazon EventBridge ルールの作成

まずは一般的なタスクから始めましょう。Amazon Simple Queue Service (Amazon SQS) キューや Amazon Simple Notification Service (Amazon SNS) トピックなどのターゲットを呼び出す、Amazon EventBridge のルールです。Role manager がない場合、ここで一旦作業を中断して、EventBridge がターゲットを呼び出せるようにするロールを作成し、ロールの信頼ポリシーを記述し、必要なアクセス許可をアタッチしてから、ルールの作成に戻ることになります。Role manager が有効な場合は、ルールとそのターゲットを定義して 作成 を選択すると、role manager がロールをプロビジョニングし、アタッチまで行います。EventBridge コンソールにはルールが作成されて利用可能な状態で表示され、ロール作成のフローを開く必要は一切ありません。

このロールは AWS マネージドロールテンプレートから作成されます。これは特定のタスクのために AWS が構築・保守する定義で、信頼ポリシーとアクセス許可があらかじめ設計されています。コンソールは新しい IAM API である AcquireRole を呼び出します。AcquireRole は一致するテンプレートを見つけ、そこからロールをプロビジョニングして EventBridge に返します。サービスに応じて、AcquireRole は新しいロールを作成するか、既に条件に合う既存のロールを再利用するため、同じタスク用の重複したロールでアカウントがあふれることはありません。

Role manager は、専用の role manager アクセス許可ではなく、お客様自身の IAM アクセス許可を使用してロールを作成します。新しいロールをプロビジョニングするには、テンプレートが実行するアクションに対するアクセス許可、最低でもロールの作成とアタッチを行うアクセス許可が必要です。AcquireRole が新規作成ではなく既存のロールを再利用する場合に必要なのは、iam:GetRole と iam:GetRoleTemplateVersion のみです。これらのアクセス許可のいずれかが不足している場合、コンソールはロールを作成せず、どのアクセス許可が必要かを表示します。

他の AWS サービスを呼び出すコードの実行

すべてのタスクに AWS が事前に定義できるアクセス許可のセットがあるわけではありません。Lambda 関数のように、ロールがお客様自身のコードを実行する場合、そのコードがどのサービスを呼び出すのかを AWS が知る方法はありません。Role manager はこのケースにも対応します。Role manager を有効にして Lambda 関数を作成すると、コードからすぐに使用できる実行ロールがアタッチされ、関数が何を呼び出すかが分かった時点で絞り込むことができます。

コードが必要とするアクセス許可が事前には分からないため、role manager は AWS マネージドポリシーである PowerUserAccess をロールにアタッチします。PowerUserAccess は AWS サービスへのアクセスを付与するため、関数は必要なサービスを呼び出せます。設計上、IAM、AWS Organizations、アカウント設定を管理するアクセス許可は付与されません。また、テンプレートは Lambda サービスのみを信頼するようにロールを設定します。

Role manager が実行ロールをアタッチし、関数は実行可能な状態になります。図 4 は、関数の 設定 タブにある実行ロールパネルに、role manager がアタッチしたロールが表示されている様子です。

IAM コンソールでロールを開いて、そのアクセス許可を確認できます。図 5 は、PowerUserAccess ポリシーがアタッチされたロールの 許可 タブです。

Role manager が作成するものに対する完全な可視性は維持されます。作成されるすべてのロールには、元になったロールテンプレートが記録され、GetRole と ListRoles の両方がそのテンプレートへの参照を返します。アカウント内の任意のロールを調べて、どれが role manager によって作成されたかを判別できます。ロールの信頼ポリシーとアクセス許可は、自分で作成したロールと同じ方法で確認でき、AWS CloudTrail には各ロールの作成が記録されます。

ワークロードの成熟に合わせたロールの絞り込み

ワークロードが成熟してきたら、最小権限の原則に従うように、role manager が作成したロールを絞り込みます。準備ができたタイミングで role manager を無効にすると、IAM Access Analyzer の未使用アクセス分析を 90 日間、追加料金なしで利用できます。Access Analyzer は各ロールの使用状況を分析し、そのロールが必要とするアクセス許可のみを残したポリシーを推奨するので、それを適用できます。最も重要なワークロードにアタッチされたロールから始めて、順に対象を広げていきましょう。

Role manager を無効にしても、既に実行中のものが中断されることはありません。リソースは現在のロールをそのまま保持し、それらのロールは変更しない限りアカウントに残ります。それ以降の新しいロールは、以前と同じように自分で作成することになります。アカウント全体ではなく単一のロールだけを絞り込みたい場合は、そのロールを編集すると role manager の管理から外れ、変更内容が保持された標準のカスタマー管理ロールになります。サンドボックスや開発用のアカウントでは、role manager を有効にしたままにしておくと時間を節約できます。本番ワークロードについては、本番稼働の前に role manager を無効にし、作成されたロールを最小権限に絞り込んでください。

まとめ

Role manager は IAM ロールのセットアップを自動化するため、最初から構築そのものに集中できます。有効にすると、構築を進めるのに合わせて、リソースに必要な IAM ロールを AWS が作成・アタッチするため、IAM の事前知識がなくても数分で使い始められます。作成されるのは完全にコントロール可能な IAM ロールであるため、これまでと同じ可視性を保ちながら、既に使い慣れたツールをそのまま使い続けられます。構築中は role manager を有効にしておき、ワークロードの成熟に合わせて、作成されたロールを絞り込んでいきましょう。

使い始めるには、IAM コンソールで role manager を有効にし、サポート対象のサービスでリソースを作成してください。詳細については、IAM ユーザーガイドの「IAM ロールの作成」およびサポート対象サービスの一覧を参照してください。

Zach Jiang

Zach は AWS のシニアテクニカルプロダクトマネージャーで、AWS Identity プロダクトを専門としています。お客様にとってアイデンティティが AWS 上での構築の「簡単な部分」になることに注力しています。テクノロジー以外では、旅行や、新しい文化・料理の探求を楽しんでいます。

David Sing

David は AWS のプリンシパルプロダクトマネージャーで、AWS IAM を専門としています。ビルダーと AI エージェントのための IAM の簡素化、AI エージェントへの安全な認証情報の発行、エージェントのアクセスを統制する認可ポリシーに注力しています。テクノロジー以外では、経済と市場、釣り、家族と屋外で過ごす時間を楽しんでいます。

Punit Deotale

Punit は AWS IAM チームのソフトウェア開発マネージャーです。お客様が AWS サービスのワークフロー内で直接 IAM ロールを作成・管理しやすくする取り組みをリードしており、作業の流れを離れることなく適切なアクセス許可を設定できるようにしています。AWS 全体でアクセス許可設定にともなう摩擦を減らしながら、お客様が最小権限を維持できるよう支援することに注力しています。仕事以外では、読書、サイドプロジェクトの開発、アウトドアを楽しんでいます。

本ブログは Solutions Architect の松井 僚太郎が翻訳しました。