Multi-account with Organizations

Amazon Web Services · Advanced · 16 min

Accounts are the strongest isolation boundary in AWS, and every serious AWS estate is a multi-account organization.

AWS Organizations groups accounts under a management account (which pays the bill and should run no workloads). Accounts are arranged in organizational units (OUs), such as Security, Infrastructure, Workloads/Prod, Workloads/Dev and Sandbox, and policies attached to an OU apply to everything below it.

Why many accounts: blast-radius isolation, clean separation of prod and non-prod, independent quotas, per-team cost visibility and simpler permissions. Consolidated billing still gives one invoice with shared volume discounts and Savings Plans.

Service control policies (SCPs) set the maximum permissions for every principal in member accounts, including their root users. They never grant anything. Typical guardrails: deny leaving the organization, deny disabling CloudTrail, GuardDuty or Config, restrict Regions, and deny creating IAM users with access keys. Resource control policies (RCPs) cap what can be done to resources such as S3 buckets and KMS keys, for example blocking access from outside the organization. Other policy types cover tags, backups and declarative service settings.

Around it you build a landing zone, usually with AWS Control Tower: a log-archive account receiving organization CloudTrail and Config data, an audit/security account as delegated administrator for GuardDuty and Security Hub, preventive and detective controls, and Account Factory for vending new accounts with baselines.

People sign in through IAM Identity Center, where permission sets (such as ReadOnly or Developer) are assigned to groups per account. Deploy shared resources to many accounts with service-managed CloudFormation StackSets, and share networks with AWS RAM.

Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "sts:*", "route53:*", "cloudfront:*",
                    "support:*", "budgets:*", "ce:*", "waf:*", "health:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {"aws:RequestedRegion": ["eu-west-1", "eu-central-1"]},
        "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/OrgBreakGlass"}
      }
    },
    {
      "Sid": "ProtectAuditTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    },
    {"Sid": "NoLeaving", "Effect": "Deny", "Action": "organizations:LeaveOrganization", "Resource": "*"}
  ]
}

Remember

  • Management account pays and governs; workloads live in member accounts grouped by OU
  • SCPs cap principals, RCPs cap resources; neither grants permissions
  • Landing zone: log archive, security tooling, Identity Center, account vending
  • Exempt global services when restricting Regions

Watch out for

  • A Region-deny SCP without exemptions for global services like IAM and STS, which breaks sign-in and IAM in every account.

Check yourself

  1. An SCP on the Prod OU allows only s3:* and ec2:*. A role in a prod account has AdministratorAccess. What can it do?
  2. Which account's principals are NOT restricted by SCPs?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html