Role manager gets the headlines because it touches something engineers configure every week — Lambda execution roles, EventBridge rules, the usual suspects. But if you’re designing AWS identity architecture for a real organization, the more interesting story is what role manager looks like paired with its quieter sibling, account access manager, across a multi-account AWS Organizations setup. One handles machine identity. The other handles human identity. Wire both together and you’ve got a coherent least-privilege architecture instead of two separate features that happen to have shipped in the same month.
Two Different Identity Problems, One Architecture
Role manager solves the service-role problem: when you configure Lambda, EventBridge, or one of the other four supported consoles, it creates or reuses the IAM role that service needs to do its job. That’s identity for workloads — the roles that AWS services assume to act on your behalf.
Account access manager solves a different problem: identity for people. It streamlines how IAM roles get assigned to workforce users who need access across multiple AWS accounts — the exact scenario that turns into a spreadsheet nightmare the moment your AWS Organizations structure grows past a handful of accounts. An engineer needs read access to logs in prod and full access in staging. Finance needs billing visibility across every account in the org. Multiply by every role, every account, every person, and you understand why workforce access provisioning is usually where IAM governance quietly falls apart.
Why Treating Them Separately Is a Mistake
It’s tempting to file role manager under “developer experience” and account access manager under “IAM ops” and let two different teams own them independently. Don’t. Both features express the same architectural principle — permissions should be assigned from a known-good default, not built from scratch by whoever’s under the most deadline pressure that day — and treating them as unrelated means you end up with consistent service-role hygiene and inconsistent human-role hygiene, or vice versa. An architecture with airtight Lambda execution roles and a free-for-all workforce access model isn’t a least-privilege architecture. It’s a least-privilege architecture with a very specific, very human-shaped hole in it.
Designing AWS Identity Architecture for Multi-Account Orgs
In an AWS Organizations setup, the natural split looks like this: role manager operates inside each member account, scoping the service roles that workloads in that account actually need. Account access manager operates at the level of workforce access assignment, governing which humans — federated through AWS IAM Identity Center — can assume which roles in which accounts. The two meet at the permission boundary: a workforce user assumes a role that was itself built, or reused, by role manager, or by your own scoped equivalent for accounts where you’ve kept role manager off.
For accounts under strict change control — production, anything in scope for a compliance framework — you’ll likely want role manager’s automatic creation disabled and a deliberate, reviewed role-provisioning process instead, while still relying on account access manager to keep the assignment of who can reach that account consistent and auditable. For dev and sandbox accounts, running both in automatic mode reduces friction without meaningfully raising risk, since blast radius in those accounts is already contained by design.
Keeping Service Roles and Workforce Roles From Colliding
One practical risk in mixed environments: a workforce user with broad cross-account access assuming a role that also happens to have a role-manager-created trust relationship to a service. Audit your trust policies specifically for this — a role’s trust policy principal should name exactly who or what can assume it, and it’s worth periodically confirming that service-facing roles aren’t also reachable by human principals through an overly broad account access manager assignment.
# Pull the trust policy for a role-manager-created role and confirm
# only the intended service principal can assume it
aws iam get-role \
--role-name lambda-role-manager-execution \
--query "Role.AssumeRolePolicyDocument"
# Cross-check: find roles whose trust policy includes an AWS principal
# (a user, role, or account) rather than only a service principal
aws iam list-roles \
--query "Roles[?AssumeRolePolicyDocument.Statement[?Principal.AWS]].RoleName" \
--output tableThat second query flags any role whose trust policy includes an AWS principal rather than only an AWS service principal — a quick way to spot service roles that have accidentally become assumable by people.
Tagging and Naming as the Connective Tissue
Because role manager and account access manager operate at different layers, your naming and tagging convention is what makes the combined architecture legible instead of two disconnected feature adoptions. Tag role-manager-created roles distinctly — a ManagedBy=IAMRoleManager tag, for instance — so you can query them as a set, separate from custom roles and from anything account access manager touches. That distinction matters the first time someone asks “show me every role AWS created automatically versus every role a human wrote,” which is exactly the question an auditor, or an incident responder at 2 AM, is going to ask. AWS’s own Security Blog is worth watching as both features mature past launch.
The Payoff: One Coherent Least-Privilege Story
Paired correctly, role manager and account access manager give you an identity architecture where both halves of the access equation — what your workloads can do, and what your people can do — start from a scoped, documented default instead of an accumulated pile of exceptions. That’s not a compliance checkbox. It’s the difference between an incident response process that starts with “let’s check the two systems that govern all access” and one that starts with “let’s hope someone remembers how this got set up.” Keep an eye on AWS What’s New for how both tools expand beyond their launch-day scope.
At Enkompass (enkompass.net), this is our home turf. We design multi-account AWS Organizations identity architectures where service roles and workforce access actually tell the same least-privilege story. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.