A practical guide to managing multiple AWS accounts as one — organizational units, service control policies, and why splitting workloads across accounts is often the right move.
For a solo developer or a small side project, one AWS account is usually all you need, and everything covered in the earlier courses in this series applies within that single account. AWS Organizations exists for a different situation: when you have, or expect to have, more than one AWS account, and you need a way to manage them together rather than as completely separate, disconnected entities. This becomes relevant surprisingly quickly for teams, for people running multiple independent projects, or for anyone who wants to properly separate production workloads from development and testing.
The instinct when starting out is often to keep everything in a single account, since creating separate accounts feels like unnecessary overhead. In practice, multiple accounts are widely considered a best practice in AWS specifically because of the isolation they provide. An account is the strongest security and billing boundary AWS offers — resources in one account cannot accidentally interfere with resources in another the way they could within shared IAM permissions inside a single account. A developer testing something destructive in a sandbox account cannot accidentally affect production, because production simply is not there to touch.
AWS Organizations lets you create new accounts under a central management account, group them into organizational units, and apply policies across those groups without having to log into each account individually. Rather than manually configuring IAM permissions in ten separate accounts, you can, for example, apply a single policy that says "no account in the development OU is allowed to use expensive GPU instance types," and have that rule enforced automatically across every account in that group.
Consolidated billing is often the first feature people encounter, sometimes before understanding the rest of Organizations. All accounts in an organization roll up to a single bill paid by the management account, and usage across accounts is often combined for volume pricing tiers, which can reduce costs compared to accounts billed entirely separately. This alone is a meaningful benefit even before considering the security and management advantages.
An organization has a root, which is the top-level container, and beneath it you create Organizational Units, or OUs, to group accounts logically. A common and genuinely practical starting structure looks something like this: a Security OU for accounts dedicated to logging and auditing, a Production OU for accounts running live workloads, a Development OU for testing and experimentation, and a Sandbox OU for accounts individual developers can use freely without any risk to anything that matters.
OUs can be nested, meaning a Production OU could contain further sub-OUs for different products or teams if the organization grows large enough to need that level of separation. For most small teams and individual developers managing a handful of projects, a flat structure with three or four top-level OUs is entirely sufficient, and there is little benefit in over-engineering the hierarchy before there is an actual organizational need for it.
Creating a new account within an organization is done directly through the Organizations console or API, without needing to go through the normal signup flow with a separate email and payment card for each one. Here is what creating a new member account looks like using boto3:
Each new account still needs a unique email address, even within an organization, though many teams use email aliasing (something like [email protected]) to route all these addresses to the same inbox without needing a genuinely separate mailbox for every account. Once created, an account can be moved into whichever OU makes sense, and it inherits any policies attached to that OU automatically.
Creating accounts in Organizations: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.htmlService Control Policies, or SCPs, are where AWS Organizations moves from convenience into genuine, enforceable governance. An SCP sets the maximum permissions available to accounts in an OU — it does not grant permissions on its own, the way an IAM policy does, but it defines a ceiling that no IAM policy within that account can exceed, no matter how permissive that IAM policy is written.
This distinction matters a lot in practice. Even an account administrator with full IAM permissions inside their own account cannot bypass an SCP applied from above, because SCPs are enforced at the organization level, entirely outside the reach of anything configured inside the account itself. This is what makes SCPs suitable for genuine guardrails rather than just suggestions — a rule like "no account may disable CloudTrail logging" or "no account may create resources outside the eu-west-1 region" becomes an actual enforced restriction rather than a policy someone could accidentally or deliberately work around.
Here is a simple SCP that denies the ability to leave the organization, a common protective measure to prevent an account from being accidentally or maliciously detached:
SCPs use the same JSON structure as the IAM policies covered in the IAM course, which makes the syntax familiar once you have written a few IAM policies. The key difference is where they are applied — attached to an OU or account within Organizations, rather than to a user, group, or role within a single account — and what they actually do, restricting rather than granting.
A practical and very common early SCP restricts which AWS regions an account is allowed to operate in. Many organizations only need one or two regions, and denying access to every other region reduces the attack surface, avoids accidental resource creation in unexpected regions, and simplifies cost tracking since usage cannot spread across regions you never intended to use.
Setting up AWS Organizations does add a layer of complexity that a single-account setup does not have, and it is worth being honest about when that complexity is actually justified. A solo developer working on one project genuinely does not need Organizations — the overhead of managing multiple accounts outweighs the benefit at that scale. The point where it starts to pay off is when there are genuinely separate concerns that benefit from hard isolation: a real production workload that should never be touched accidentally during development, multiple people who need different levels of access, or compliance requirements that call for demonstrable separation between environments.
A reasonable, widely used pattern for a growing project is to start with two accounts: one for production and one for everything else, including development and personal experimentation. As the project and team grow, splitting development further into its own dedicated account, and adding a separate account purely for centralized logging and security auditing, becomes worthwhile. This incremental approach avoids the trap of designing an elaborate ten-account structure before there is any real need for that level of separation.
The management account, the one that owns the organization itself, deserves special caution. Because it can create and manage every other account, and because SCPs applied at the root affect everything beneath it, the management account should generally not be used to run actual workloads at all. Its only job is to manage the organization, ideally accessed by very few people, with strong protections like mandatory MFA, because compromising it means potentially compromising every account underneath it.
AWS Control Tower is worth knowing about as a related service, even if this course does not cover it in depth. Control Tower builds on top of Organizations and automates much of the initial setup — creating a sensible default OU structure, setting up centralized logging, and applying a baseline set of SCPs — which removes a lot of the manual configuration otherwise required to get a multi-account setup off the ground correctly. For anyone seriously adopting a multi-account structure rather than just experimenting, Control Tower is usually the more efficient starting point than configuring Organizations entirely by hand.
The overall theme across this entire course is that Organizations exists to turn "multiple AWS accounts" from a management headache into a structured, governable system. Consolidated billing simplifies the financial side, OUs create logical groupings that reflect how a team actually works, and SCPs turn security intentions into enforced rules rather than just documented policy that depends on everyone remembering to follow it. None of it is necessary for a single small project, but understanding it early means recognising the right moment to adopt it rather than reaching for it too late, after a production incident makes the case for isolation the hard way.