Multi-Account Governance
Explore how to identify and resolve permission denials that affect multiple AWS accounts by understanding organization-level controls such as Service Control Policies, permission boundaries, and Identity Center permission sets. This lesson guides you through systematic troubleshooting and remediation steps to maintain secure and compliant multi-account environments in AWS.
Yesterday, the role could do almost anything. Today the same API call fails everywhere, in every account it touches, and nothing in that account's own IAM policy has changed. That mismatch, a symptom too consistent to be a local misconfiguration, is the first clue that the real cause sits above the account boundary entirely.
Here's the shape of it. A role that has been acting like an administrator across several AWS accounts now fails the same API call everywhere, and CloudTrail records AccessDenied for actions that were working yesterday. Because the blast radius crosses accounts and regions, IAM policy in a single account is the least likely root cause here, and organization-level controls need to be proven or ruled out first.
The hypotheses get ordered by what can deny permissions above the account boundary, working downward toward account-local causes from there. A practical ordering is Service Control Policy (SCP) or Control Tower guardrail, then permissions boundary, then Identity Center permission set or session policy, then the account's IAM policies and resource policies.
Where the deny can come from
When the same request fails across multiple accounts, the governance surfaces that can influence many accounts at once are where attention belongs. AWS ...