AWS IAM Role Manager Guide: Setup, Roles, Controls

Quick answer

AWS IAM Role Manager is an optional account-level provisioning setting, not a new type of identity. In supported service consoles, it applies an AWS-managed role template and uses AcquireRole to create a matching IAM role or reuse one that already fits.

The resulting role is an ordinary IAM role. You can inspect, edit, or delete it, and CloudTrail records a creation as an AcquireRole management event. Role Manager does not bypass the caller’s permissions, prove least privilege, or delete roles when the account setting is disabled.

Where Role Manager works

As of the August 19 source check, AWS lists six supported service consoles:

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

AWS says service coverage will expand. Check the live directory before designing a standard that assumes a particular console or use case is supported.

Role Manager does not replace service-specific role creation that already exists. It adds one account setting and a template-based path for supported workflows, including some open-ended tasks whose final permissions AWS cannot know in advance.

Enable it with an owner and boundary

In the IAM console, go to Account settings and enable Role Manager. Enabling or disabling it requires iam:PutAccountProperties.

Before enabling it, record:

1. the accounts and organizational units in scope;
2. who can change the account setting;
3. which principals can create or reuse roles;
4. which service consoles and templates are permitted;
5. how created roles are inventoried and reviewed;
6. when development roles must be narrowed or retired.

Most AWS accounts have Role Manager disabled by default. AWS documents a separate behavior for accounts created through its new account experience, where the setting can be enabled by default and may require advanced-feature activation before it can be disabled.

Caller permissions still decide the result

Role Manager exposes AcquireRole, but AWS evaluates the IAM work performed on the caller’s behalf:

Outcome	Required actions
Reuse a matching role	iam:GetRole
Inspect the template	iam:GetRoleTemplateVersion
Create a new role	iam:CreateRole plus the template’s underlying policy actions
Attach a managed policy	iam:AttachRolePolicy
Add an inline policy	iam:PutRolePolicy

The precise actions vary by template. Retrieve the template version and review its trust and permissions policies before delegating access. A console button does not make a broad IAM grant safe for every user.

For the API and template mechanics, use the AcquireRole and role-template guide.

Use CloudTrail as creation evidence

AWS records a new role created through Role Manager as one AcquireRole event. The event identifies the caller, template ARN and version, replacement parameters, and returned role.

Keep at least:

• caller identity and session context;
• account, event time, and Region;
• template ARN, major version, and minor version;
• replacement parameters such as service and role name;
• resulting role ARN and name;
• linked service resource and accountable owner.

CloudTrail proves that the operation occurred. It does not prove that the template remained appropriate, the resource used every permission, or the role was later narrowed.

Control it across an organization

AWS documents SCP patterns that can:

• deny enabling Role Manager by restricting iam:PutAccountProperties for the RoleManager namespace;
• deny template-based creation using the iam:RoleTemplateARN context key;
• deny non-templated role creation while allowing the approved template path.

SCPs set the maximum permission boundary; they do not grant access by themselves. Identity policies still need to allow the intended operations. Test both an approved and denied case in a non-production account before applying an organization-wide rule.

Disabling is not cleanup

Disabling Role Manager stops the automatic path but does not delete or detach roles it already created. Resources keep their roles and continue operating.

Treat disablement and role remediation as separate changes:

1. inventory all roles with template references;
2. identify the attached resource and owner;
3. review trust and permissions;
4. narrow, replace, or retain with evidence;
5. test the workload and rollback;
6. remove only through normal change control.

The production least-privilege guide covers that transition.

Frequently asked questions

What is AWS IAM Role Manager?

It is an optional IAM account setting that lets supported AWS service consoles automatically create or reuse ordinary IAM roles from AWS-managed role templates.

Does Role Manager bypass a user’s IAM permissions?

No. AcquireRole evaluates the underlying IAM actions against the caller. Creating a role requires CreateRole and the policy-attachment actions used by the template; reusing a role requires GetRole.

Does disabling Role Manager delete its roles?

No. AWS says existing roles remain attached and continue working until an authorized owner changes or deletes them.

Official sources

• AWS IAM: Create roles automatically with Role Manager
• AWS IAM: Manage access to Role Manager
• AWS Security Blog: How Role Manager changes the starting point
• AWS announcement: IAM Role Manager

Source check: August 19, 2026. Recheck account defaults, supported consoles, template directory, permissions, SCP condition keys, and CloudTrail fields before enablement.