Organizations and Policy Types

What it is

AWS Organizations lets you manage many AWS accounts as one group. Accounts are the strongest isolation boundary on AWS, so a multi account strategy limits the blast radius of mistakes and attacks, separates duties and gives each workload its own limits and billing.

Organizations adds the central controls: organizational units (OUs) to group accounts, and policies that apply to groups.

How it works

Designing the structure

A common structure uses OUs by function and risk, not by company department.

Keep the management account nearly empty. It is the one account that SCPs do not restrict, so it should host only Organizations, billing and a few central services, with very few users and strong MFA.

Create accounts through Organizations (or Control Tower) rather than by hand. A new member account gets an administrative role, OrganizationAccountAccessRole by default, that the management account can assume.

Policy types in Organizations

SCPs and RCPs filter permissions and never grant them. The identity and policy logic page covers how they combine with other policies.

SCP strategy

Use the default FullAWSAccess policy and add deny SCPs for the things you never want: a deny list is simpler to maintain than an allow list. Typical guardrails include:

• Deny leaving the organization.
• Deny disabling or deleting CloudTrail, Config, GuardDuty and Security Hub.
• Deny actions outside approved Regions.
• Deny use of the root user in member accounts.
• Deny creating IAM users or access keys, if you use only federation.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } }
    }
  ]
}

Test every SCP on a sandbox OU first. Attach policies to OUs rather than to individual accounts where possible, so that new accounts inherit them.

An action is allowed only if every level from the root to the account allows it. Allow exceptions with conditions, such as aws:PrincipalArn matching an administrative role, to keep a break glass path.

Delegated administrators and trusted access

Many services integrate with Organizations. You enable trusted access so the service can work across accounts, and you designate a delegated administrator member account to run the service day to day. This keeps routine security work out of the management account.

# AWS CLI, in the management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com
aws organizations register-delegated-administrator \
  --account-id 222233334444 \
  --service-principal guardduty.amazonaws.com

Services that commonly use a delegated administrator include GuardDuty, Security Hub, Config, Inspector, Macie, Firewall Manager, IAM Access Analyzer, CloudFormation StackSets and IAM Identity Center. Some services have their own enable command, which handles delegation, but the pattern is the same.

Sharing across accounts

AWS Resource Access Manager (RAM) shares resources, such as subnets, Transit Gateways, Private CA and Resolver rules, with accounts or OUs without copying them. Enable sharing with Organizations once, then share to an OU so new accounts get access.

Controlling account access

• Use IAM Identity Center for people. Do not create IAM users per account.
• Centralise root access management for member accounts, so there are no root passwords or keys to manage in each one.
• Set alternate contacts for security and billing in every account.
• Close or move accounts to a suspended OU with a deny all SCP when they are no longer needed.

Operating it safely

Changing an SCP at a high level affects many accounts at once. Review the policy, test, and roll out gradually. Monitor CloudTrail for AccessDenied events that the new policy causes, and keep a rollback path.