IAM misconfigurations are consistently in the top three categories of cloud security incidents. At single-account scale, the blast radius of a misconfiguration is bounded by the account. At multi-account scale — where a single management account governs dozens of member accounts — the blast radius can be catastrophic. AWS Organizations with Service Control Policies (SCPs) is how enterprise environments establish guardrails that no account-level IAM policy can override.

AWS Organizations: The Foundation

AWS Organizations provides a hierarchy of accounts grouped into Organizational Units (OUs). Policies attached to OUs apply to all accounts within them — including child OUs. The typical enterprise OU structure:

Root
├── Security (Audit, Log Archive)
├── Infrastructure (Network, Shared Services)
├── Workloads
│   ├── Production
│   │   ├── Prod-App-A
│   │   └── Prod-App-B
│   └── Non-Production
│       ├── Dev
│       └── Staging
└── Sandbox

The management account (root) should have no workloads. It exists solely to manage the organization. Access to it should be extremely restricted and audited.

Service Control Policies: Maximum Permission Boundaries

SCPs define the maximum permissions available in an account. They do not grant permissions — they restrict what can be granted by IAM policies in member accounts. An SCP allow does not mean a user can do the action; the user's IAM policy must also allow it. An SCP deny is absolute — even an account root user cannot override an SCP deny (with one exception: management account).

Essential SCP Patterns

1. Region restriction: Prevent resources being created outside approved regions. This is one of the highest-value SCPs — it prevents shadow IT, reduces the scope of security monitoring, and simplifies compliance.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-south-1", "us-east-1"]
    }
  }
}

Note: global services (IAM, STS, Route 53, CloudFront) must be excluded via a NotAction list or the SCP will break them.

2. Prevent leaving the organization:

{
  "Effect": "Deny",
  "Action": "organizations:LeaveOrganization",
  "Resource": "*"
}

3. Protect security tooling: Prevent disabling GuardDuty, CloudTrail, Config, or Security Hub — these are your detection and audit layer.

{
  "Effect": "Deny",
  "Action": [
    "guardduty:DeleteDetector",
    "guardduty:DisassociateFromMasterAccount",
    "cloudtrail:DeleteTrail",
    "cloudtrail:StopLogging",
    "config:DeleteConfigurationRecorder",
    "securityhub:DisableSecurityHub"
  ],
  "Resource": "*"
}

4. Require encryption: Deny S3 bucket creation without default encryption, or EC2 instance launch without encrypted EBS volumes.

IAM Permission Boundaries

Permission boundaries are an IAM feature that defines the maximum permissions an IAM entity (user or role) can have. Unlike SCPs (which operate at the organization/account level), permission boundaries operate at the entity level within an account.

The key use case: delegated IAM administration. You want to allow a dev team to create IAM roles for their application — but you don't want them creating roles that have more permissions than their own team has. Attach a permission boundary to any role the dev team creates, and that boundary caps what those roles can do, regardless of what the role's identity-based policies say.

IAM Identity Center (SSO) — The Right Way to Handle Human Access

Long-lived IAM users with access keys are a persistent vulnerability. IAM Identity Center (formerly AWS SSO) provides federated access to multiple accounts from a single sign-on portal, integrated with your identity provider (Entra ID, Okta, etc.).

The access model: Permission Sets define what a human can do in an account (mapped to IAM policies). Users or groups are assigned permission sets to specific accounts. Access is via temporary credentials (typically 1–8 hour session duration). No long-lived access keys; no shared credentials.

Automated Account Vending with Control Tower

AWS Control Tower automates the account provisioning process — new accounts are created with baseline guardrails (mandatory SCPs), audit account integration, and logging configuration already applied. The Account Factory (or Account Factory for Terraform/AFT) creates new accounts via a self-service portal or Terraform pipeline, eliminating manual account setup and inconsistently applied controls.

Sripadatech designs AWS multi-account architectures and implements Organizations governance for enterprise clients. Contact us to discuss your AWS governance model.