In AWS Organizations, what is the difference between the management account and a member account, and what does grouping accounts into organizational units (OUs) give you?
answer
- one payer, many workload accounts
- the account that created the organization
- folders of accounts, policies inherit down
- the payer itself is not restrictable
- policy attaches to a node, not a resource
basics
~20 sIn AWS Organizations one management account creates the organization, pays every bill and cannot be restricted by service control policies; the rest are member accounts holding workloads. OUs group accounts so one attached policy applies to all beneath.
solid answer
~50 sAn organization has exactly one management account — the account that created it. It owns the organization, invites or creates accounts, attaches organization policies, and is the payer for consolidated billing. Every other account is a member account, and that is where workloads live. The management account is special in a way that matters: service control policies do not restrict it, so an SCP that denies an action across the organization still leaves that action allowed there. That is the main reason the standard practice is to keep the management account empty of workloads. OUs are containers arranged in a tree beneath the organization root; you attach an SCP, tag policy or backup policy to an OU and every account below it inherits that policy, so you write one `Production` rule set instead of copying rules into each account.
code
bash · 4 linesaws organizations describe-organization
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-a1b2
aws organizations list-accounts-for-parent --parent-id ou-a1b2-abcd1234go deeper
Be able to say there is exactly one management account and many member accounts, that OUs are folders of accounts arranged in a tree, and that billing rolls up to the management account as the payer.
Explain inheritance concretely — a policy attached to an OU applies to every account beneath it, with no opt-out — and know the two feature sets, since SCPs only exist once all features are enabled.
Show that you know the management account is exempt from SCPs, and take the operational conclusion seriously: keep it free of workloads, keep its principal population tiny, and treat access to it as break-glass.
Own the argument for account granularity itself. An account is the strongest blast-radius, quota and billing boundary AWS offers, and you weigh that isolation against the real overhead of provisioning, connecting and governing many of them.
## What AWS Organizations actually is AWS Organizations is the layer that sits **above** individual AWS accounts. On its own an AWS account is an isolated universe: its own IAM principals, its own resource namespace, its own bill. Organizations lets you group many such accounts into one **organization** so they can be billed together, governed together, and enrolled together into org-aware services. An organization has three structural pieces: - **The root.** A single top node, created with the organization. It is not an account; it is the top of the OU tree. - **Organizational units (OUs).** Containers under the root that hold accounts and other OUs. Nesting is bounded to a handful of levels, and an OU holds accounts, not resources. - **Accounts.** One management account plus any number of member accounts. ## Management account vs member account The **management account** is whichever account called `CreateOrganization`. It is the only account that can create or invite member accounts, attach and detach organization policies, and enable trusted access for org-aware services. It is also the **payer**: all member-account usage lands on its bill. Because it holds that authority, it is deliberately exempt from the governance it applies to everyone else. **Service control policies do not restrict principals in the management account.** An `Effect: Deny` SCP attached to the root that blocks `s3:DeleteBucket` will block it everywhere in the organization except in the management account. The practical rule that falls out of this is: run no workloads there, keep the population of principals in it tiny, and treat access to it as break-glass. **Member accounts** are ordinary AWS accounts that happen to belong to the organization. Their principals — including each account's root user — are subject to every SCP on the path from the organization root down to the account. A member account can be moved between OUs, and moving it silently changes the policies that apply to it, which is a genuinely useful lever and a genuinely surprising outage source. ## Inheritance is the whole point of OUs Attachment happens at a node: the root, an OU, or a single account. Inheritance flows **downward and never stops early**. If an SCP is attached to a `Workloads` OU, every account in `Workloads` and in every OU nested under it is constrained by it. There is no "closest attachment wins" and no way for a child OU to opt out — a child can only ever be constrained further, never freed. That is why OU design is really policy design. The usual shape mirrors governance rather than the org chart: a `Security` OU for logging and audit accounts, an `Infrastructure` OU for shared networking and tooling, `Workloads` split into production and non-production, and a `Sandbox` OU with a loose ceiling for experiments. SCPs are not the only policy type that inherits. Organizations also supports **tag policies** (standardising tag keys and casing), **backup policies**, and **AI services opt-out policies**, all attached the same way. ## Consolidated billing One bill, paid by the management account, with usage from all member accounts aggregated. Aggregation is not just cosmetic: usage is pooled for tiered pricing, and Reserved Instance and Savings Plans discounts can be shared across the organization (a preference you can turn off if a team must be billed strictly on its own consumption). Each member account can still see its own costs; what it does not have is its own payment method. ## Feature sets An organization runs in one of two feature sets. **Consolidated billing only** gives you the shared bill and nothing else. **All features** additionally enables the policy types — including SCPs — plus trusted access and delegated administration for org-aware services. If SCPs seem to be missing, an organization stuck in consolidated-billing-only mode is the usual cause; upgrading requires the member accounts to accept a handshake. ## What Organizations is not It is not a sign-in system — human access across the accounts is layered on top separately. It is not a network: accounts in one organization have no connectivity to each other by default. And it is not a resource-sharing mechanism on its own; sharing resources across accounts is a separate service that merely *uses* the organization as its trust scope. ```bash aws organizations describe-organization aws organizations list-accounts ```
- What is the difference between the two Organizations feature sets, and why would that ever bite you?Consolidated billing only gives you the shared bill and nothing else; all features additionally enables the policy types, including SCPs, plus trusted access and delegated administration for org-aware services. If SCPs are simply unavailable in the console, an organization left in consolidated-billing-only mode is the usual reason. Upgrading requires each member account to accept a handshake, so it is not a unilateral flip.
- Can you swap which account is the management account of an existing organization?No — there is no in-place transfer. The management account cannot become a member of its own organization, so moving payer duties means standing up a new organization and moving accounts over one at a time by removing and re-inviting them. Policy attachments, OU structure and organization-level trails do not follow the accounts, so this is a migration project rather than a setting.
- If a policy is attached to a parent OU and a different one to a nested OU, which applies?Both. Inheritance never stops early and a child cannot opt out of an ancestor's policy — the effective governance is everything on the path from the root down to the account. A nested OU can only narrow what its parent already permits, which is why moving an account between OUs changes what it can do without touching a single IAM policy.
saying these in an interview costs you the question
- Says SCPs also restrict the management account
- Calls AWS Organizations a single sign-on product
- Thinks each member account gets its own separate bill
- Believes an OU connects accounts on the network
- Assumes a child OU can opt out of a parent's policy