The new AWS experience removes two pieces of permission setup that often interrupt an early build. First, a project owner can now invite another person with an emailed invite, instead of having to set up an IAM user or IAM Identity Center. Second, when you create a resource using a supported AWS service, IAM role manager can automatically set up the IAM role for you so that your project resources can talk to each other.
Those actions involve different identities. Project access authorizes the person doing the work. An IAM role authorizes the service or application that runs afterward.
If you created your account through the new AWS experience, role manager is already turned on. When you create a supported resource, such as a Lambda function, AWS creates or reuses the role it needs and attaches it automatically.
Share a project with collaborators
A project owner can share access in two ways: invite someone from theTeam page and choose one or more projects, or open a specific project and invite them from its Members area. An invitation from the Team page does not automatically share every project the owner has; access applies only to the selected projects. After accepting, the team member has admin access to the resources and services available in those projects, including the ability to create access controls for services and applications. They cannot perform owner-only team-management, project, root, or financial actions. If you need to customize a team member’s access instead of granting project admin access, you must first activate advanced AWS features. For more details about sharing projects and team member access, see Invite team members to collaborate in AWS Settings.
To see the invitation process in action, watch Invite Your Teammate to Your AWS Project.
How role manager works
An IAM role defines what an AWS service is allowed to access and do. Setting one up usually means defining which service can assume the role, choosing what that service is allowed to do, and attaching the role to the resource.
IAM role manager automates that setup. When you create a resource in one of the supported services, role manager creates a role for it or reuses one that already fits. It then attaches the role as part of the same workflow, so you do not have to stop and set it up separately in IAM.
For accounts created through the new AWS experience, role manager is enabled by default. You cannot disable it until the account owner activates advanced AWS features.
This restriction is enforced by an AWS-managed service control policy (SCP). In the new experience, AWS manages the SCPs and resource control policies (RCPs) that protect your projects' preconfigured defaults, so you do not set up or edit these guardrails. For details, see Managed policies for your organization.
After advanced features are activated, you can manage role manager from Account settings in the IAM console.
How role manager sets up a Lambda execution role
Lambda is a useful example because AWS cannot know ahead of time which services your code will call. With role manager enabled, creating a function automatically attaches an execution role that the code can use immediately. You can narrow that role later, once you know what the function actually needs.
Because those permissions are unknown at creation time, role manager starts the role with the AWS managed PowerUserAccess policy. This gives the function broad access to AWS services, but it does not allow the function to manage IAM, AWS Organizations, or account settings. The role's trust policy allows only Lambda to assume it.
After the function is created, open its Configuration tab and choose Permissions. The Execution role panel shows the PowerUserRole that role manager attached.
Follow the role link to IAM. On the role's Permissions tab, choose PowerUserAccess to inspect the AWS managed policy and the access it grants.
Roles created by role manager are standard IAM roles, so you can inspect their trust policies and permissions, edit them, or delete them. Each role records the AWS-managed template it came from, which lets you identify roles created by role manager. AWS CloudTrail records each role's creation.
Refine permissions before production
Least privilege means giving a workload only the actions and resource access it needs. Role manager's PowerUserAccess policy is useful while you are still discovering those needs, but it is intentionally broader than most production functions require.
Use IAM Access Analyzer policy generation to help refine the role's permissions toward least privilege. Editing the role removes it from role manager's control and makes it a standard role that you manage.
After activating advanced AWS features, you can disable role manager without affecting existing applications or removing their roles. Existing roles stay in place, but new resources use the standard service or IAM role-creation workflows.
Conclusion
Role manager automates the initial IAM role setup for supported AWS services. It creates or reuses a role and attaches it while you create the resource, but the result remains a standard IAM role that you can inspect and control.
Together with AWS-managed project sharing, this reduces the access setup required for both collaborators and the services they build. Before production, review how the workload actually behaves and use IAM Access Analyzer policy generation to replace broad permissions with a more focused policy.
To get started, create a resource in a supported service. In accounts created through the new AWS experience, role manager is already enabled. For more information about managing roles yourself, see IAM role creation.
Top comments (0)