The Cross-Account Role Pattern That Scales

Most cross-account access starts as bespoke and ends as a tangle. The pattern with consistent role naming, scoping, and trust relationships.

Naming

Cross-account roles are the backbone of multi-account AWS architecture. They allow workloads in one account to access resources in another without sharing static credentials. The pattern is powerful but easy to do badly; sloppy cross-account roles are one of the most common findings in AWS security audits.

What good naming looks like:

• RoleName format: purpose-sourceAccount.: A naming convention that includes the purpose and the source account makes the role inventory navigable. Example: BackupRole-prod-from-backup-account makes the relationship explicit.
• Predictable.: The convention is documented and applied consistently. New roles follow the convention; old roles are migrated when touched. The predictability makes the inventory parseable.
• Greppable.: The naming pattern lets the team search for related roles. "All roles assumed from the audit account" is a single grep against the role list. The discoverability makes audits and reviews efficient.
• Auditable.: The role name itself documents the trust relationship. An auditor reading the inventory can immediately see what each role is for and where it is assumed from. The audit conversation gets shorter.
• Versioned when needed.: Major changes to a role's purpose or scope produce a new role with a versioned name. The old role is deprecated; the new role replaces it. The deprecation is tracked.

Naming is one of those small disciplines that compounds. Good naming makes everything else easier; bad naming makes inventory management impossible at scale.

Scoping

The scope of cross-account roles determines the blast radius if the trust relationship is abused. Tight scoping limits damage; loose scoping (wildcards, overly broad permissions) amplifies it.

• Each role: minimum necessary permissions.: The role grants only the permissions actually needed for its purpose. Read-only where read-only is sufficient. Specific resources where specific resources are sufficient. The principle of least privilege applies.
• No wildcards on resources.: Resource ARN patterns avoid wildcards where possible. "arn:aws:s3:::backup-bucket-prod" not "arn:aws:s3:::*". The specific ARN limits the role's reach to what was intended.
• Time-bound where possible.: STS session durations are bounded. The role can be assumed for an hour or a few hours, not days. Short sessions limit the window during which a leaked credential can be used.
• STS sessions instead of permanent roles.: Where the use case allows, the role grants a session rather than persistent access. The session naturally expires; refreshing requires re-authentication. The pattern is more secure than long-lived persistent access.
• Periodic permission review.: The role's permissions are reviewed periodically. Permissions that are no longer needed are removed. CloudTrail data shows what the role actually used; permissions not used in the last quarter are candidates for removal.

Scoping is where the security value of the cross-account role pattern lives. Without tight scoping, the pattern produces wide attack surfaces.

Trust

The trust policy is what determines who can assume the role. The trust relationship is the boundary; getting it wrong opens the role to broader principals than intended.

• Trust policy specifies exact principal.: The policy names the specific principal (account ID, role ARN, user ARN) that can assume this role. Avoid trusting entire accounts unless the use case demands it; prefer specific roles or users.
• External ID for third-party access.: When a third-party service assumes the role (Datadog, PagerDuty, AWS partners), the trust includes an external ID. The external ID prevents confused-deputy attacks where an attacker impersonating a different customer's third-party setup tries to assume your role.
• Prevents confused-deputy attacks.: The external ID is the defense against confused-deputy. Without it, anyone who knows the role ARN and the third-party service identity could potentially assume the role. With it, the third party must provide the right ID, which only the legitimate customer knows.
• Reviewed annually.: Trust relationships drift over time. Roles trusted by accounts that no longer exist; trust relationships established for projects long completed. The annual review re-validates each trust.
• Trust relationships drift; review re-validates.: The drift is real; auditors look for it. The annual review produces evidence that the team is aware of every trust relationship and has confirmed it is still appropriate.

Cross-account role pattern is one of the most-used patterns in multi-account AWS. Done well, it provides safe inter-account access; done poorly, it produces wide attack surfaces. Nova AI Ops integrates with IAM data, surfaces unused roles and overly permissive trust relationships, and produces the inventory that the annual review starts from.