IAM role and user ARNs look deceptively simple next to something like a Lambda ARN — no region, and the resource segment is just a type keyword and a name. The part that actually trips people up is the optional path: AWS lets you nest roles and users under a path prefix the same way you’d nest files in folders, and getting that path segment positioned correctly (between the type keyword and the name, with exactly one slash on each side) is where hand-typed IAM ARNs most often go wrong. IAM Role/User ARN Generator builds the ARN from four fields — account id, a role-vs-user toggle, an optional path, and a name — so the path always lands in the right place regardless of how you type it.
IAM is a global AWS service, so unlike Lambda or EC2, its ARNs never carry a region — the field between the third and fourth colon is always empty: arn:aws:iam::123456789012:role/my-role. The account id is still required, though, since every role and user belongs to exactly one AWS account. The tool’s form reflects that reality directly: there’s an account id field, but no region field at all, with a short note explaining why rather than leaving you to wonder if something is missing.
The role-vs-user choice is a toggle rather than a free-text field on purpose. The resource type segment in a real IAM ARN has to be exactly role or exactly user, lowercase, with no room for a typo like Role or Roles silently producing a broken ARN — a toggle makes that mistake structurally impossible. The optional path field is the piece most generators skip: AWS itself creates plenty of roles under paths, most visibly service-linked roles under aws-service-role/... and console-created service roles under service-role/..., and organizations that use IAM paths to group roles by team or environment need that segment to show up correctly in every ARN they hand-build. Type the path with or without leading or trailing slashes — service-role, /service-role, or service-role/ all normalize to the same result — and the tool inserts exactly one slash on each side, so role/service-role/my-lambda-role comes out right whether you were careful about slashes or not.
Leave the path blank — the common case for most manually created roles and users — and you get the simple two-segment resource: role/my-role or user/jdoe. Nested paths work the same way: a path of org/team-a produces user/org/team-a/jdoe, preserving the full hierarchy.
After building, the ARN runs through the same structural validator shared across this entire tool family: partition, service, and — since IAM has no region — a check that the region field really is empty, plus the standard 12-digit account id format check. This is deliberately scoped to roles and users, which share an identical ARN shape; IAM groups use the same pattern with group/ in place of role/ or user/ but aren’t part of this form’s toggle, since conflating three resource types in one two-way switch would undercut the whole point of making the type field foolproof.
A Load sample button fills in a realistic account id, role type, path, and name so you can see the nested-path form immediately; Clear resets everything. As with every tool here, the account id and any role or user names you type never leave your browser — construction and validation both happen entirely client-side.