Multi-Account Access and Governance

Three different jobs, three different tools

Once a company runs more than one AWS account, three needs appear at the same time and get confused with one another: giving people access, building and running the accounts, and capping what anyone can do. Naming the job first is what makes the tool choice obvious.

AWS Organizations can manage multiple accounts and apply permissions guardrails at the organization, organizational unit, or account level. IAM Identity Center can centrally manage workforce access to multiple AWS accounts.

The guardrail level matters as much as the guardrail itself. AWS Organizations can apply a ceiling at three levels:

• the whole organization,
• an organizational unit grouping accounts,
• a single account.

That range is why a permission ceiling can be narrow or company-wide without changing mechanism. Classify the requirement as identity assignment, environment orchestration, or a permission ceiling before you pick anything, and the rest of this topic falls into place.

Control Tower as the orchestration layer

AWS Control Tower sets up and governs a multi-account environment by orchestrating AWS Organizations, AWS Service Catalog, and IAM Identity Center.

Read that sentence twice, because it explains what Control Tower is not: it is not a replacement for those services. It drives them. Anything the underlying services can do stays available for a team that wants to extend the setup by hand.

What Control Tower produces is a landing zone. A Control Tower landing zone is a multi-account environment based on security and compliance best practices.

It is the foundation, not a single setting: the accounts, the organizational structure, and the governance applied to them. Three near misses are worth ruling out now:

• A landing zone is not one identity policy handing every administrator access everywhere.
• It is not a directory instance scoped to isolated applications in one account.
• It is not a temporary role session used to reach a single account.

Those are all narrower objects. The landing zone is the environment they would live inside.

Provisioning and oversight

Two Control Tower features are constantly mixed up because both deal with accounts. One creates them, the other watches them.

Control Tower Account Factory standardizes and automates the provisioning of new accounts from configurable templates. Instead of a person clicking through account setup and hoping the result matches the last one, a template produces the same shape every time.

The Control Tower dashboard provides central oversight of provisioned accounts, enabled controls, and noncompliant resources. It is the place to see what exists and what is out of line.

The distinction matters in scenario questions because the wrong feature is always plausible. The dashboard cannot issue credentials to workforce users, define how much permission an account may have, or build a trust relationship between two accounts. It reports. Likewise, Account Factory does not monitor anything after the account exists; it standardizes how the account came to be.

Controls keep the environment governed

Provisioning an account well is a one-time act. Keeping it in line is continuous, and that is what controls are for. Control Tower controls provide ongoing governance and can be preventive, detective, or proactive.

Controls also do practical housekeeping that teams otherwise script themselves: Control Tower can apply controls that help create and preserve security logs and required cross-account access permissions. Logging that survives and cross-account permissions that stay in place are governance outcomes, not one-off tasks.

A service control policy is a ceiling, never a grant

This is the single most misread idea in multi-account design. An SCP centrally defines the maximum available permissions for IAM users and roles in member accounts. And immediately: an SCP does not grant permissions; an identity-based or resource-based policy must grant the requested access.

A ceiling with nothing underneath it gives nobody anything. Access still has to be granted somewhere.

Effective permissions are the intersection of the applicable SCP and resource control policy limits with permissions granted by identity-based and resource-based policies. Intersection is the operative word: a request needs a positive grant and room under every applicable ceiling.

That makes permission diagnosis a two-step routine rather than a hunt:

1. Is the action granted? Look at the identity-based or resource-based policy.
2. Is the action still within every ceiling? Look at each applicable organization-level limit.

Both steps must come back yes. If the grant is missing, no ceiling can supply it. If a ceiling excludes the action, no grant can push past it.

Who the ceiling reaches

Scope is the second half of the mechanism, and it has one asymmetry worth memorizing. SCPs affect member accounts, including delegated administrator accounts, but do not affect users or roles in the management account.

A delegated administrator sounds privileged, and it is — but it is still a member account, so the ceiling applies to it. The management account is the exception, and the only one.

One prerequisite completes the picture: SCPs are available only when an organization has all features enabled. Without that, the mechanism is not on the table at all.

Diagnosing a blocked action

Put the two rules together and a common support ticket answers itself. An administrator attaches AdministratorAccess inside a member account, and the action still fails because an inherited ceiling denies it.

Nothing is broken. The grant is present, the ceiling excludes the action, and the intersection is empty. A broad identity policy is still an identity policy: it cannot lift a maximum defined above the account. Nor does the request migrate anywhere — the management account's exemption applies to identities in that account, not to work performed elsewhere.

The fix is to change the ceiling, or to accept it. It is never to grant harder.

Choosing the mechanism

The two selections at the end of this topic are short and worth holding verbatim.

Use AWS Control Tower when the requirement is to establish and operate a governed landing zone with account provisioning and oversight. Use an SCP when the requirement is to set a maximum-permissions guardrail across an organization, organizational unit, or member account.

The deciding factor is how much of the operating layer the requirement actually asks for. A request for a ceiling and nothing else does not justify a landing zone, an account-provisioning workflow, or a dashboard.

When the requirement combines standardized account creation, continuous visibility, company-wide governance controls, and the ability to keep extending the AWS services underneath, that combination points to Control Tower, because it orchestrates AWS Organizations, AWS Service Catalog, and IAM Identity Center rather than replacing them.

Key takeaways

• Name the job first: identity assignment, environment orchestration, or permission ceiling.
• Control Tower orchestrates: it sets up and governs a multi-account environment on top of AWS Organizations, AWS Service Catalog, and IAM Identity Center.
• Know its parts: a landing zone is the governed environment, Account Factory provisions accounts from templates, the dashboard gives oversight, and controls govern continuously as preventive, detective, or proactive rules.
• A ceiling grants nothing: maximum permissions are defined for member-account identities, and access still requires an identity-based or resource-based grant, with effective permissions being the intersection.
• Mind the scope: member accounts including delegated administrators are affected, management-account identities are not, and the mechanism requires all organization features enabled.