この記事について
- AWS 公式が公表している週刊 AWS やアップデート情報の中から、ネットワークリソース関連の情報を集約して把握するため、Claude を活用してサマリーを生成・出力しています。
- 週刊 AWS および AWS の最新アップデートを継続的にキャッチアップする習慣をつけるため。
- 各記事に対する感想は、自身で記載して投稿しています。
- タイトルに【備忘】と付けているのは、後から見返せるよう記録として残しておきたいためです。
はじめに
2026年8月10日週の AWS アップデートを確認しましたが、ネットワーク関連（VPC、NAT Gateway、Transit Gateway、ELB、Direct Connect 等）の専用アップデートは確認できませんでした。
今週は IAM や S3、Billing といったセキュリティ・管理系のアップデートが中心でした。
ネットワーク関連アップデート
2026年8月10日週のネットワーク関連（VPC / NAT Gateway / Transit Gateway / ELB / Direct Connect 等）のアップデートは確認できませんでした。
その他注目リリース
- 週刊AWS – 2026/8/10週: AWS IAM がロールマネージャーを提供開始し、IAM ロールの自動セットアップが可能になるなど、セキュリティ・アクセス管理まわりのアップデートが集中した週。
- 週刊生成AI with AWS – 2026年8月10日週: Kiro が公開から 1 周年を迎え、エージェント統合や Kiro Crew のオープンソース公開など生成 AI 開発ツール周辺の動きが加速している。
まとめと感想
AWS IAM が、IAM ロールを自動的にセットアップする Role Manager を提供開始
IaC（Terraform）で IAM ポリシーやロールを書くとき、AI のレビューだけでなくこういうツールもあれば、自分が見落としていたところにもっと気づけて便利なのにと前々から思っていました。
今回のサービスについて、かなり気になりましたので書き出してみます。
出来ること
- リソース作成フロー（例: Lambda 関数の作成、EventBridge ルールの作成）の中で、AWS管理の role template（ロールテンプレート） を適用してロールを払い出す
- 払い出しは 新API
AcquireRoleを経由し、テンプレートに合致する既存ロールがあれば再利用し、なければテンプレートから新規作成する - 作成されるのは通常のIAMロールであり、ユーザーが完全に制御できる（閲覧・編集・削除可能）
- 各ロールには「どのテンプレート由来か」が記録される
- CloudTrail には role manager によるロール作成が
AcquireRoleイベントとして記録される - 有効化 / 無効化はいつでも可能
- 無効化しても、それまでに作成されたロールは削除されない
- 追加料金なし
出典：ロールマネージャーを使用してロールを自動的に作成する
：ロールマネージャーへのアクセスを管理する
：How AWS IAM role manager rethinks the starting point for IAM roles
対応サービス
- AWS Backup
- AWS CloudFormation
- Amazon CloudWatch
- AWS Elastic Beanstalk
- Amazon EventBridge
- AWS Lambda
- Amazon SageMaker Unified Studio
- AWS Secrets Manager
- AWS Step Functions
AWS Lambda は業務で使う頻度が高く、そのたびに Lambda 実行ロールへ IAMポリシーを付与しようとして「このポリシーは本当に必要だったかな？」と悩み調べて、
「あ、やっぱり必要だった」「今回このケースでは不要だった」となることが自分の経験では多々あり、このツールの登場で特にPoCの際には効果があると思いました。
仕組み
基本フロー
-
role manager は「呼び出し元ユーザー自身の IAM 権限」でロールを作成する（role manager 専用権限ではない）
- テンプレートが行うアクション（
iam:CreateRole/iam:AttachRolePolicy/iam:PutRolePolicy等）の権限がユーザーに無ければ、コンソールは不足権限を通知し、ロールは作成されない
- テンプレートが行うアクション（
- リソース作成フローで role manager が提示するロールを受け入れるための追加操作は不要
- 別のロールを使いたい場合は「既存ロールを選択」または「手動で新規作成」を選ぶ
ロールテンプレート
- テンプレートは信頼ポリシー＋許可ポリシー＋ARNを持つ設計図
- **バージョンは不変（immutable）**で、AWS が更新する際は既存版を書き換えず新バージョンを発行する
- テンプレートはパラメータ（
RoleName、bucketName、accountId等）を受け取り、role manager がコンソールで自動補完する - テンプレート内容は
iam:GetRoleTemplateVersionで確認できる - 代表的なテンプレートと用途:
| サービス | テンプレート（ARN 末尾） | 性質 |
|---|---|---|
| AWS Lambda / Amazon EventBridge / Amazon CloudWatch / AWS CloudFormation / AWS Elastic Beanstalk |
iam.amazonaws.com/PowerUserRoleTemplate:1（5 サービス共通の同一 ARN） |
事前に必要権限を確定できない用途向けの広範な権限テンプレート。AWSServiceName と RoleName をパラメータに取り、信頼ポリシーの Principal を当該サービスに設定する。AWS Security Blog は Lambda 実行ロールのケースについて、AWS 管理ポリシー PowerUserAccess（iam:* / organizations:* / account:* を除く全サービスへのフルアクセス）がアタッチされると明記。同一 ARN のため他 4 サービスでも同等に広い権限になると見込まれるが、正確な内容は iam:GetRoleTemplateVersion で確認すること |
| AWS Backup | backup.amazonaws.com/AWSBackupDefaultServiceRoleTemplate:1 |
用途が定まったタスク向けで権限は絞り込み済み |
| AWS Secrets Manager | secretsmanager.amazonaws.com/AWSSecretsManagerRotationRoleTemplate:1 |
ローテーション用途に絞り込み |
| Amazon CloudWatch（Synthetics / RUM / Metric Streams / Scheduled Query 等） |
synthetics.amazonaws.com/... ほか各専用 ARN |
用途別に絞り込み |
AWS Step Functions / Amazon SageMaker Unified Studio も対応サービスだが、前者は 2026-09-06 時点の「Role template directory」に個別テンプレート行の記載がなく、後者は
AmazonSageMaker*IAMPermissiveExecutionRoleTemplateを使用する。
-
定義タスク（用途が明確）はタスクに必要なアクションのみ付与
- オープンエンドなタスク（自前コード実行等）は広い権限を付与し、後から絞り込む前提
ユースケース
| シーン | role manager が有効なケース |
|---|---|
| PoC / 検証環境の立ち上げ | IAM の事前知識なしで Lambda / EventBridge 等をすぐ動かしたいときに、ロール設計を後回しにできる |
| サンドボックス / 開発アカウント | ロール作成の反復作業を省き、開発スピードを優先できる |
| IAM に不慣れなチーム | 信頼ポリシーや権限の初期設計をテンプレートに任せることができる |
| 自前コード実行（Lambda 等）で必要権限が不明 | まず PowerUserAccess で動かし、後から IAM Access Analyzer で絞り込みができる |
| ロール作成の統制ポイントを 1 つにしたい | アカウントレベルの RoleManager/Enabled ＋ Organizations SCP で一元管理できる |
本番ワークロードでの推奨（Security Blog）
本番投入前に role manager を無効化し、作成済みロールを最小権限に絞り込みを行う。
開発 / サンドボックスでは有効のまま運用する。
メリット・デメリット
メリット
-
立ち上げが数分で完了できる
- ロール作成のためのコンテキストスイッチが不要であること
- 作成物は通常の IAM ロールであること
- 既存の可視化・監査ツール（IAM コンソール、CloudTrail、Access Analyzer）がそのまま使えること
-
重複ロールの抑制ができる
-
AcquireRoleが合致する既存ロールを再利用できること
-
-
監査性
- 各ロールにテンプレート参照が記録され、CloudTrail に
AcquireRoleイベントが残る（誰が・どのテンプレートで・どのロールを作成したか）
- 各ロールにテンプレート参照が記録され、CloudTrail に
-
統制が容易
- アカウントレベルのオン/オフ＋ SCP（
iam:PutAccountProperties拒否、iam:RoleTemplateARN条件キーによるテンプレート作成の拒否/限定）
- アカウントレベルのオン/オフ＋ SCP（
- 権限をユーザー自身の IAM 権限で評価するため、権限昇格を招かない（テンプレート実行に必要な権限が無ければ作成されない）
デメリット／注意するべきこと
-
オープンエンド用途は広めの権限（
PowerUserAccess）から始まるため、最小権限化は利用者の責任で後追い実施が必要であること -
PowerUserAccessの 30 日アクティビティを基に Access Analyzer が推奨を出すため、四半期バッチ等の低頻度権限が「未使用」と誤判定されうること- 適用前レビュー必須であること
- コンソール操作限定。CLI / SDK / IaC からのリソース作成には介入しないこと（＝コンソールと IaC で作成経路が分かれると構成が二重管理になりやすい）
-
ドリフトの原因になりうること
- IaC 管理アカウントでコンソール作成を許すと、IaC 管理外のロールが増えること
- ロールを編集した時点で role manager 管理から外れ、テンプレートのバージョン更新が届かなくなること
- 「新しい AWS エクスペリエンス」で有効化されたアカウントは、advanced features を有効化するまで無効化できないこと
IaC との連携
業務では、Terraform でAWSリソースを構築しているので、下記の観点で AI と壁打ちしてみました。
Q1：自動セットアップが、IaC で作成した「IAMロール」を上書きする可能性はあるか？
結論
既存ロールの内容が上書きされることはない。
公式ドキュメント上、Role Manager の動作は次の２つだけで、既存ロールのポリシーは信頼ポリシーを変更する動作は定義されていないとのこと。
- テンプレートに合致する既存ロールの「再利用」(
AcquireRoleが当該ロールのARNを返すのみ。ポリシーは変更しない) - テンプレートからの新規ロール作成
根拠と補足
| 論点 | 公式ドキュメントの記載 | 実務上の意味 |
|---|---|---|
| 発火条件 | 「対応サービスコンソールでリソースを作成するとき」にロールを払い出す(User Guide 「How role manager works.」) | Terraform / CDK / CloudFormation(CDK経由) / CLI からのリソース作成では role manager は介入しない。IaC apply が既存ロールを差し替えられることはない |
| 既存ロールへの作用 | 「合致する既存ロールがあれば AcquireRole はそれを返す」「新規作成時のみ ias:CreateRole が必要」(User Guide「Manage access to role manager」) |
再利用時はロールを参照するだけ。ポリシーの再適用・マージは記載なし |
| APIレベルの動作 |
AquireRole API Reference は「role template からロールを作成する」と定義。エラーに NameConflict("the resulting role name conflicts with an existing role in the account", 409) と EtityAlreadyExists(409) を規定 |
既存ロールと同名になる場合、AquireRole はエラーで停止する。既存ロールを上書き・改変する経路は API仕様上存在しない |
| 「合致」の判定 | ロールにはテンプレート参照が記録され、GetRole がそれを返す。 role manager は「テンプレートに合致するロール」を再利用(サービスによる挙動が異なる) |
手動 / IaC で作ったロールはテンプレート参照を持たないため、通常は「合致」せず再利用対象にならない。再利用された場合もロール内容は不変 |
これらから「上書きリスク」ではなく「ドリフトリスク」として捉えることとなる。
具体的な例としては下記を挙げている。
- 開発者がコンソールでリソースを作成 → role manager が IaC 管理外のロールを新規作成 → tfstate / スタックに存在しないロールが増える
- IaC で「明示的にロールを指定して」リソースを作る限り、そのリソースには IaC 私的のロールが付く(role manager は介入しない)
IaC 管理アカウントでの推奨:
Q2：IaC は最小限のリソースのみ構築し、role manager 生成リソースを後からインポートするのが最適な手順か
結論
標準手順としては推奨しない
IaC を「あるべき状態の唯一のソース」に保つ原則に反し、次の摩擦が生じるとのこと。
| 「後からインポート」方式の問題点 | 根拠 |
|---|---|
role manager はオープンエンド用途で PowerUserAccess を付与する。そのままインポートすると広すぎる権限を IaC に固定化してしまい、結局あとで絞り込みが必要 |
Security Blog「Run code that calls other AWS services」 |
|
ロールを編集した時点で role manager 管理対象から外れる。 IaC 管理下に置くには結局ポリシーを自前定義することになり、テンプレートを使う利点が消える |
IAM User Guide「After you change a role's policies or trust policies, role manager no longer manages that role」 |
| テンプレートはバージョン不変・自動更新なし。 インポート後は AWS 側改善が反映されない |
IAM User Guide「Template versions are immutable」 |
| コンソール作成に依存するため、CI/CD パイプラインで完結しない（誰かがコンソールを触る前提の運用になる） | IAM User Guide「role manager is available in select AWS service consoles」 |
| インポート対象（ロール本体＋アタッチされた管理ポリシー参照＋信頼ポリシー）の状態管理が煩雑 | 一般的な IaC インポート運用 |
推奨手順（IaC 中心の場合）:
結論から導き出される手順としては下記で進めた方が最適
- role manager は本番アカウントで無効化（＋ SCP で強制）
- IaC 側で必要最小限のリソースを定義し、ロールも IaC で明示定義してリソースにアタッチする
- 最小権限ポリシーの雛形が欲しい場合は IAM Access Analyzer のポリシー生成（CloudTrail アクティビティからの生成） を使い、その出力を IaC のポリシー定義に落とし込む（role manager 経由で作らせてからインポートするより、最初から IaC に取り込める）
- どうしても role manager で先に作られてしまったロールがある場合のみ、例外的な取り込みとして:
- CloudTrail の
AcquireRoleイベントで対象ロールと由来テンプレートを特定 -
iam:GetRole/GetRoleTemplateVersionで信頼ポリシー・権限を確認 - IaC にロール定義を新規記述（
PowerUserAccess等の広い権限は最小権限へ書き換え） -
terraform import/ CloudFormation リソースインポート / CDK import で取り込み、以後は IaC 管理 - 取り込み後、tfstate / スタックとの差分（drift）がないことを確認
- CloudTrail の
この手順で進めると、環境ごとに手順を用意するなど運用管理が煩雑になるうえ、場合によっては既存環境を破壊しかねないリスクもあり、不安を覚えます。
結局のところ、PoC 段階や sandbox 環境で仕様と突き合わせつつ最小権限のロールをまず作り、その後に Role Manager を有効化して本当に必要なポリシーを洗い出していく方が良いと感じた。
出典
- Apply least-privilege permissions to a role created automatically（IAM User Guide）
- Overview of role templates（IAM User Guide）
- Create roles automatically with role manager（IAM User Guide）
-
AcquireRole（IAM API Reference） —「Errors」（
NameConflict/EntityAlreadyExists） - AWS Security Blog