AWS Organizations

Organizations groups multiple AWS accounts under one management account, with consolidated billing, centralised policy and shared service configuration.

The question it answers is why you would want many accounts at all. The answer is that an AWS account is the strongest isolation boundary AWS offers. Service quotas are per account, a blast radius stops at the account edge, IAM cannot accidentally reach across one, and billing separates without tag discipline. Separating production from development with VPCs and IAM policies in one account is possible and considerably weaker. One over-broad policy and the separation is gone.

Structure

aws organizations create-organization --feature-set ALL

ALL, not CONSOLIDATED_BILLING. The billing-only feature set gives you a shared invoice and nothing else, no service control policies, no delegated administration, no organisation-wide CloudTrail. Upgrading later requires every member account to accept, which is tedious.

aws organizations create-organizational-unit --parent-id "$ROOT_ID" --name Workloads
aws organizations create-organizational-unit --parent-id "$WORKLOADS_OU" --name Prod
aws organizations create-organizational-unit --parent-id "$WORKLOADS_OU" --name NonProd

A structure that works for most organisations:

Root
├── Security          (log archive, audit, security tooling)
├── Infrastructure    (shared networking, CI/CD, DNS)
├── Workloads
│   ├── Prod
│   └── NonProd
├── Sandbox           (loose controls, hard spend limits)
└── Suspended         (deny-all, for accounts being wound down)

Organise by what policy should apply, not by team. Teams reorganise; the distinction between production and non-production does not. An OU structure mirroring your org chart needs rebuilding after every reorganisation, and policies attached to it move with people rather than with risk.

Keep the hierarchy shallow. Policies inherit down, and debugging an effective policy through five nested levels is genuinely unpleasant.

The management account

Three rules, and they are widely broken.

Run no workloads in it. Nothing. It is where organisation-wide policy lives, and it is the one account service control policies cannot restrict. An SCP never applies to the management account, so it has no guardrails at all.

Lock it down. Hardware MFA on root, root credentials in a safe, no IAM users, access only via a break-glass role that alarms when assumed.

Do not use it as the security account. Delegate to a separate one:

aws organizations register-delegated-administrator \
  --account-id 210987654321 \
  --service-principal guardduty.amazonaws.com

Delegated administration lets a dedicated security account manage GuardDuty, Security Hub, Config, IAM Access Analyzer and others across the organisation, so day-to-day security work never requires touching the management account.

Creating accounts

aws organizations create-account \
  --email aws-prod-payments@example.com \
  --account-name "Payments Production" \
  --role-name OrganizationAccountAccessRole \
  --iam-user-access-to-billing DENY

aws organizations describe-create-account-status \
  --create-account-request-id car-abc123

Two practical points.

Every account needs a unique email address, and it cannot be reused even after an account is closed. Use a plus-addressed or distribution-list scheme, aws-prod-payments@example.com, pointing at a group rather than an individual. An account whose root email belongs to someone who has left is a genuine problem.

OrganizationAccountAccessRole is created automatically and trusts the management account, which is how you get into a new account initially. It grants full administrator access, so treat assuming it as a privileged operation and alarm on it.

Move the account into the right OU immediately, since it lands under the root where fewer policies apply:

aws organizations move-account --account-id 210987654321 \
  --source-parent-id "$ROOT_ID" --destination-parent-id "$PROD_OU"

Billing

Consolidated billing is the most immediately visible benefit, and it does more than combine invoices.

Volume discounts aggregate. Tiered pricing for S3 and data transfer is calculated across the whole organisation, so ten accounts each using 20 TB are priced as 200 TB.

Reserved Instances and Savings Plans are shared by default. An unused reservation in one account automatically applies to matching usage in another. That is usually what you want, and occasionally not. A team that bought reservations from its own budget may be subsidising another. Turn sharing off per account where it matters:

aws organizations disable-aws-service-access \
  --service-principal ram.amazonaws.com    # example: RAM sharing

Cost allocation tags must be activated in the management account before they appear in reports:

aws ce list-cost-allocation-tags --status Inactive
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=CostCentre,Status=Active

Tags applied for months before activation produce no historical data, which is a common and irritating discovery.

Control Tower

Control Tower is a managed layer over Organizations that sets up a landing zone: the OU structure, a log archive and audit account, organisation CloudTrail, Config with conformance packs, IAM Identity Center and a set of guardrails.

Use it for a new organisation. It produces a sound structure in an afternoon rather than weeks, and encodes AWS's current recommendations.

Two caveats worth knowing before committing. It is opinionated about structure, and fighting it is unpleasant. And enrolling existing accounts with established configurations can be awkward, sometimes requiring changes you would not otherwise make. For a greenfield organisation it is the obvious choice; for a large existing estate, evaluate carefully.

Closing accounts

aws organizations close-account --account-id 210987654321

The account enters a 90-day suspended state before final closure, during which it can be reopened. Its resources stop and its root email remains unusable for a new account permanently.

The pattern worth adopting instead is a Suspended OU with a deny-all SCP. Move the account there, let it sit with everything blocked, and confirm nothing broke before closing it properly. Closure is irreversible after 90 days, and the data goes with it.

There is also a quota on how many accounts can be closed in a rolling 30-day period, which surprises teams doing a large cleanup.

Common errors

AccessDeniedException: You don't have permissions to access this resource.

Organizations APIs largely work only from the management account, or from a delegated administrator for that specific service.

ConstraintViolationException: You have exceeded the allowed number of AWS
accounts

A soft quota. Request an increase; new organisations start with a low limit.

DuplicateAccountException / EmailAlreadyExists

That email belongs to an existing or previously closed AWS account. Addresses are never released.

An SCP has no effect on the management account. By design. It cannot be restricted.

Quick reference

---

Key takeaways

• An account is the strongest isolation boundary AWS has: quotas, blast radius, billing, IAM.
• Create with --feature-set ALL. Billing-only blocks SCPs and delegated administration.
• Organise OUs by policy, not by team. Teams reorganise; prod versus non-prod does not.
• Run nothing in the management account, and remember SCPs never apply to it.
• Delegate security services to a dedicated account rather than working in the management account.
• Each account needs a unique, permanently consumed email: use distribution lists.
• Reservations and Savings Plans are shared by default, which is usually right.
• Activate cost allocation tags or they generate no data.
• Use a Suspended OU before closing an account. Closure is irreversible.

---

Check your understanding

---

Frequently Asked Questions

Why use multiple AWS accounts instead of one with separate VPCs?

Because an account is the strongest isolation boundary AWS provides. Service quotas apply per account, so one team cannot exhaust another's Lambda concurrency. A compromise or a runaway script stops at the account edge. IAM policies cannot accidentally grant access across accounts the way an over-broad policy can within one. And costs separate without relying on tag discipline. VPC and IAM separation inside a single account is workable and materially weaker. One mistaken wildcard undoes it.

How should I structure organizational units?

By the policies that should apply, not by team. A structure of Security, Infrastructure, Workloads split into Prod and NonProd, plus Sandbox and Suspended, reflects genuine differences in what should be permitted and survives reorganisations. An OU per team means restructuring the hierarchy and its attached policies whenever the company reshuffles. Express team ownership through tags and account names instead, and keep the tree shallow. Inherited policies across many levels are hard to reason about.

What should the management account be used for?

Organisation management and nothing else. No workloads, no data, no shared services. The reason is that service control policies never apply to it, so it has no guardrails at all. A mistake there has no safety net. Lock root with hardware MFA, store the credentials physically, create no IAM users, and access it only through a break-glass role that raises an alarm when assumed. Delegate GuardDuty, Security Hub, Config and similar services to a dedicated security account.

What does consolidated billing actually save?

More than a single invoice. Volume discount tiers for services such as S3 and data transfer are calculated across the whole organisation, so many accounts' usage aggregates into cheaper tiers. Reserved Instances and Savings Plans are shared by default, meaning an unused reservation in one account automatically covers matching usage in another. That sharing is usually desirable and occasionally not, if a team purchased reservations from its own budget. It can be disabled per account.

Should I use AWS Control Tower?

For a new organisation, yes. It sets up a landing zone. OU structure, log archive and audit accounts, organisation CloudTrail, Config with conformance packs, IAM Identity Center and guardrails, in an afternoon rather than weeks of assembly, and it encodes AWS's current recommendations. The caveats are that it is opinionated about structure and unpleasant to fight, and that enrolling existing accounts with established configurations can be awkward. For a large existing estate, evaluate before committing.

What happens when I close an AWS account?

It enters a suspended state for 90 days during which it can be reopened, then closes permanently along with its data. The root email address is consumed forever and cannot be used for a new account, even after closure. There is also a quota on closures within a rolling 30-day window, which catches teams doing bulk cleanup. The safer pattern is a Suspended OU with a deny-all SCP: move the account there, confirm over some weeks that nothing depended on it, and only then close.