Control access across AWS accounts

An AWS account is more than a label. It is a boundary for authorization, billing, quotas, and operations. Separate production, security evidence, and development when they need different owners or blast radii. Tags help organize resources inside an account, but they do not create the same isolation.

AWS Organizations groups accounts into organizational units, or OUs. AWS Control Tower can establish and govern a landing zone. Neither service gives a workload permission to read a bucket or assume a role; IAM and resource policies still provide those positive grants.

For cross-account access, first choose the shape. Use a role when the caller needs a temporary bundle of permissions in another account. Use a resource policy when one supported resource can directly grant a narrow action to an external principal.

Name the owner of each boundary. A platform team may create accounts and OUs, a security team may own organization guardrails, and an application team may own workload roles. Separating those duties prevents one convenient administrator from silently controlling production, evidence, and the policies meant to protect both.

Account separation has an operating cost, so use it for a real boundary. Different data sensitivity, production authority, evidence ownership, or billing responsibility can justify another account. A new account is not useful merely because two resources have different names.

Cross-account role assumption checks two sides before creating a session. The caller needs permission to call sts:AssumeRole, and the target role must trust that caller. After assumption, the role’s permissions control the session’s actions.

Direct resource access follows the service’s resource-policy rules. Verify that the service supports a resource policy and which principal forms it accepts. The choice changes the audit principal, session behavior, and revocation point.

AWS KMS is a useful two-sided example. To use a key from another account, the key-owning account must authorize the external principal in the key policy, and the principal’s own account must grant the KMS action through IAM. One side alone is not enough. The data-service policy must also permit the intended data access.

Test the exact operation from the exact principal. A successful role assumption proves only that the session exists; it does not prove the session may read the resource. Likewise, a successful decrypt does not prove the role may administer the key or read every encrypted object.

Keep the access path narrow enough to revoke safely. Removing target-role trust stops new assumptions, while changing a resource policy removes that direct grant. Existing temporary sessions still follow their lifetime and applicable revocation behavior, so include session duration in the removal plan.

A service control policy, or SCP, sets the maximum permissions available to affected member-account principals. It never grants an action. If an SCP allows S3, an IAM or resource policy must still grant the specific S3 action. If an SCP denies an action, an IAM allow cannot restore it.

Attach a broad prohibition at an OU only when it should apply to every covered principal. If only roles created by developers need a limit, required permissions boundaries and controlled PassRole access may be narrower. SCPs also do not restrict principals in the management account, so keep routine workloads there to a minimum and protect organization administration separately.

Test a guardrail in a limited OU before wider rollout. Prove one action that must remain allowed, one that must be denied, and the management-account exception. A mistaken deny can disable every covered identity, so staged evidence is cheaper than emergency recovery.

Record who may attach, detach, or edit the SCP and who may move an account to another OU. A guardrail does not protect the organization if the same routine identity can simply remove its scope. Monitor those organization changes and keep recovery access deliberate.

Promote the policy only after the observations match its stated scope. If an allowed deployment action fails, repair the guardrail before widening it. If the prohibited action still succeeds, identify whether the principal, account, or management-account exception sits outside the SCP’s reach.