Lesson 254 · AWS Learning Path

AWS 254: AWS Organizations

Anil Jalela · Published Mar 6, 2026 · 12 min read

Why this matters to an architect

An AWS account is a strong boundary for identity, quotas, billing records, blast radius, and service configuration. AWS Organizations lets an enterprise arrange many accounts into a governed hierarchy, apply central guardrails and service configurations, integrate trusted AWS services, delegate operations, and receive consolidated billing.

Organizations does not replace IAM, networking, observability, security operations, or account-level configuration. It supplies an enterprise control plane above accounts. A good architect knows what each organization control can enforce, which principals/resources it excludes, how inheritance works, and how to recover from a bad root-level change.

Outcomes

By the end, you can:

• explain organizations, management/member accounts, administrative root, organizational units (OUs), accounts, parents, and policies;
• distinguish the all-features and consolidated-billing-only feature sets;
• design an OU hierarchy around policy differences and account lifecycle rather than an org chart alone;
• compare SCPs, RCPs, tag, backup, AI opt-out, and current declarative service policies;
• predict authorization and declarative-policy inheritance without claiming that a policy grants access;
• distinguish trusted access, service-linked roles, delegated administrators, and ordinary IAM delegation;
• plan account creation, invitation, movement, suspension, closure, removal, and migration safely;
• explain consolidated billing, discounts, commitments, credits, and ownership boundaries;
• diagnose governance failures using Organizations, CloudTrail, service, account, and billing evidence.

History and the control-plane idea

AWS Organizations entered preview in November 2016 and became generally available on February 27, 2017. It introduced hierarchical OUs, account creation/invitation, consolidated billing, and service control policies. Since then, AWS has added trusted-service integrations, delegated administration, resource control policies (RCPs), and declarative policies that centrally configure service behavior.

The hierarchy is global rather than a workload-Region tree:

organization
└── administrative root (r-xxxx)
    ├── management account
    ├── Security OU
    │   ├── LogArchive account
    │   └── SecurityTooling account
    ├── Infrastructure OU
    ├── Workloads OU
    │   ├── NonProduction OU
    │   └── Production OU
    ├── Sandbox OU
    ├── PolicyStaging OU
    └── Suspended OU

Do not confuse the administrative root container with an AWS account's root user, or the organization management account with either one. Older material may call the management account the “master account”; use current terminology.

Core objects and hard boundaries

An account move changes inherited controls immediately enough to require change planning. A nested OU inherits from the root and every ancestor plus direct attachments. Design OUs around common controls and lifecycle - for example production, sandbox, policy staging, quarantine - not merely current reporting lines.

Feature sets: all features versus consolidated billing

All features provides consolidated billing plus policies, trusted AWS service integrations, delegated administration, and central governance. It is the normal enterprise target.

A legacy consolidated billing only organization groups payment and usage but cannot use the advanced governance features. Enabling all features is an organization migration: invited member accounts may need to approve, organization-created accounts are treated differently, and AWSServiceRoleForOrganizations must exist. Inventory handshakes, account ownership, unavailable owners, and rollback constraints before starting.

Do not create an organization casually in a personal learning account. An account can belong to only one organization at a time; invitations, billing responsibility, account-age constraints, and standalone-account requirements can complicate reversal.

Management account: protect the unguarded control plane

The management account can manage organization policies/integrations and is responsible for member-account charges. SCPs do not constrain its users or roles, and RCPs do not protect its resources. Keep business workloads and normal security tooling out of it; use it only for operations that must run there. Protect root credentials with independent MFA and recovery contacts, tightly limit workforce access, log all actions, and use dedicated management-account permission sets.

Delegate supported services and routine governance to member accounts. Delegation reduces exposure but does not transfer every management-account-only operation. A delegated administrator may possess organization-wide power through its service, so isolate, monitor, and review it.

AWS now recommends a root SCP that denies unauthorized organizations:LeaveOrganization and account:CloseAccount. Organizations created in the console after July 10, 2026 receive this default security control automatically; older organizations and those created via API/CLI/CloudFormation require explicit review. This SCP protects member accounts, not the management account.

Authorization policies: SCPs and RCPs

Neither SCPs nor RCPs grants permission.

• SCPs are principal-centric maximums. They limit what IAM users/roles and root users in member accounts can do, whether accessing organization or external resources. They do not affect management-account principals or service-linked roles.
• RCPs are resource-centric maximums. They restrict which principals - including external principals - can access supported resources in member accounts. They do not protect management-account resources.

An IAM allow still must survive every applicable SCP on the path; resource access must also survive applicable RCPs, resource policies, and service-specific policy. Explicit deny wins. If using an allow-list SCP strategy, an allow for the action must exist at every level from root through each OU to the account. Detaching the AWS-managed full-access baseline before replacement can unintentionally block everything in the affected path.

SCP examples must account for global services, service-linked roles, recovery, KMS, root-only tasks, AWS Support, and new Regions/services. Test denies in a policy-staging OU with representative roles and automated positive/negative cases before wider attachment. Do not attach an untested deny directly to the root.

RCPs can protect supported resources from organization-external identities even when a resource policy is accidentally broad. Confirm service/resource support and service-principal exceptions. They complement rather than replace bucket/key/queue policies.

Declarative and management policies

Declarative policies merge through inheritance operators into an effective policy. Depending on type, parents can assign values, append/remove elements, or restrict what children may override. Unlike SCP/RCP authorization calculations, supported effective declarative policies can be viewed for an account/OU.

Current policy families include:

Availability, exact names, services, Regions, syntax, and quotas evolve. Read the current policy-type page before design. “Attached” does not mean “effective and valid”: inspect the effective policy, service-side deployment/status, unsupported resources, errors, and a behavior test. Tag policies do not magically tag existing resources and enforcement support is service/resource specific. Backup policies require valid selections, vaults, roles, and service operation evidence.

Some declarative/management policies can affect the management account even though SCPs/RCPs do not. Never generalize the management-account exception across all policy types.

Trusted access, service-linked roles, and delegated administration

Trusted access authorizes a supported AWS service to perform organization-wide tasks and request service-linked roles in member accounts. It is not a generic permission for every service and it is not the same as assigning a delegated administrator.

Service-linked roles contain AWS-defined permissions for a specific service. SCPs do not restrict them. Enabling trusted access can create roles/configuration asynchronously across accounts, so verify service deployment status rather than assuming one successful API call completed the fleet.

Delegated administration registers one or more member accounts, where supported, to operate that integrated service. Each service defines how many delegates, what they can do, and what remains management-account-only. A generic Organizations delegated administrator capability also has its own permissions and constraints; do not infer one service's model from another.

Use the integrated service's console/API to enable or disable trusted access when AWS recommends it, so the service can create or clean up resources correctly. Before disabling, inventory delegated admins, service-linked roles, aggregators, data stores, recorders, standards, policies, and member configuration. DisableAWSServiceAccess alone can strand service resources or break central security visibility.

Account creation, invitation, and access

You can create a member account or invite an existing account. Creation is asynchronous: poll DescribeCreateAccountStatus, record failure reason, then bootstrap identity, security contacts, logging, configuration, budgets, baseline roles, tags, and OU placement. Account email addresses must be unique and should use a durable enterprise routing strategy rather than one employee's mailbox.

Organization-created accounts commonly receive an OrganizationAccountAccessRole (or specified access role) for management-account access. Invited accounts do not automatically receive that role. Treat it as privileged cross-account access, control and review it, and remember that removing an account does not automatically delete such IAM roles.

Invitations and feature-set changes use handshakes with expiry and authorized accept/decline paths. Verify account ownership before accepting; joining changes payer, policy inheritance, discount/credit behavior, trusted-service reach, and potentially data governance.

Account state and lifecycle

Use the State field - not the retired Status field. AWS retired Status on September 9, 2026. Current account states are:

Closure is not immediate resource deletion or cost erasure. Inventory retention, commitments, Marketplace/private offers, domains, logs, legal holds, support, encryption keys, root email/recovery, and restoration deadlines. A suspended/quarantine OU is a governance workflow, not the AWS-generated SUSPENDED billing/account state.

Removing a member does not close it. It becomes standalone, loses organization policies/trusted-service governance and consolidated payer coverage, and assumes its own new charges. Before removal it needs verified contacts, payment method, and support-plan selection; organization-created accounts also have a minimum age before removal. Revoke old organization access roles and replace logging/security/billing dependencies. Account migration between organizations includes a standalone gap unless a supported process says otherwise.

Consolidated billing and FinOps boundaries

Organizations itself and consolidated billing have no additional charge, but the management account pays member charges. Consolidation combines eligible usage for volume tiers and can share Reserved Instance/Savings Plans discounts and credits according to current preferences and eligibility. It does not merge account resources, quotas, IAM, or data.

Commitment ownership and benefit allocation differ. The account that bought a Savings Plan or reservation retains the financial commitment; leaving/removing accounts or changing sharing preferences can alter benefit application and raise costs. Free Tier, credits, tax, seller of record, Marketplace agreements, support, and billing transfer each have specific rules. Model the exact month boundary and use Cost and Usage Reports/cost allocation rather than assuming the member's displayed charge equals the organization's economic cost.

Newer billing transfer can place payment of an organization's consolidated bill under an external billing account while security/governance remains with the source organization; discount calculations remain bounded by each Organizations organization. Do not confuse payer delegation with merging governance trees.

Change workflow and evidence

For any organization-wide change:

1. State requirement, owner, target root/OU/accounts, and affected principals/resources.
2. Inventory current hierarchy, attachments, effective policies, delegated administrators, and trusted access.
3. Model inheritance and exceptions, including management account/service-linked roles.
4. Validate syntax and service support; peer review.
5. Deploy to a policy-staging OU with representative disposable accounts.
6. Run allowed, forbidden, break-glass, service-linked-role, billing/security, and rollback tests.
7. Roll out in small batches; watch CloudTrail and service deployment status.
8. Confirm target state and record rollback evidence.

CloudTrail records Organizations API actions such as policy changes, account moves, trusted-access changes, and handshakes. Correlate with service-specific logs, billing data, and effective configuration. A Console tree screenshot cannot prove policy behavior.

Practical lab

Download the AWS254 Organizations governance pack. It contains:

• ORGANIZATION_DESIGN_WORKBOOK.md;
• SUPPLIED_ORGANIZATIONS_CASES.md with six failures;
• POLICY_INHERITANCE_MATRIX.md;
• TRUSTED_ACCESS_AND_ACCOUNT_LIFECYCLE.md;
• ANSWER_DIRECTIONS.md, opened after independent analysis.

Design Security, Infrastructure, Workloads, Sandbox, PolicyStaging, and Suspended OUs. Give every account a purpose, owner, root-email pattern, contacts, baseline, guardrails, delegated services, billing owner, migration/closure path, and evidence. No organization needs to be created.

Read-only CLI evidence

Organizations is a global control plane. Run only with authorized management/delegated read access:

aws sts get-caller-identity
aws organizations describe-organization
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-REDACTED
aws organizations list-accounts \
  --query 'Accounts[].{Name:Name,Id:Id,State:State,Joined:JoinedTimestamp,Method:JoinedMethod}'
aws organizations list-policies --filter SERVICE_CONTROL_POLICY
aws organizations list-policies --filter RESOURCE_CONTROL_POLICY
aws organizations list-aws-service-access-for-organization
aws organizations list-delegated-administrators

Pagination matters: SDK/CLI scripts must retrieve every page. Redact account IDs, names, emails, OU/policy IDs, organization ID, and business structure. list-policies does not prove attachment or effect; follow with target/parent/attachment/effective-policy queries appropriate to that type.

Troubleshooting matrix

Cost, quotas, and cleanup

Organizations has no additional charge, but integrated services, logging, Config, Backup storage, security products, data transfer, support, and operational tooling do. Account and policy quotas, attachment limits, account-creation concurrency, invitation limits, and service-policy support change; verify current Service Quotas/docs and request increases early.

The supplied lab creates nothing. Do not “clean up” a real organization by deleting OUs or policies. For an approved sandbox, detach/move only after modeling inherited control changes; disable integrations through service guidance; remove delegated admins/dependencies; close or remove accounts only with owners, billing, data retention, and recovery approved; then prove hierarchy, policies, access, service configuration, and bill state.

Knowledge check

1. How do administrative root, root user, and management account differ?
2. Why is all-features mode required for advanced governance?
3. Why should OU design follow control/lifecycle differences rather than only departments?
4. What does an SCP limit, and what principals does it not affect?
5. How does an RCP differ, and why does neither policy grant access?
6. Why can a declarative policy affect the management account while an SCP cannot?
7. How do trusted access, service-linked role, and delegated administrator differ?
8. Why can disabling trusted access directly leave an unsafe or broken service state?
9. What replaced account Status, and what are the five states?
10. Why is removing an account different from closing it?
11. What must be prepared before an account becomes standalone?
12. How can an account move change security immediately?
13. What billing benefits and liabilities are shared, and what remains account-scoped?
14. Why is a policy-staging OU a required safety control?

Lesson acceptance

Pass requires a complete hierarchy and account inventory; management-account isolation; correct feature-set decision; SCP/RCP and declarative inheritance calculations; six supplied diagnoses; trusted-access/delegated-admin change plan; current State lifecycle handling; invitation/create/move/remove/close controls; consolidated billing and commitment-impact analysis; positive/negative/recovery tests; CloudTrail/service/billing evidence; and no-create or verified cleanup proof.

Official sources

• AWS Organizations introduction
• Organizations concepts
• Management-account best practices
• Organizations policy types
• Authorization policies: SCPs and RCPs
• Declarative policy inheritance
• Organizations integrations and trusted access
• Monitor current account states
• Remove a member account
• Consolidated billing
• AWS Organizations 2017 general availability