Account structure and separating environments

Before you launch a single server on AWS, you make a decision that is painful to change later: how to structure your accounts. Most people start with one account, put everything in it, and regret it — because one account mixing development experiments and production data has no real isolation, no clean blast-radius boundary, and a billing report you cannot make sense of. This first lesson is account structure and separating environments: the foundation everything else sits on. (This is a concept-and-usage course — you will understand how production AWS is run and see the real setup; you practise in your own free-tier account when you choose.)

Why one account is not enough

An AWS account is the fundamental boundary of isolation and billing. Everything in one account shares the same security perimeter, the same limits, and the same bill. Putting production and development in one account causes real problems:

No blast-radius isolation. A mistake in development — a runaway script, a misconfigured permission — can reach production resources, because they are in the same account. You want a wall between "where we experiment" and "where real users' data lives".
Weak security boundaries. Access is harder to scope: someone who needs to break things freely in dev should not, by default, be able to touch production. Separate accounts make that separation clean.
Unclear cost. With everything in one account, you cannot easily answer "what does production cost versus development?" — the bill is one undifferentiated lump.
Shared limits. AWS service quotas are per-account; dev workloads can exhaust a limit production needs.

The principle: an account is a boundary, so use accounts to draw the boundaries you care about — chiefly between environments (production, staging, development) and often between teams or products.

AWS Organizations and multiple accounts

The tool for running many accounts is AWS Organizations. It lets you create and manage a set of accounts under one umbrella, with consolidated billing and central governance. The common shape:

A management account (the root of the organization) — used only for organization-level administration and billing, not for running workloads. Keep it clean and locked down.
Member accounts for the actual work, typically one per environment: a production account, a staging account, a development account — and often a separate security/logging account and a shared-services account.
Organizational Units (OUs) group accounts (e.g. a "Workloads" OU containing prod and staging) so you can apply policy to a group.

This gives you what one account cannot: production genuinely isolated from development, a clear per-account bill, and central control. Consolidated billing also means the whole organization's usage is combined for volume discounts, while each account's costs stay visible separately — you get both isolation and a unified bill.

Service Control Policies: guardrails across accounts

Organizations also gives you Service Control Policies (SCPs) — organization-level guardrails that set the maximum permissions any account (or OU) can have, regardless of what its own IAM allows. An SCP does not grant permissions; it bounds them. Typical uses:

Restrict regions — deny everything outside the regions you actually use, so nobody accidentally spins up resources in a far region (a real cost and security concern).
Prevent leaving the organization or disabling security services (CloudTrail, GuardDuty) in member accounts.
Block risky actions in production that should never happen.

SCPs are a governance layer: even a full administrator in a member account cannot exceed what the SCP permits. For a foundation, the idea to hold is that Organizations lets you set organization-wide rules that individual accounts cannot override — a powerful safety net once you have many accounts.

A sensible starting structure

You do not need a dozen accounts on day one, but you should start with the separation that matters. A pragmatic baseline:

A management account — billing and org admin only, heavily locked down, no workloads.
A production account — real workloads and data, the most tightly controlled.
A non-production account (or separate staging and development accounts) — where you build and test freely without risking production.
Later, as you grow: a security/log-archive account (central CloudTrail logs, immutable), and a shared-services account (things many accounts use).

The through-line, and the theme of this whole module, is that these are the decisions painful to change later: migrating resources between accounts after the fact is real work, so you draw the boundaries early. Getting account structure right up front — production isolated, environments separated, an org with guardrails — saves you from a tangled, insecure, unaccountable single account that every growing team eventually regrets.

Check your work

Why not one account: an account is the isolation + billing boundary; one account mixing prod and dev gives no blast-radius isolation (a dev mistake can reach prod), weak security scoping, an unclear lumped bill, and shared quotas. Use accounts to draw the boundaries you care about — chiefly per environment.

AWS Organizations manages many accounts under one umbrella: a management account (billing/admin only, no workloads), member accounts per environment (prod/staging/dev, plus security and shared-services), and OUs grouping them. Gives isolation and consolidated billing (volume discounts, per-account visibility).

Service Control Policies (SCPs): org-level guardrails that bound the maximum permissions of an account/ OU (don't grant — cap). Uses: restrict regions, prevent disabling security services / leaving the org, block risky prod actions. Even a member-account admin cannot exceed them.

Starting structure: management (locked, no workloads) + production (tight) + non-production (or separate staging/dev); later add security/log-archive and shared-services accounts. These are decisions painful to change later — draw the boundaries early.

Practice

Explain why running production and development in a single AWS account is risky, on three dimensions (blast radius, security, cost).
Describe the role of the management account and why it should not run workloads.
Sketch a starting multi-account structure for a small team and justify each account.
Explain what an SCP does and does not do, with two example guardrails you would set.
Explain how consolidated billing gives you both isolation and a unified bill.
Explain why account structure is a "painful to change later" decision and what that implies for day one.

Official documentation

AWS — Organizing your AWS environment using multiple accounts — Why and how to use multiple accounts.
AWS Organizations — User guide — Managing accounts, OUs and consolidated billing.
AWS — Service Control Policies — Organization-wide permission guardrails.

Next: IAM — users, roles and least privilege in practice.