Multi-Account Architecture & AWS Organizations

Foundations You'll Need Today

How to Use This Curriculum

1. Why Multi-Account Architecture Is on the Exam

The SAP-C02 exam opens with Domain 1, Design Solutions for Organizational Complexity, and that domain is not really about any single service. It is about the question of how a large organization should be shaped on AWS, and the answer AWS has converged on over the last several years is that it should be shaped as many accounts rather than one. That conclusion is counterintuitive enough to candidates who learned AWS on a single account that the exam spends real question budget testing whether you have internalized it. A scenario that describes a company with a single production account, a shared IAM user directory, and a growing pile of resource-based policies is describing an architecture that has already failed in a way that is not yet visible, and the correct answer is almost always to restructure into accounts rather than to patch the existing account with more policies.

The architectural problem that multi-account solves is blast radius, and it solves it at a layer that no in-account control can reach. Within a single account, every principal that can create IAM policies can, in principle, escalate to full account administrator. A developer with permission to create a role and attach a policy can attach AdministratorAccess to that role and assume it. A compromised CI/CD credential with iam:PassRole and a broad enough set of service permissions can do the same. The only reliable boundary against this class of escalation is an account boundary, because crossing an account requires an explicit trust relationship that the target account controls. When you separate workloads into accounts, a compromise in one account is contained by the fact that the other accounts do not trust it. That containment is the primary reason the exam treats account separation as the default rather than as an advanced pattern.

The secondary reasons are quotas and billing. Service quotas are per-account, so a runaway workload in one account cannot exhaust the API rate limits or instance capacity that another account depends on. Consolidated billing through AWS Organizations aggregates all member accounts onto a single bill, which means volume discounts and Savings Plan commitments apply across the whole organization rather than per account, and it means the finance team has one place to look. Neither of these is as architecturally interesting as blast radius, but both show up in exam scenarios phrased around cost allocation or quota isolation, and both are consequences of the same structural decision.

The exam also tests the failure mode of getting this wrong in the other direction. An organization that creates an account per developer, or per microservice, or per environment without any grouping structure ends up with hundreds of accounts and no way to apply policy to them coherently. The Organizational Unit hierarchy is the mechanism that makes many accounts manageable, and a scenario that describes an unmanageable account sprawl is testing whether you reach for OUs as the organizing principle. The rest of this lesson is about how that hierarchy is built, what it constrains, and where it breaks.

2. How AWS Organizations Actually Works

AWS Organizations is a management layer that sits above individual accounts and provides three things: a hierarchy for grouping accounts, a consolidated billing relationship, and a policy attachment mechanism. The hierarchy is a tree. At the top is the organization root, which is not an account but a container. Beneath the root are Organizational Units, which can nest arbitrarily deep, and beneath the OUs are the member accounts themselves. Every account in the organization has exactly one parent, and the tree is the structure along which policies are inherited. The account that created the organization is the management account, sometimes called the root account or the payer account, and it holds a special position: it is the only account that can create and attach policies to the organization, and it is the only account that is exempt from those policies.

Consolidated billing is the mechanism that makes the organization financially coherent. When an account joins an organization, its charges roll up to the management account's bill, and the member account's own payment method is no longer used. This has a practical consequence that surprises people: the management account becomes financially responsible for every member account, which means a compromised or misconfigured member account can generate charges the management account must pay. It also means that Reserved Instance and Savings Plan discounts purchased in one account apply across the organization, and that the volume tiering for services like S3 is calculated on aggregate usage rather than per account. The exam occasionally tests whether you know that consolidated billing is the reason to use Organizations even when you do not need the policy features.

The policy attachment mechanism is the part that matters most for governance, and it is worth being precise about what Organizations itself provides versus what other services provide on top of it. Organizations natively supports Service Control Policies, which are the subject of the next day's material, and it supports tag policies and backup policies as organization-level policy types. It does not itself provide identity management, account provisioning automation, or compliance detection — those come from IAM Identity Center, Control Tower, and AWS Config respectively, all of which integrate with Organizations but are separate services. A common exam trap is a scenario that asks for centralized identity management and offers AWS Organizations as an answer; Organizations is the prerequisite that makes Identity Center's cross-account provisioning possible, but it is not the identity service.

Account creation and invitation are the two ways accounts enter an organization. An account created directly through Organizations is born inside the organization and is immediately subject to its policies. An existing standalone account can be invited and must accept the invitation, which is a deliberate friction point because joining an organization transfers billing control and subjects the account to policies it did not author. Once an account is a member, leaving the organization requires the management account to remove it, and a member account cannot unilaterally depart. That asymmetry is the structural reason Organizations is a governance tool rather than a convenience: the management account holds the power, and member accounts are along for the ride.

3. The Core Decision Boundary: How to Split Accounts

The single fork that most multi-account scenario questions hinge on is where the account boundaries go, and the answer is almost never "one account per team" or "one account per application." The organizing principle that AWS's own guidance converges on is to split by what needs a hard boundary, and then to group by what shares a lifecycle. The hard boundaries are security, billing, and blast radius. The shared lifecycles are environments and business units. An account boundary is expensive — it means separate IAM, separate VPCs unless you share them, separate service quotas, and a cross-account trust relationship for anything that needs to talk across it — so you want as few of them as the hard boundaries require, and you want the ones you have to be drawn where a compromise would otherwise spread.

The pattern that falls out of this is a small number of top-level OUs with distinct purposes. A Security OU holds the accounts that exist to observe and protect the rest of the organization: the log-archive account that aggregates CloudTrail and Config data, and the audit account that holds the security tooling and the read-only cross-account roles. These accounts are deliberately isolated because their value depends on workload teams not being able to modify them. An Infrastructure OU holds shared services: the network account that owns the Transit Gateway and the shared VPCs, the DNS account, and the account that runs centralized CI/CD. A Workloads OU holds the accounts that run actual applications, typically subdivided by environment (Prod, Staging, Dev) or by business unit, or both. A Sandbox OU holds accounts that exist for experimentation and are expected to be torn down and recreated.

The environment split within Workloads is the one candidates most often get wrong on the exam. The instinct is to put Dev, Staging, and Prod in the same account with different VPCs or different resource name prefixes, because that is how it is done in a single-account world. The correct answer is almost always separate accounts, because the boundary that matters is not network isolation — that is what VPCs and security groups are for — but permission isolation. A developer who can deploy to Dev should not be able to deploy to Prod, and the cleanest way to enforce that is to give them a role in the Dev account and no role in the Prod account. Doing it with IAM policies inside one account is possible but fragile, because every new policy is a chance to accidentally grant Prod access.

The pick-X-when rules that follow from this table are the ones to carry into the exam. Pick a separate account when the requirement is a boundary that cannot be crossed by an in-account administrator, when the requirement is independent service quotas, or when the requirement is separate cost attribution. Pick an OU when the requirement is to apply the same policy to a set of accounts. Pick a VPC or subnet when the requirement is network segmentation within a single trust domain. Pick an IAM role when the requirement is to grant a specific principal access to a specific resource. The exam frequently offers all four as options for a scenario that only one of them actually satisfies, and the discriminator is almost always whether the requirement says "even if an administrator in that account tries."

4. OU Design and the Tradeoffs of Each Structure

Once you have decided how many accounts you need, the next set of decisions is about how to arrange them in the OU tree, and the tradeoff is always between policy precision and policy maintenance. A flat structure — every account directly under the root — gives you the simplest possible tree and the coarsest possible policy control, because any policy you attach at the root applies to everything. A deep structure with many nested OUs gives you precise control, because you can attach a policy at exactly the level where it applies, but it costs you the cognitive overhead of remembering which policies are attached where and what the effective permission set is for any given account. The exam does not test your aesthetic preference here, but it does test whether you understand that inheritance means a policy attached high in the tree is organization-wide and cannot be relaxed from below.

The most common structural mistake is to organize the tree by team rather than by function. A tree with OUs named after departments looks natural to an organization chart, but it makes policy attachment awkward, because the policies you actually want to write are almost never department-specific. Region restrictions, service blocks, and logging requirements apply to categories of accounts — production, non-production, security, sandbox — not to the marketing team's accounts specifically. Organizing by function means a new policy is attached once at the right level and applies correctly to every account that should receive it. Organizing by team means the same policy has to be attached to each team's OU, and the day a team reorganizes, the policy attachment is wrong.

The second tradeoff is depth versus breadth. A tree that is three levels deep (root, environment OU, account) is easy to reason about and covers most organizations. A tree that is five levels deep (root, business unit, environment, application tier, account) gives finer control but makes it harder to answer the question "what policies apply to this account" without walking the whole path. The practical guidance is to add a level only when there is a policy that genuinely needs to attach at that level and nowhere else. If you cannot name the policy that justifies a level, the level is probably not earning its complexity.

The third tradeoff is how to handle accounts that do not fit the pattern. There is always at least one — an account with a regulatory requirement that conflicts with the standard region restriction, or an account that needs to run a service the rest of the organization blocks. The two options are to create a dedicated OU for the exception, which keeps the exception visible and auditable, or to attach an account-level policy that carves out the exception, which is more surgical but easier to forget. The exam tends to favor the dedicated OU because it makes the exception a first-class part of the structure rather than a hidden override, and because it means the exception can be reviewed as a unit rather than discovered by reading every account's attachments.

Finally, there is the question of how much of the tree to build up front. Building the full tree before you have accounts to put in it produces empty OUs that may not match how the organization actually evolves. Building it incrementally as accounts are needed produces a tree shaped by history rather than by design. The pragmatic middle is to build the top-level OUs that correspond to the hard boundaries — Security, Infrastructure, Workloads, Sandbox — on day one, and to add sub-OUs beneath Workloads only when there is a policy or a billing requirement that justifies them. That gives you a structure that is correct from the start without over-committing to a shape you will want to change.

5. Sizing, Limits, and Quotas

The limits that matter for Organizations are mostly generous, but a few of them shape real design decisions and the exam does test them. The headline number is that an organization can contain a large number of accounts — the default quota is in the thousands, and it can be raised — so account count is rarely the binding constraint. What is more likely to bind is the number of accounts you can create per day, which is a rate limit rather than a total limit, and which matters when you are provisioning a new business unit's worth of accounts through automation. If a scenario describes a bulk account creation that fails partway through, the cause is usually the creation rate limit rather than the total account quota.

Organizational Unit depth is limited, and the limit is deep enough that it is rarely hit in practice, but the exam does occasionally test whether you know that nesting is bounded. The more practically relevant limit is the number of policies that can be attached to a single target, which is what constrains how many guardrails you can stack on one OU. Because policies are intersected, a design that needs many guardrails on one OU will eventually hit the attachment limit, and the response is to consolidate policies rather than to restructure the tree. This is one of the reasons the deny-list posture is preferred: a single deny-list policy can express many guardrails, whereas an allow-list policy tends to need one policy per service.

Consolidated billing has its own limits, and the one worth knowing is that an account can belong to exactly one organization at a time. There is no way to have an account participate in two organizations' billing, which means a merger or acquisition requires a deliberate decision about which organization the acquired accounts join. The exam frames this as a scenario about integrating an acquired company, and the correct answer usually involves either inviting the acquired accounts into the existing organization or keeping them separate with a cross-account trust relationship, depending on whether the requirement is unified governance or preserved autonomy.

The management account deserves its own note because it is the one account whose position cannot be changed after the fact. It is the account that created the organization, and there is no supported operation to transfer that role to a different account. If the management account is compromised, the attacker has the ability to detach every policy in the organization, invite arbitrary accounts, and change the billing relationship. This is why the guidance to keep it workload-free is not a stylistic preference but a security requirement, and why the exam treats "move the workload out of the management account" as the correct answer to any scenario that describes workloads running there.

6. Failure Modes and What They Look Like in Production

The characteristic failure of a multi-account architecture is not an outage but a slow accumulation of exceptions that erode the boundaries the architecture was built to provide. It starts with a legitimate need — a team needs cross-account access to a shared resource — and it is solved with a trust relationship that is broader than the need required. Over time, the number of cross-account trusts grows, each one slightly wider than necessary, and the account boundaries that were supposed to contain a compromise become porous. The symptom is not visible in any single metric; it shows up in an access review as a list of roles that nobody can confidently say are still needed, and in an incident as a compromise that spreads further than the architecture diagram suggested it would.

The second failure mode is the orphaned account. An account is created for a project, the project ends, and the account is left running with its resources, its IAM users, and its trust relationships intact. Because it is no longer anyone's active responsibility, it does not receive the policy updates that the rest of the organization receives, and it becomes the weakest link. The diagnostic signal is an account that appears in the organization's account list but not in any team's ownership records, and the mitigation is a periodic review that either assigns an owner or closes the account. The exam frames this as a governance question rather than a technical one, and the correct answer usually involves tagging accounts with ownership metadata and reviewing untagged accounts.

The third failure mode is the policy that was correct when it was written and is wrong now. A region-restriction policy written when the organization operated in two regions becomes a blocker when a new region is approved, and the failure surfaces as an AccessDenied in a service that has nothing obviously to do with regions. The diagnostic move is to check the SCP chain before checking IAM, because the error message does not distinguish between the two layers. The mitigation is to treat organization-level policy changes as change-controlled events with a documented review cadence, so that policies are revisited when the organization's requirements change rather than when they cause an incident.

The fourth failure mode is the one that is hardest to detect because it looks like success: an organization that has grown to hundreds of accounts with no coherent OU structure. Every account is directly under the root, every policy is attached at the root, and the effective permission set is the same for every account in the organization. This is not a security failure in the sense of a breach, but it is a governance failure in the sense that the organization has all the cost of many accounts and none of the isolation benefit. The diagnostic signal is that a policy change intended for one category of accounts affects all of them, and the mitigation is to restructure the tree around the boundaries that actually matter.

7. The Operational and SRE Angle

From an SRE perspective, the multi-account structure is a blast-radius control, and the way to evaluate it is to ask what a single compromised credential can reach. In a well-structured organization, the answer is one account's resources plus whatever that account has been explicitly trusted with. In a poorly structured one, the answer is everything, because the trust relationships form a connected graph. The operational practice that keeps this honest is a periodic review of cross-account trust relationships, treated as a first-class inventory rather than as an incidental configuration detail. The review asks, for each trust, whether the granting account still needs it and whether the scope is still the minimum required.

Monitoring for multi-account problems is mostly about watching the organization's own control plane rather than watching workloads. The events worth alarming on are the ones that change the structure: CreateAccount, InviteAccountToOrganization, LeaveOrganization, AttachPolicy, DetachPolicy, and the account-level changes that move an account between OUs. These are low-frequency, high-consequence events, and a notification on each one gives the platform team a chance to catch a mistake before it becomes an incident. CloudTrail records them in the management account, and the practical pattern is a CloudWatch alarm or an EventBridge rule that routes them to a review channel.

The SLO implication of multi-account structure is indirect but real. Because service quotas are per-account, a workload that shares an account with a noisy neighbor can be throttled by that neighbor's activity, which shows up as latency or error-rate SLO breaches that have nothing to do with the workload's own code. Separating the noisy neighbor into its own account is a resilience measure as much as a governance one, and the exam does test this framing. The runbook shape that follows is: on an unexplained throttling incident, check whether the account is shared with other workloads before assuming the workload itself is at fault.

The other operational consideration is the cost of the structure itself. Every account has a baseline cost — the resources that exist in every account regardless of workload, such as the default VPC, the CloudTrail trail, and the Config recorder — and an organization with hundreds of accounts pays that baseline hundreds of times. This is rarely the dominant cost, but it is a real one, and it is the reason the guidance is to split accounts by hard boundaries rather than by every conceivable dimension. The exam occasionally frames a cost-optimization scenario around account consolidation, and the correct answer usually preserves the security and environment boundaries while consolidating accounts that were split for no structural reason.

8. Edge Cases and Exam Gotchas

The gotchas cluster around the same theme: the management account is special, and the boundaries are structural rather than policy-based. The first and most heavily tested gotcha is that the management account is exempt from Service Control Policies. Any scenario that asks you to constrain the management account with an SCP is testing whether you know it cannot be done, and the correct answer is to move the workload out of the management account rather than to try to constrain it. The second is that the management account cannot be changed after the organization is created, so a scenario that asks you to designate a different account as the payer is testing whether you know that is not a supported operation.

The third gotcha is the distinction between Organizations and the services that build on it. Organizations provides the hierarchy and the policy attachment mechanism; it does not provide identity management, account provisioning automation, or compliance detection. A scenario that asks for centralized SSO and offers Organizations as an option is testing whether you reach for IAM Identity Center instead. A scenario that asks for automated account provisioning and offers Organizations is testing whether you reach for Control Tower or AFT. The pattern is that Organizations is the prerequisite, not the solution.

The fourth gotcha is the direction of the trust relationship in cross-account access. When account A needs to access a resource in account B, the trust is established by account B granting access to a principal in account A, and the principal in account A must also have permission to assume the role or call the API. Both sides need a policy, and a scenario that describes access failing despite one side being configured correctly is testing whether you know both are required. The fifth is that consolidated billing does not imply consolidated permissions: joining an organization does not grant any account access to any other account's resources, and a scenario that assumes otherwise is testing whether you conflate the billing relationship with the trust relationship.

The sixth gotcha is the account creation rate limit, which shows up in scenarios about bulk provisioning. The seventh is that an account can belong to exactly one organization, which matters in merger scenarios. The eighth is that removing an account from an organization requires the management account to act, so a scenario that describes a member account trying to leave is testing whether you know it cannot. The ninth, and the one most often missed, is that the OU structure is not a security boundary in itself — it is a policy attachment point. Two accounts in different OUs with the same policies attached have the same effective permissions, and a scenario that assumes OU membership alone provides isolation is testing whether you understand that the isolation comes from the policies, not the tree.

9. Organizations vs. the Services It Gets Confused With

Organizations sits in a family of governance services that all look like "a way to manage many accounts," and the exam deliberately mixes them. The closest relative is AWS Control Tower, which is not a separate mechanism but a managed wrapper that provisions an Organizations structure and attaches a curated set of SCPs and Config rules to it. The distinction is that Organizations gives you the raw hierarchy and you decide what to attach, while Control Tower gives you an opinionated landing zone with guardrails already in place. A scenario that asks for a landing zone with minimal design effort is pointing at Control Tower; a scenario that asks for a custom hierarchy with specific policies is pointing at Organizations directly.

The second relative is IAM Identity Center, which provides centralized human access across the accounts in an organization. It depends on Organizations — it can only provision roles into accounts that are members — but it is a distinct service with its own configuration. The third is AWS RAM, which shares specific resources across accounts without merging their networks or their permissions. The fourth is AWS Config, which detects and reports on resource configuration but does not prevent anything. The fifth is the SCP itself, which is a policy type that Organizations supports rather than a separate service.

The pick-X-when rules that fall out of this table are the ones to carry into the exam. Pick Organizations when the requirement is the structural foundation: the hierarchy, the billing relationship, and the place where policies attach. Pick Control Tower when the requirement is a landing zone that is provisioned and maintained rather than hand-built. Pick IAM Identity Center when the requirement is human access across accounts. Pick RAM when the requirement is to share a specific resource without merging networks. Pick Config when the requirement is detection. Pick an SCP when the requirement is prevention. The exam frequently offers several of these for a scenario that only one satisfies, and the discriminator is usually whether the requirement is about structure, identity, resource sharing, detection, or prevention.

Hands-on Lab: Designing and Building an OU Hierarchy

Scenario Question Drills

Peek into Tomorrow

Sources