IAMの新機能「ロールマネージャ」で Lambda の実行ロール設定を省略してみた
はじめに
2026年8月12日、IAM ロールマネージャが一般提供（GA）されました。
払い出されるロールは、サービスごとに用意されたロールテンプレートをもとに作成されます。対応サービスは、公式ドキュメントでは次の6つです。
- AWS Elastic Beanstalk
- Amazon EventBridge
- AWS Lambda
- Amazon SageMaker Unified Studio
- AWS Secrets Manager
- AWS Step Functions
仕組みや有効化手順は、別記事をご参照ください。本記事では Lambda を対象に、ロールマネージャを有効化したアカウントで関数を作成したときの挙動を AWS CLI と API で確認します。
検証内容
関数の作成画面
ロールマネージャを有効化したアカウントの関数作成画面では、実行ロールを設定する項目が表示されず、関数名とランタイムを指定するだけで関数を作成できました。作成した関数は test-iam-0813 です。
ロールマネージャが無効なアカウントでは、基本的な権限を持つ実行ロールがデフォルトで作成されるという説明が表示されました。Custom execution role を選択すると右側にパネルが開き、既存ロールの選択欄と Create new role ボタンが表示されました。
| 項目 | ロールマネージャが無効 | ロールマネージャが有効 |
|---|---|---|
| 実行ロールを設定する項目 | 表示された | 表示されなかった |
払い出されたロールの内容
関数を作成したあと、ロールマネージャの動作を CloudTrail のイベントで確認しました。ロールマネージャによるロールの払い出しは AcquireRole として記録されます。検証はすべて us-east-1 で実施しました。
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=AcquireRole \
--region us-east-1
イベントのリクエストには、適用されたロールテンプレートの ARN とテンプレートに渡された値が含まれており、レスポンスには払い出されたロール名が記録されていました。呼び出し元はコンソール操作に使用した IAM プリンシパルでした。
{
"eventName": "AcquireRole",
"requestParameters": {
"replacementValues": {
"AWSServiceName": { "values": ["lambda.amazonaws.com"] }
}
},
"responseElements": {
"role": { "roleName": "PowerUserRole" }
}
}
ロール名が分かったので、get-role で中身を取得しました。
aws iam get-role \
--role-name PowerUserRole \
--query 'Role.{RoleName:RoleName,Arn:Arn,SourceRoleTemplate:SourceRoleTemplate}'
出力には、通常の IAM ロールには存在しない SourceRoleTemplate が含まれていました。
{
"RoleName": "PowerUserRole",
"Arn": "arn:aws:iam::123456789012:role/PowerUserRole",
"SourceRoleTemplate": {
"TemplateArn": "arn:aws:iam::aws:role-template/iam.amazonaws.com/PowerUserRoleTemplate:1",
"TemplateMinorVersion": 0
}
}
信頼ポリシーと、アタッチされた管理ポリシーも取得しました。
aws iam get-role --role-name PowerUserRole --query 'Role.AssumeRolePolicyDocument'
aws iam list-attached-role-policies --role-name PowerUserRole
信頼ポリシーは Lambda のサービスプリンシパルによる sts:AssumeRole を許可していました。アタッチされていた管理ポリシーは arn:aws:iam::aws:policy/PowerUserAccess の1つだけでした。バージョンを指定して PowerUserAccess の内容を取得しました。
aws iam get-policy-version \
--policy-arn arn:aws:iam::aws:policy/PowerUserAccess \
--version-id v12
主な許可内容は次のステートメントです。
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
}
iam、organizations、account 以外のすべてのアクションが対象です。別のステートメントでは、この3サービスについてもサービスリンクロールの作成など一部のアクションを個別に許可していました。払い出された PowerUserRole は、最小権限に絞った Lambda 実行ロールではなく、広範な権限を持つロールでした。
AdministratorAccess をそのまま付与するよりは権限が限定されており、開発を始めるときの IAM 設定の手間を減らせます。ただし、あくまで着手を早めるための初期状態であり、本番利用に適した最小権限ではありません。
PowerUserRoleTemplate が使用されるのは Lambda だけではありません。ロールテンプレートの一覧を見ると、AWS Elastic Beanstalk、Amazon EventBridge、AWS Step Functions にも同じテンプレートが割り当てられていました。
ロールマネージャがすべてのサービスに PowerUserAccess を付与するわけではありません。Secrets Manager のシークレットローテーション用テンプレート AWSSecretsManagerRotationRoleTemplate:1 は、ローテーションに必要なアクションを条件付きで許可するインラインポリシーを定義していました。
参考: Secrets Manager のロールテンプレート
aws iam get-role-template-version \
--template-arn arn:aws:iam::aws:role-template/secretsmanager.amazonaws.com/AWSSecretsManagerRotationRoleTemplate:1 \
--region us-east-1
{
"RoleTemplateVersion": {
"TemplateArn": "arn:aws:iam::aws:role-template/secretsmanager.amazonaws.com/AWSSecretsManagerRotationRoleTemplate:1",
"TemplateName": "AWSSecretsManagerRotationRoleTemplate",
"TemplateVersionId": "AVTAZKAPJZG4PCYR454GW",
"Description": "Creates a role that allows AWS Secrets Manager to perform secret rotation by accessing and updating secret values",
"MajorVersion": 1,
"DefaultMinorVersion": 0,
"ManagedByType": "Service",
"ManagedByValue": "secretsmanager.amazonaws.com",
"Enabled": true,
"MinorVersion": 0,
"RoleNamePattern": "@{RoleName}",
"RolePathPattern": "/service-role/",
"RoleDescriptionPattern": "Allows AWS Secrets Manager to perform secret rotation by accessing and updating secret values",
"AssumeRolePolicyDocumentTemplate": {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SecretsManagerPrincipalAccess",
"Effect": "Allow",
"Principal": {
"Service": "secretsmanager.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "@{accountId}"
}
}
}
]
},
"InlinePolicyTemplates": [
{
"PolicyName": "SecretRotationPermissionPolicy",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRotationAccessGeneric",
"Effect": "Allow",
"Action": [
"secretsmanager:DescribeSecret",
"secretsmanager:GetSecretValue",
"secretsmanager:PutSecretValue",
"secretsmanager:UpdateSecretVersionStage"
],
"Resource": "arn:aws:secretsmanager:@{region}:@{accountId}:secret:*",
"Condition": {
"StringEquals": {
"secretsmanager:resource/Type": "@{resourceType}"
}
}
},
{
"Effect": "Allow",
"Sid": "AllowPasswordGenerationAccessAdmin",
"Action": [
"secretsmanager:GetRandomPassword"
],
"Resource": "*"
},
{
"@Enabled": "ADMIN_RESOURCE_ENABLED",
"Sid": "AllowRotationAccess",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:@{region}:@{accountId}:secret:*",
"Effect": "Allow",
"Condition": {
"StringEquals": {
"secretsmanager:resource/Type": "@{adminType}"
}
}
},
{
"@Enabled": "CMK_ENABLED",
"Sid": "KMSAccessForCustomerSecret",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKey"
],
"Resource": "@{kmsKeyArn}",
"Condition": {
"StringEquals": {
"kms:ViaService": "secretsmanager.@{region}.amazonaws.com"
}
}
}
]
}
}
],
"MaxSessionDuration": 3600,
"VersionEnabled": true,
"CreateTimestamp": "2026-07-09T15:27:27+00:00",
"UpdateTimestamp": "2026-07-09T15:27:27+00:00"
}
}
@{...} はロールの払い出し時に値が入るプレースホルダです。@Enabled を持つステートメントは、対応するパラメータが有効な場合だけ適用されます。出力からは ParametersDefinition（RoleName、accountId、region、resourceType、kmsKeyArn など8個のパラメータ定義）を省いています。
関数の実行
デフォルトコードを変更せずに、Lambda コンソールのテスト機能で関数を1回実行し、CloudWatch Logs で結果を確認しました。
aws logs tail /aws/lambda/test-iam-0813 \
--since 10m \
--region us-east-1
2026-08-13T05:02:19.257000+00:00 INIT_START Runtime Version: python:3.14.mainline.v59
2026-08-13T05:02:19.371000+00:00 START RequestId: 27c95d17-... Version: $LATEST
2026-08-13T05:02:19.388000+00:00 END RequestId: 27c95d17-...
2026-08-13T05:02:19.388000+00:00 REPORT RequestId: 27c95d17-... Duration: 2.13 ms Billed Duration: 112 ms
Memory Size: 128 MB Max Memory Used: 37 MB Init Duration: 109.34 ms
エラーなく実行が完了していました。
払い出されたロールが実行時に使われたかどうかは、RoleLastUsed に現れます。
aws iam get-role \
--role-name PowerUserRole \
--query 'Role.RoleLastUsed'
{
"LastUsedDate": "2026-08-13T05:02:21+00:00",
"Region": "us-east-1"
}
us-east-1 での利用日時が記録されていました。関数を実行した 05:02:19Z の2秒後です。払い出された PowerUserRole は、関数の実行ロールとして使用されていました。
作成後の実行ロール変更
関数作成時には実行ロールを指定しませんでしたが、作成後に基本設定を開くと、実行ロール欄には PowerUserRole が選択済みの状態で表示されていました。同じ欄に Create new role、Edit role、View role details in IAM も並んでおり、権限を絞ったロールへ変更できる状態でした。
留意したい点
本番から分離した開発アカウントで利用する
ロールマネージャはアカウント単位の設定であり、複数人が利用するアカウントでは全員に影響します。本番とは AWS アカウントを分け、実データや本番環境につながらないサンドボックスや開発用アカウントに限定して有効化するのが前提です。
PowerUserAccess は sts:AssumeRole を許可します。そのため、PowerUserRole から引き受けられる管理者相当のロールがあると、実質的な権限昇格が可能になります。引き受け先は同一アカウントに限らず、他のアカウントのロールも対象です。AdministratorAccess などの強い権限を持つロールについて、信頼ポリシーに PowerUserRole からの経路がないかを確認する必要があります。
PowerUserRole を割り当てている関数は、認証なしの関数 URL や API Gateway など、第三者から直接呼び出せる構成には適していません。依存パッケージや Lambda Layers に含まれるコードも同じ実行ロールで動くため、持ち込むコードは出所を確認できるものだけに絞ります。
本番投入前に関数専用ロールへ切り替える
ロールマネージャは、同じテンプレートから払い出すロールに同じ名前を使います。別の関数を作成しても、割り当てられるのは同じ PowerUserRole です。つまり関数ごとの権限分離ができません。しかも、あとからロールマネージャを無効化しても、作成済みのロールや関数への割り当てはそのまま残ります。AWS Security Blog でも、本番ワークロードではロールマネージャを無効化し、最小権限のロールで実行することを推奨しています。
共有された PowerUserRole 自体を編集すると、同じロールを利用するすべての関数に影響します。また、権限ポリシーや信頼ポリシーを変更すると、ロールマネージャの管理対象から外れ、以後のロールテンプレートの更新を受け取らなくなります。開発初期は PowerUserRole で動作を確認し、必要な権限を整理したあとに関数専用の実行ロールへ切り替えて再テストします。
本番の IaC では関数専用ロールを明示的に管理し、PowerUserRole や PowerUserAccess が指定されていた場合はデプロイを拒否する仕組みが有効です。
GuardDuty とコスト監視で異常に備える
PowerUserRole の誤用や侵害による不審な操作は GuardDuty で、意図しないリソース作成による費用の増加は Budgets とコスト異常検出のアラートで検知できます。ただし、いずれも通知のための仕組みであり、AWS API の実行や費用の発生を止めるものではありません。アカウント分離や実行ロールの最小権限化と組み合わせる前提の対策です。
まとめ
IAM ロールマネージャを有効にすると、Lambda の実行ロールを自分で用意せずに関数を作成できます。本番から切り離したサンドボックスや個人の開発用アカウントであれば、IAM 設定の手間を省いて検証を始められます。
無料プランのアカウントも候補になります。使えるサービスやインスタンスタイプに制限があり、料金もクレジット残高の範囲に収まるため、広い権限を渡したときの影響を小さく抑えられます。
一方、払い出された PowerUserRole は広範な権限を持つため、本番ワークロードには適していません。
SCP を使って組織単位でロールマネージャの利用を制御した検証結果は、次の記事で紹介予定です。
参考リンク
