AWS IAM role manager shipped on 12 August 2026 attaching PowerUserAccess to four of six consoles

Summary. AWS IAM role manager became generally available on 12 August 2026 in every commercial Region except GovCloud (US) and China. It creates IAM roles for you inside six service consoles with no approval step. For four of those six, the template it applies is PowerUserRoleTemplate, which attaches the AWS managed policy PowerUserAccess: full access to every AWS service except IAM, Organizations and account settings. The announcement says you can "enable or disable role manager at any time"; the user guide says accounts created with the new AWS experience have it enabled by default and "cannot be disabled until you activate advanced features". And the SCP AWS publishes to lock an organisation onto role manager denies iam:GetRoleTemplateVersion unconditionally, which breaks the role-reuse path the policy exists to enforce. The production warning lives only in a blog post.

What shipped

From the What's New post, dated 12 August 2026: "role manager, a capability in AWS Identity and Access Management (IAM) that automatically sets up the IAM roles your AWS services need. When you set up a supported service in the console, role manager creates a default role on your behalf, or reuses one that already exists in your account if it already matches the required permissions."

The user guide names the six consoles exactly: AWS Elastic Beanstalk, Amazon EventBridge, AWS Lambda, Amazon SageMaker Unified Studio, AWS Secrets Manager and AWS Step Functions. The announcement said "6 AWS service consoles at launch, including AWS Lambda and Amazon EventBridge" without listing them.

There is no price. Role manager is an account property toggled through PutAccountProperties with the key RoleManager/Enabled, not a per-Region setting.

The template table is the story

The role template directory publishes which template each console gets. Four of the seven listed entries point at the same template.

AWS is direct about why. The security blog explains: "Because the permissions your code needs aren't known up front, role manager attaches the AWS managed policy PowerUserAccess to the role. PowerUserAccess grants access to AWS services so your function can call what it needs. By design, it doesn't grant permission to manage IAM, AWS Organizations, or account settings. The template also configures the role to trust only the Lambda service."

PowerUserAccess is a real managed policy with a published document, last edited 12 February 2026, currently at version v12. Its statement is a NotAction deny-list: "Effect": "Allow", "NotAction": ["iam:*", "organizations:*", "account:*"], "Resource": "*". Everything else in AWS is allowed on every resource.

The user guide states the trade-off plainly: "A template for a defined task grants only the actions that task needs. A template for open-ended work, such as running your own code, grants broad access to AWS APIs so you can build without granting access to each service yourself." And elsewhere: "For some roles, such as those for compute resources or cloud infrastructure management, it creates roles with broad permissions."

There is no approval step

The user guide: "When role manager is enabled, it provides roles appropriate to the service and the resource as part of the relevant console workflow. Supported service consoles will indicate when role manager is available. No additional action is required to accept the role that role manager provides. For example, when you create an AWS Lambda function in the console, Lambda uses role manager to create the function's execution role by default."

A developer clicking through the Lambda console gets a PowerUserAccess execution role without ever seeing the words PowerUserAccess. The role appears in IAM as a standard role, tagged with the template it came from, and both GetRole and ListRoles return that template reference. That tagging is the one thing that makes cleanup tractable.

Role manager cannot escalate a caller's privileges. It "creates the role using your own IAM permissions, not a separate role-manager permission", so a user without iam:CreateRole and iam:AttachRolePolicy gets an error rather than a role. The risk is not escalation. It is that anyone who already holds those permissions now creates PowerUserAccess roles by default instead of by decision.

The default-on contradiction

The announcement says: "You can enable or disable role manager at any time, as well as inspect the AWS-managed templates that role manager deploys on your behalf."

The user guide carries a Note that says otherwise: "For most AWS accounts, role manager is disabled by default. But if you created your account using our new AWS experience, role manager is enabled by default and cannot be disabled until you activate advanced features."

"At any time" is false for exactly the accounts most exposed: brand-new ones, where it is on before anyone has read the template table. AWS softens this with a free analyzer, but only for that population: "After you activate advanced features and disable role manager, AWS provides an unused access analyzer at no additional cost for 90 days."

Disabling does not clean up. "Roles created by role manager are not deleted when you disable role manager."

AWS's own lockdown SCP breaks role reuse

This is the sharpest defect, and it is a three-page trail.

The user guide publishes a copy-paste SCP under the heading "Block role creation except through role manager". It denies seven actions when "Null": {"iam:RoleTemplateARN": true} — that is, whenever the role-template context key is absent. The seven include iam:GetRoleTemplateVersion.

The IAM condition-key reference defines where that key is populated: "When an AWS service acquires a role from a role template, the role template ARN is included as a context key in the authorization checks for CreateRole, TagRole, PutRolePolicy, AttachRolePolicy, PutRolePermissionsBoundary, and GetRole." Six actions. GetRoleTemplateVersion is not among them, and the Service Authorization Reference confirms the same six independently.

So on GetRoleTemplateVersion the key is never present, the Null test is always true, and the deny always fires. The security blog then tells you why that hurts: "When AcquireRole reuses an existing role instead of creating one, it needs only iam:GetRole and iam:GetRoleTemplateVersion."

An organisation that applies AWS's published policy verbatim blocks the reuse path and forces a new role on every console workflow, against a hard cap of 1,000 roles per account by default.

Two more places the docs disagree

The API reference for AcquireRole describes creation only: "Creates an IAM role from the specified role template." Its error list includes NameConflict at HTTP 409 — "the resulting role name conflicts with an existing role in the account" — and EntityAlreadyExists, also 409. The word "reuse" does not appear on the page, while the announcement and user guide both describe reuse as normal behaviour.

The two pages also disagree on what reuse costs in permissions. The user guide: "If a role that matches the template already exists in the account, AcquireRole returns that role. This requires the iam:GetRole permission." One permission. The blog: "it needs only iam:GetRole and iam:GetRoleTemplateVersion." Two.

The quota that bites during cleanup

IAM raised the default managed policies per role from 10 to 20 on 19 August 2026, seven days after role manager shipped, with a Service Quotas ceiling of 25. That announcement covers "all commercial AWS Regions, AWS GovCloud (US) and China Regions" — a wider footprint than role manager itself, which excludes GovCloud and China.

The relevant IAM limits, all confirmed from the quota tables:

The cap collides with the remediation flow AWS points you at: "IAM limits the number of managed policies that you can attach to a role. If applying the recommendation would exceed that limit, the console notifies you and does not apply the change." Replacing one broad policy with several narrow ones can fail on a role that is already close to 20.

And the recommendation itself has a short memory: "The recommendation is based on the last 30 days of activity. A permission that the resource uses infrequently on a longer time horizon, such as for a quarterly job, can appear as unused." Anything running on a quarterly or annual cycle will be recommended away.

Three tools, no guidance on which to use

Role manager's pages send you to the unused access analyzer. The "Prepare for least-privilege permissions" page they link to sends you to IAM Access Analyzer policy generation instead, which is a different feature: it "reviews your AWS CloudTrail logs and generates a policy template", needs an existing service role, and requires that you "specify the CloudTrail trail that is logging events for the account before you can generate a policy".

A third option shipped on 18 August 2026: IAM Policy Autopilot gained Terraform plan file support. That is not an AWS-run service. Per the announcement, "IAM Policy Autopilot is an open source tool... available at no additional cost and runs on your own machine", and it produces policies that "reference specific resource ARNs rather than wildcards, when possible". The string "autopilot" appears zero times in the IAM User Guide table of contents. Three overlapping tools, documented in three places that do not reference each other, and no page says which to use when. Our note on IAM Policy Autopilot and Terraform plan files covers that third path in detail.

Audit coverage is one event, and it is good

"When role manager creates a role, AWS CloudTrail records the creation as a single AcquireRole event. The event shows who called the operation, the role template and parameter values that were used, and the role that was created." The published sample event carries "eventName": "AcquireRole", "eventSource": "iam.amazonaws.com", "readOnly": false, and a templateArn of arn:aws:iam::aws:role-template/iam.amazonaws.com/PowerUserRoleTemplate:1.

One event name, with the template ARN inline, makes detection straightforward. Alarm on AcquireRole where templateArn contains PowerUserRoleTemplate, in production accounts, today.

What to do

Check whether role manager is on. Accounts created through the new AWS experience have it enabled and cannot turn it off until advanced features are activated. Read the template directory before deciding, because four of the six consoles resolve to PowerUserAccess.

Follow the blog's advice, which the user guide never gives: "In sandbox or development accounts, keeping role manager enabled saves time. For production workloads, disable role manager and refine the roles it created to least privilege before going live."

If you apply the published lockdown SCP, remove iam:GetRoleTemplateVersion from the deny list first, or you will force role creation on every workflow and burn through the 1,000-role default. And treat the 30-day recommendation window as a floor, not an answer, for anything that runs less often than monthly.

The honest read: role manager fixes a real problem, which is that developers paste AdministratorAccess when role creation blocks them. Trading AdministratorAccess for PowerUserAccess is a genuine improvement. Calling the result a least-privilege story is not.

FAQ

How eCorpIT can help

Our senior engineering teams run IAM permission reviews for organisations moving workloads onto AWS, including the role-template audit and CloudTrail detection described above. This work sits alongside our DevOps services and our analysis of the IAM managed-policy-per-role cap. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified, and we design AWS accounts aligned with DPDP Act 2023 requirements for Indian deployments. Talk to us via /contact-us/.

References

1. AWS IAM now provides role manager to set up IAM roles automatically, AWS What's New, 12 August 2026

1. How AWS IAM role manager rethinks the starting point for IAM roles, AWS Security Blog, 12 August 2026

1. IAM role manager, AWS IAM User Guide

1. Enable and use role manager

1. Role manager and least-privilege permissions

1. IAM role templates

1. PowerUserAccess, AWS Managed Policy Reference

1. IAM and AWS STS quotas

1. IAM condition keys reference

1. Actions, resources and condition keys for AWS Identity and Access Management

1. AcquireRole, IAM API Reference

1. PutAccountProperties, IAM API Reference

1. IAM increases default quota for managed policies per role, AWS What's New, 19 August 2026

1. IAM Policy Autopilot now supports Terraform plan files, AWS What's New, 18 August 2026

1. IAM Access Analyzer policy generation

1. Prepare for least-privilege permissions, IAM User Guide

1. AWS Identity and Access Management endpoints and quotas, AWS General Reference

Last updated: 22 August 2026.