AWS Organizations & Account Structure

Overview

AWS organizes everything around the account as the real isolation boundary, unlike a nested resource-group hierarchy inside a single subscription, an AWS account is where billing, service quotas, and blast radius actually get contained. AWS Organizations lets many accounts be managed together: organizational units (OUs) group accounts for policy application, and Service Control Policies (SCPs) attach at the organization, OU, or account level to cap the maximum permissions available underneath them, on top of, never instead of, the IAM policies that actually grant access. Tags and AWS Resource Groups exist for cross-resource visibility inside an account, but they are a query mechanism, not a lifecycle or deletion boundary the way an Azure resource group is.

Quick Reference

The commands below are grouped by service, not an exhaustive reference (see the official AWS CLI command reference for every flag), but the set that covers nearly all day-to-day aws CLI work.

Syntax

aws organizations create-organizational-unit \
  --parent-id r-abcd --name Production

aws organizations create-account \
  --email prod-payments@example.com --account-name payments-prod

Examples

scp-deny-outside-approved-regions.json, an SCP that caps every identity in the attached OU to two approved regions, no matter what their own IAM policy allows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "eu-west-1"] }
      }
    }
  ]
}

Visual Diagram

Common Mistakes

• Assuming AWS Resource Groups behave like an Azure resource group, a deletion/lifecycle boundary, when they're really just a saved tag-based query with no ownership semantics.
• Running an entire company, production included, out of a single AWS account instead of separating environments and teams by account.
• Writing an SCP and expecting it to grant access, then being confused when everything underneath it still returns access denied without a matching IAM allow.
• Assuming an org-wide SCP also restricts the management account itself; SCPs only ever apply to member accounts, never to the management account.
• Skipping AWS Organizations and centralized logging entirely, leaving no org-wide guardrail against an individual account drifting out of compliance.

Performance

• SCP evaluation happens alongside normal IAM policy evaluation and adds no meaningful latency, the real cost is organizational complexity if the OU/SCP structure isn't kept simple.
• Account creation and OU membership changes through AWS Organizations are eventually consistent, propagation to all regions/services can take a few minutes, don't assume it's instantaneous.

Best Practices

• Separate accounts by environment (production, staging, development) and by team or workload boundary, using AWS Organizations to manage them centrally rather than tags inside one account.
• Apply SCPs at the OU level for guardrails that should apply organization-wide (approved regions, disallowed services), rather than repeating them per account.
• Use a dedicated management account for billing/Organizations and a separate log-archive account for centralized CloudTrail logs, following the landing-zone pattern instead of overloading one account with every responsibility.
• Use tags and AWS Resource Groups for cross-resource visibility and cost allocation within an account, not as a substitute for real account-level isolation.