Accounts, Organizations & billing

Multi-account isolation, SCPs, consolidated billing.

Beyond individual resources, an architect designs the account structure the whole estate lives in. AWS Organizations, consolidated billing, and the account-as-a-boundary model shape isolation, governance, and cost.

Accounts as boundaries, Organizations for governance

An AWS account is the strongest isolation boundary AWS offers: separate resource namespaces, separate default trust, and a clean seam for billing. Mature organizations use AWS Organizations to group many accounts into a hierarchy of organizational units, applying Service Control Policies that cap what each account can do — even its administrators. This gives you blast-radius isolation (prod in a different account from dev), org-wide guardrails (deny disabling logging, restrict Regions), and central control. A common pattern is a dedicated security/logging account, a shared-services account, and separate accounts per environment or team.

Organization (management account — billing + SCPs, no workloads)
 ├─ Security OU
 │    └─ log-archive, security-tooling
 ├─ Infrastructure OU
 │    └─ shared-services (networking, CI)
 └─ Workloads OU
      ├─ prod     (isolated)
      └─ dev/test (isolated)
 
# One SCP at the Workloads OU can deny, e.g., disabling CloudTrail — org-wide.

Consolidated billing and cost visibility

Consolidated billing rolls all accounts up to one payer, which both simplifies payment and pools usage for volume discounts and shared Savings Plans/Reserved Instance benefits — you get isolation without paying more for it. For cost management, use Cost Explorer and Budgets to see and alert on spend, and apply a consistent tagging strategy (owner, environment, cost-center) so you can attribute cost across accounts and resources. Good account structure plus tagging is what keeps a large, multi-team AWS estate both governable and cost-transparent, which is exactly what the Well-Architected cost and operational pillars call for.