AWS Organizations and SCPs

AWS Organizations is a free service that enables you to centrally manage multiple AWS accounts. As your business grows, you might have separate accounts for development, testing, production, and different business units. Without a central management tool, each account is a silo – you must log in to each one to apply policies, track costs, and manage users. This leads to inconsistent security, billing chaos, and operational overhead.

AWS Organizations solves this by providing a single point of control. You designate one account as the management account (formerly called the master account). From this account, you can create new accounts, invite existing accounts to join, group accounts into organizational units (OUs), and apply policies across the entire organization. The most important policies are Service Control Policies (SCPs), which set permission guardrails that apply to all accounts in an OU or the whole organization.

When you create an organization, AWS automatically creates a root container. All accounts are placed under this root. You can then create OUs as sub-containers. For example:

- Root - Security OU (contains audit account, logging account) - Workloads OU - Production OU (contains prod accounts) - Development OU (contains dev accounts)

Each account can be in only one OU at a time. The management account is always separate and not subject to SCPs by default (though you can apply SCPs to it, but it's not recommended).

SCPs are JSON policy documents that specify allowed or denied actions. They use the same syntax as IAM policies but have a different effect. An SCP does not grant permissions – it defines a maximum permission boundary. For a user or role to actually perform an action, three conditions must be met:

If an SCP denies an action, it is blocked regardless of what IAM policies say. This is the key difference from IAM: SCPs act as an overarching guardrail.

AWS Organizations itself is free. There is no cost to create an organization, create OUs, or attach policies. However, you pay for the AWS services used in each member account (e.g., EC2, S3). The management account can consolidate billing, giving you volume discounts across all accounts.

There are two feature sets:

Limits:

In an on-premises environment, centralizing security policies across multiple business units often requires separate directory services, network segmentation, and manual configuration. AWS Organizations provides a cloud-native way to enforce policies at scale. Without it, you would need to replicate IAM policies across every account manually, which is error-prone. Competing cloud providers offer similar services (e.g., Azure Management Groups with Azure Policy, GCP Organizations with Organization Policies). However, AWS Organizations is tightly integrated with IAM, making it a foundational component for multi-account strategies.

SCPs are attached to the root, OUs, or directly to accounts. They are inherited by all child OUs and accounts. For example, if you attach an SCP to the root that denies all actions on EC2, no account in the organization can use EC2. If you attach an SCP to the Production OU that denies deleting CloudTrail trails, only accounts in Production are affected.

SCPs can use allow lists or deny lists. An allow list explicitly allows only specific actions (denying everything else by default). A deny list explicitly denies certain actions while allowing everything else. AWS recommends starting with a deny list approach to avoid accidentally blocking necessary services.

Example SCP (deny list):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser"
      ],
      "Resource": "*"
    }
  ]
}

This SCP prevents any account in the target OU from creating or deleting IAM users. Note that the management account is not affected by default.

A financial services company must comply with PCI-DSS, which requires strict controls over who can access production environments. They use AWS Organizations to manage over 50 accounts. The security team creates OUs for 'PCI-Production', 'PCI-Testing', and 'Non-PCI'. They attach SCPs to the 'PCI-Production' OU that:

When a developer tries to launch an unauthorized instance type, the SCP denies the API call even if the developer's IAM role allows it. This enforces compliance without relying on individual account administrators. The security team uses AWS CloudTrail to monitor denied API calls and receives alerts if anyone attempts a blocked action. Cost: the SCPs themselves are free, but the organization pays for the underlying resources in each account. Misconfiguration: if the security team accidentally attaches a deny-all SCP to the root, all accounts lose access. They always test new SCPs on a single test account first.

A startup uses AWS Organizations to consolidate billing across 10 accounts for different teams (engineering, marketing, data science). The finance team uses the management account to view a single bill and get volume discounts. They also use SCPs to enforce cost controls. For example, they attach an SCP to the 'Development' OU that denies ec2:RunInstances with instance types larger than t3.large. This prevents developers from accidentally launching expensive instances. They also deny rds:CreateDBInstance for database instances that are not db.t3.micro. This keeps development costs low. The SCPs do not grant permissions; they only set boundaries. Developers still need IAM roles that allow EC2 actions, but the SCP ensures they cannot exceed the size limit. If a developer needs a larger instance for a legitimate reason, they must request an exception from the finance team, who can temporarily detach the SCP or create a new one with a broader allowance. This workflow balances autonomy and control.

A company creates an organization but does not enable all features, so they cannot use SCPs. They rely on IAM policies in each account, but these are inconsistent. An administrator in one account accidentally deletes a critical S3 bucket because there is no central policy to prevent it. Later, they enable all features and attach a deny SCP to prevent s3:DeleteBucket. However, they forget to attach the FullAWSAccess policy to new accounts, causing all users to lose access. The root user of the management account can still access accounts, but day-to-day operations stop. They learn to always attach the FullAWSAccess policy to the root OU and then apply deny policies as needed. This scenario highlights the importance of understanding SCP inheritance and the default FullAWSAccess policy.