LEARN. PRACTICE. GROW.Concept and mechanism
A multi-account architecture needs to distinguish who can grant access and which boundaries still apply. An AWS Organizations SCP establishes permission boundaries in member accounts; an Allow in that policy does not itself grant an action to a role. An applicable Deny can block an operation even when the role has an IAM Allow. The management account is outside SCP scope and needs its own controls. Do not confuse federated authentication with unrestricted authorization. For cross-account KMS key use, check both the key owner policy and the external principal IAM policy, alongside other boundaries.
Guided application
In a recovery rehearsal, start with the effective principal, action, resource, and error context. If object reading works but kms:Decrypt fails, do not conclude compute capacity is missing. Follow the authorization chain and change only what is approved. For central evidence, an organization trail can prevent member administrators from deleting that trail. For common configuration, service-managed StackSets can follow new accounts in an OU. Also define exit behavior: retaining a stack when its account leaves the target leaves existing resources outside that StackSet management. Handover should identify who takes responsibility for configuration, cost, and resource review.
The recovery account can read the backup, but the key remains in another account. Review must include data and cryptographic authorization.
Common pitfalls
SCP as a grant; global administration as diagnosis; stack retention as automatic maintenance; landing zone as compliance proof.
Related topics: Hybrid networking, DNS, and segmentation · Resilience, state, and releases
Check both sides of cross-account relationships and control lifecycles.
Reference: Service control policies · SAP-C02