AWS Organizations is your central control plane for managing multiple AWS accounts.
Let’s see it in action. Imagine you have three accounts: a "Dev" account for experimentation, a "Staging" account for testing before production, and a "Prod" account for your live applications. You want to ensure that all these accounts are using a specific IAM password policy and that no one can accidentally delete the Prod account. Organizations makes this seamless.
First, you set up a "Management" account. This is the account that will orchestrate everything. From the Organizations console in the Management account, you create your Organizational Units (OUs) – think of these as folders for your accounts. You might create an OU called "Production" and another called "Non-Production." You then move your Staging and Dev accounts into "Non-Production," and your Prod account into "Production."
Now, the power of Organizations truly shines: Service Control Policies (SCPs). SCPs are like AWS IAM policies but applied at the OU or account level, acting as guardrails. They don’t grant permissions; they restrict them. If an SCP says "no iam:DeleteAccount," then no one in any account within that OU (or the entire organization if applied at the root) can delete an AWS account, regardless of their IAM permissions. This is how you protect your Prod account.
Here’s how you’d enforce an IAM password policy across all accounts in the "Non-Production" OU. You’d create an SCP like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforcePasswordPolicy",
"Effect": "Allow",
"Action": "iam:UpdateAccountPasswordPolicy",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"iam:PasswordPolicyPasswordMinLength": "14",
"iam": [
"iam:PasswordPolicyRequireSymbols",
"iam:PasswordPolicyRequireNumbers",
"iam:PasswordPolicyRequireUppercaseCharacters",
"iam:PasswordPolicyRequireLowercaseCharacters"
]
}
}
}
]
}
You then attach this SCP to the "Non-Production" OU. Now, any attempt to create or update an IAM password policy in the Dev or Staging accounts that doesn’t meet these criteria will be denied. The iam:UpdateAccountPasswordPolicy action is allowed only if the specified conditions for password length and character types are met. This is crucial because IAM policies are evaluated differently than SCPs. IAM policies grant permissions, while SCPs set the maximum permissions an IAM policy can grant. If an IAM policy allows an action, but an SCP denies it, the action is denied.
This hierarchical structure is key. You can apply SCPs at the root of your organization to set baseline restrictions for everyone, then refine them by applying more specific SCPs to individual OUs or even directly to accounts. For example, you might have a root-level SCP that denies all access to the ec2:TerminateInstances action for any instance tagged with environment:production, and then a more permissive SCP on your Dev OU that allows broader EC2 actions.
The problem this solves is the complexity of managing security, compliance, and billing across a growing number of AWS accounts. Without Organizations, you’d be configuring IAM, security groups, and billing alerts individually for each account, a monumental task prone to errors. Organizations provides a single pane of glass for policy enforcement and consolidated billing. You can enable consolidated billing, where all costs from member accounts roll up to the Management account, and you can take advantage of volume discounts.
The one thing that trips many people up is the distinction between IAM policies and SCPs. You might have an IAM user with iam:CreateBucket permission. If you apply an SCP to their account that denies s3:CreateBucket, they still cannot create S3 buckets. This is because SCPs act as a ceiling on permissions; they don’t grant permissions themselves. The effective permissions are the intersection of IAM policies and SCPs.
Beyond SCPs, Organizations also enables you to integrate with AWS Config and AWS CloudTrail for centralized logging and resource inventory across all accounts. You can delegate administration for specific AWS services to a designated account within your organization, simplifying management of complex services like Security Hub or GuardDuty.
The next step in mastering AWS Organizations is understanding how to integrate it with AWS Control Tower for a more opinionated, automated setup of secure, multi-account AWS environments.