AWS Organizations and IAM Foundations: Accounts, OUs and Roles

Quick take: AWS accounts are the walls between workloads. Organizations and IAM are the keys and the locks. Get this right early and scaling is painless; get it wrong and every new account is a security incident waiting to happen.

A small fintech started with one AWS account shared by the whole engineering team. Root credentials lived in a shared password manager. When the team grew to thirty people, nobody knew who had created which IAM user, access keys were pasted into laptops, and a contractor still had console access three months after leaving. The fix was not more policies in the same account — it was a proper multi-account structure with centralized identity and least-privilege roles. That is the subject of this article, and it is the cheapest, highest-leverage security investment you will make on AWS.

The thing that makes this hard is that “permissions on AWS” is not one mechanism — it is a chain of them, evaluated in a specific order, where an explicit Deny anywhere wins, where an SCP on an organizational unit can cap an admin who has AdministratorAccess, and where a role with perfect permissions still fails because its trust policy names the wrong principal. Most “why can’t I do this?” and far more dangerous “why could they do that?” incidents come from not holding the whole chain in your head. This article builds that chain explicitly — principal → STS → org guardrails → policy evaluation → resource — and then enumerates, in tables you can keep open during an incident, every account type, OU layout, identity option, policy type, evaluation rule, error code and failure mode that sits along it.

By the end you will design an account structure that isolates blast radius, hand humans temporary credentials instead of long-lived keys, write trust policies that are gates rather than rubber stamps, use SCPs as guardrails (not as a permissions system), and read an AccessDenied message back to the exact line of the exact policy that produced it. We use real service names, real default limits, real aws CLI and Terraform, and the actual IAM policy-evaluation order — not a simplified cartoon of it.

What problem this solves

A single account with many users and resources becomes impossible to audit and dangerous to operate. Everything shares one trust boundary: a misconfigured Lambda in “dev” runs in the same account as the production database; one over-broad IAM user is a path to every resource; one leaked root credential is total compromise. There is no natural place to set a guardrail that says “nothing in this part of the company may ever create a public S3 bucket,” because there is no “part” — there is just one flat namespace of users and resources.

What breaks without this structure, concretely: you cannot answer “who can delete the production database?” because permissions are scattered across dozens of inline policies and ad-hoc users. You cannot give a contractor access to one project without risking the whole account. You cannot prove to an auditor that dev cannot reach prod, because they share an account. Cost attribution is guesswork because one bill covers everything. And the day someone’s laptop with an access key is stolen, the blast radius is everything, not one workload.

Who hits this: every team that grows past a handful of people or past a single environment. It bites hardest on regulated workloads (fintech, health, anyone facing an audit), on teams onboarding contractors or third parties, and on anyone who started with one account “just to try AWS” and never restructured. The fix is structural — accounts as boundaries, an organization to govern them, Identity Center for humans, roles for everything — and the rest of this article is how each piece works and the exact ways each one fails.

To frame the whole field before the deep sections, here is every layer this article covers, the question it answers, and where it lives:

Learning objectives

By the end of this article you can:

• Design an AWS Organizations structure — management account, organizational units, member accounts — that isolates blast radius and gives every account a clear governance home.
• Choose between an IAM user, an IAM role, and IAM Identity Center access for any caller, and explain why humans should almost never have long-lived IAM users.
• Write an IAM identity policy, a resource policy and a trust policy, and say exactly what each one controls and which one is the real gate for AssumeRole.
• Recite the IAM policy-evaluation order and predict the decision for any combination of Allow, explicit Deny, SCP, RCP, permissions boundary and session policy.
• Use service control policies (SCPs) and resource control policies (RCPs) as guardrails — capping maximum permissions — without mistaking them for a permissions-granting system.
• Apply a permissions boundary to safely delegate IAM administration without letting a junior admin escalate their own privileges.
• Diagnose an AccessDenied to the exact policy that produced it using CloudTrail, the IAM Policy Simulator and sts decode-authorization-message.
• Stand up the whole foundation with aws CLI and Terraform, and avoid the dozen mistakes that turn a clean foundation into a sprawl.

Prerequisites & where this fits

You should already have signed in to the AWS console at least once and know that an AWS account has a 12-digit ID, a root user (the email you signed up with), and a billing relationship. You should be comfortable running the aws CLI with a configured profile, reading JSON, and editing a small JSON policy document. Nothing here requires prior IAM depth — that is what we build — but knowing what an S3 bucket and an EC2 instance are makes the examples land.

This is the foundation layer of an AWS estate: everything else sits on top of it. The account and OU structure here is what AWS Control Tower Guardrails: Building a Secure Multi-Account Foundation automates and enforces at scale — Control Tower is Organizations plus a managed landing zone plus baked-in guardrails, so understanding the raw pieces first makes Control Tower legible rather than magic. The audit story — who did what, and why a call was denied — is AWS CloudTrail and Config: Audit and Compliance at Scale, and CloudTrail is the single most useful tool when an IAM decision surprises you. The network boundary that complements the account boundary is AWS VPC, Subnets and Security Groups Explained, and the question of where accounts and resources physically live is AWS Regions and Availability Zones: Resiliency from the Ground Up.

A quick map of who owns what during an access incident, so you call the right person fast:

Core concepts

Six mental models make every later section obvious.

An account is the real security boundary. On AWS, the blast radius of almost any failure — a leaked key, a wrong policy, a runaway script, a compromised dependency — is bounded by the AWS account it happened in. Separate accounts share nothing by default: no VPC, no IAM principal, no resource. That isolation is the whole reason multi-account exists. A “dev” account that gets compromised cannot touch “prod” because there is no path between them you did not explicitly create. Accounts are cheap (free to create; you pay only for what runs in them), so you use them generously — per environment, per team, per workload, per blast-radius unit.

An organization groups accounts and lets you govern them centrally. AWS Organizations ties accounts together under a single management account (the payer), gives you consolidated billing, and — critically — lets you attach policies to organizational units (OUs) that inherit downward to every account inside them. An OU is a folder of accounts (and OUs can nest, up to five levels deep). The OU tree is where governance lives: you put all production accounts in a Workloads/Prod OU and attach a guardrail to the OU, not to thirty accounts one by one.

Humans get temporary credentials; only machines and break-glass get keys. The modern pattern is IAM Identity Center (formerly AWS SSO): a human authenticates once (against Identity Center’s own directory or your corporate IdP via SAML/SCIM), is matched to a permission set, and STS mints temporary credentials (valid for up to 12 hours) by having them assume a role in the target account. No human IAM user, no long-lived access key, no key to rotate when they leave — you just remove their group membership. IAM users with access keys still exist, but for narrow cases: a few break-glass admins, and legacy automation that cannot use a role.

A role is a set of permissions anything can temporarily wear. An IAM role is not a person; it is a named bundle of permissions plus a trust policy saying who is allowed to assume it. An EC2 instance, a Lambda function, a user in another account, or an Identity Center session can all assume a role and act with its permissions for a bounded session. Roles are the universal mechanism for temporary, auditable access — and the trust policy, not the permissions, is what decides whether the assumption is allowed at all.

Every permission is the outcome of a chain, and an explicit Deny always wins. A request is allowed only if it survives the full policy-evaluation chain: organization SCPs/RCPs (which cap what is reachable), the permissions boundary (which caps the principal), the identity policy (which must Allow), any session policy, and the resource policy (for cross-account, which must also agree). At every layer, an explicit Deny ends evaluation immediately. There is no “mostly allowed.” This single rule — explicit Deny beats any Allow; SCP/boundary can only subtract — explains nearly every IAM surprise.

Policies are JSON, and the building blocks are always the same. Every policy is a JSON document of statements, each with an Effect (Allow/Deny), one or more Actions (s3:GetObject), a Resource (an ARN), an optional Principal (who — only in resource/trust policies), and optional Conditions (when — MFA present, source IP, aws:PrincipalOrgID). Learn this shape once and every policy type reads the same.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

The AWS account: the blast-radius boundary

Everything starts with the account, so be precise about what it is. An AWS account is an isolated tenancy with its own 12-digit ID, its own resource namespace, its own service quotas, its own root user, and (under an org) a billing relationship to the payer. Two accounts share nothing by default — that is the entire point. You create accounts liberally because isolation is the cheapest security control you have.

Why separate accounts at all

Strong, hard isolation is the headline, but it buys you several distinct things at once. Each row below is a reason teams move from one account to many:

Common account roles in an estate

Mature estates converge on a small set of named account purposes. You do not need all of these on day one, but knowing the target shape prevents painting yourself into a corner:

The cardinal rule is the first row: the management account holds no workloads. It can administer the entire organization, so anything running there is a maximum-blast-radius target, and several org-level actions cannot be guarded by SCPs (SCPs do not restrict the management account). Treat it as a vault you visit, not an office you work in.

Securing the root user

Every account — management and member — has a root user that bypasses IAM. You lock it down once and ideally never use it again. The actions that genuinely require root are few and worth memorising, because they tell you when you are forced to break the glass:

The hardening checklist for root, in priority order — do every row:

# Confirm the root user has NO access keys (run as an admin role, not as root)
aws iam get-account-summary --query "SummaryMap.AccountAccessKeysPresent"
# 0 = good (no root keys). 1 = delete them immediately.

AWS Organizations and OUs

An organization is the container that ties accounts together. You create it from the account that becomes the management account; every other account is a member account, either created inside the org (it gets a member-managed OrganizationAccountAccessRole you can assume) or invited in (an existing account accepts an invitation).

Organization feature sets

Organizations has two modes, and you almost always want the second:

# Create an organization with ALL features (run once, from the management account)
aws organizations create-organization --feature-set ALL

Designing the OU tree

OUs are folders; policies attach to them and inherit down to every account and sub-OU inside. A clean starting tree separates governance intent, not just team names. A widely used baseline:

# Create the root-level OUs (capture the org root id first)
ROOT_ID=$(aws organizations list-roots --query "Roots[0].Id" -o text)
aws organizations create-organizational-unit --parent-id "$ROOT_ID" --name "Security"
aws organizations create-organizational-unit --parent-id "$ROOT_ID" --name "Workloads"

# Terraform: an org with all features, plus two OUs
resource "aws_organizations_organization" "this" {
  feature_set = "ALL"
  enabled_policy_types = ["SERVICE_CONTROL_POLICY", "RESOURCE_CONTROL_POLICY"]
}

resource "aws_organizations_organizational_unit" "security" {
  name      = "Security"
  parent_id = aws_organizations_organization.this.roots[0].id
}

resource "aws_organizations_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = aws_organizations_organization.this.roots[0].id
}

Organizations limits that shape your design

These are the real defaults you design around (many are soft and raisable via a quota request, but the structure limits below are firm):

IAM identities: users, groups, roles

Inside each account, IAM answers “who can do what.” The “who” is a principal — and choosing the right kind of principal is the most consequential decision you make repeatedly.

Choosing the right principal type

The pattern is loud: roles for almost everything; IAM users only at the edges. Long-lived access keys are the leading cause of real-world AWS breaches because they do not expire, travel in plaintext, and rarely get rotated.

IAM entity limits per account

The defaults you bump into (most adjustable via Service Quotas, but know the starting numbers):

Groups: attach policy once, not per user

For the IAM users that do exist, never attach policies to individuals — attach to a group and add users to it. When someone changes role, you change group membership, not a pile of inline policies.

# Create a group, attach a managed policy, add a (break-glass) user to it
aws iam create-group --group-name BreakGlassAdmins
aws iam attach-group-policy --group-name BreakGlassAdmins \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam add-user-to-group --group-name BreakGlassAdmins --user-name alice-breakglass

resource "aws_iam_group" "breakglass" {
  name = "BreakGlassAdmins"
}

resource "aws_iam_group_policy_attachment" "breakglass_admin" {
  group      = aws_iam_group.breakglass.name
  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

IAM roles and trust policies

A role has two policies that do completely different jobs, and conflating them is the single most common IAM mistake.

Two policies, two jobs

The trust policy is the gate: if it does not name your principal, you get AccessDenied on sts:AssumeRole before any permission is ever checked. Conversely, a wildcard Principal in a trust policy is a gaping hole — any account can assume the role and inherit its permissions.

A trust policy that lets a specific other account’s role assume this one, only with an ExternalId and only from inside your org:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:role/ci-deployer" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "kloudvin-deploy-7f3a",
        "aws:PrincipalOrgID": "o-abcd1234ef"
      }
    }
  }]
}

# Assume a role and get temporary credentials (15 min – 12 h session)
aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/AppDeployRole \
  --role-session-name alice-deploy \
  --external-id kloudvin-deploy-7f3a \
  --duration-seconds 3600

Trust-policy principal types

The Principal element in a trust policy can name several kinds of caller — each with a different security profile:

Conditions that harden a trust policy

The Condition block is where you turn a broad principal into a safe one. The high-value condition keys:

IAM policies: the JSON building blocks

Every policy — identity, resource, trust, SCP — is the same JSON shape. Learn the elements once.

Anatomy of a policy statement

Policy types and where each attaches

There are more policy types than most people realise, and they do different things in evaluation:

Managed vs inline vs customer-managed

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadAppBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::kloudvin-app-data",
        "arn:aws:s3:::kloudvin-app-data/*"
      ]
    },
    {
      "Sid": "DenyUnlessTLS",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::kloudvin-app-data/*",
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

# Create a reusable customer-managed policy from a file, then attach to a role
aws iam create-policy --policy-name ReadAppBucket \
  --policy-document file://read-app-bucket.json
aws iam attach-role-policy --role-name AppRole \
  --policy-arn arn:aws:iam::444455556666:policy/ReadAppBucket

How a permission is actually decided: evaluation order

This is the heart of IAM and the reason for nine out of ten surprises. A request runs the full chain, and the order — plus “explicit Deny always wins” — is non-negotiable.

The decision flow, step by step

Two foundational truths fall out of this table:

Same-account vs cross-account

The Allow side has a subtle but critical difference depending on whether the caller and resource are in the same account:

Worked example: who wins?

Take a role with AdministratorAccess (identity Allow on *), in an account whose OU has an SCP denying s3:DeleteBucket outside region ap-south-1, with a permissions boundary limited to s3:* and ec2:*:

The lesson the table teaches: AdministratorAccess is not a guarantee. An SCP or a boundary above it silently subtracts, which is exactly how you safely let teams hold broad roles without holding god-mode.

Service control policies and resource control policies

SCPs and RCPs are the org-level guardrails. They are filters, not grants — they define the maximum that principals (SCP) or resources (RCP) in an OU can ever do, no matter what an in-account admin writes. This is how you enforce “nobody in production may disable CloudTrail” across thirty accounts with one policy.

SCP vs RCP vs permissions boundary

These three “capping” mechanisms confuse everyone; here they are side by side:

SCP strategies: allow-list vs deny-list

A classic deny-list SCP — block leaving the org, disabling CloudTrail, and using member-account root:

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

# Attach an SCP to an OU (the policy must be created first)
aws organizations attach-policy \
  --policy-id p-examplescp \
  --target-id ou-root-prod1234

resource "aws_organizations_policy" "deny_leave_org" {
  name    = "deny-leave-org"
  type    = "SERVICE_CONTROL_POLICY"
  content = file("${path.module}/scp-deny-leave-org.json")
}

resource "aws_organizations_policy_attachment" "prod" {
  policy_id = aws_organizations_policy.deny_leave_org.id
  target_id = aws_organizations_organizational_unit.workloads.id
}

The region-lock gotcha (read before you ship an SCP)

A favourite guardrail is “only operate in ap-south-1.” Naively denying everything outside the region locks you out of global services (IAM, STS, Route 53, CloudFront, Support) because they authenticate through us-east-1. Always exempt them with NotAction:

What SCPs/RCPs do not do

IAM Identity Center: human access done right

For humans, the destination is IAM Identity Center: one sign-in, MFA, and time-boxed role sessions in any account — zero IAM users to manage. It is the answer to “how does Alice get admin in staging and read-only in prod without a single long-lived key?”

The Identity Center vocabulary

Identity Center vs IAM users — the contrast that ends the debate

# After enabling Identity Center, log in for short-lived CLI credentials
aws configure sso          # one-time: set start URL + region
aws sso login --profile prod-readonly
aws s3 ls --profile prod-readonly   # uses temporary creds, auto-expires

# A permission set + assignment (Terraform)
resource "aws_ssoadmin_permission_set" "readonly" {
  name             = "ProdReadOnly"
  instance_arn     = local.sso_instance_arn
  session_duration = "PT4H"   # 4-hour sessions
}

resource "aws_ssoadmin_managed_policy_attachment" "readonly" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

resource "aws_ssoadmin_account_assignment" "platform_readonly_prod" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
  principal_id       = local.platform_group_id
  principal_type     = "GROUP"
  target_id          = local.prod_account_id
  target_type        = "AWS_ACCOUNT"
}

Permission-set design table

Permissions boundaries: delegating IAM safely

The hardest delegation problem is “let a team create their own roles without letting them grant themselves more than they have.” The tool is a permissions boundary: a managed policy that sets the maximum permissions a principal can have, regardless of its identity policies. You require — via SCP or condition — that any role the team creates must carry the boundary.

Why boundaries matter

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "BoundaryMaxPerms",
    "Effect": "Allow",
    "Action": ["s3:*", "dynamodb:*", "logs:*", "cloudwatch:*"],
    "Resource": "*"
  }]
}

# Create a role that MUST carry the boundary (the boundary caps its real power)
aws iam create-role --role-name TeamAppRole \
  --assume-role-policy-document file://trust.json \
  --permissions-boundary arn:aws:iam::444455556666:policy/TeamBoundary

Boundary mechanics — the rules that trip people up

Architecture at a glance

The diagram is not a request packet — it is the authorization path: how an identity becomes a permitted action, read left to right. Start at the principals: a workforce user signing in via SSO (no long-term keys), a narrow set of break-glass IAM users, and workloads carrying instance/execution roles. They flow into IAM Identity Center and STS, where a permission set is matched and AssumeRole mints temporary credentials (≤12 h, optionally gated by sts:ExternalId and MFA). The call then enters the org guardrails zone: the org root and OUs inherit an SCP/RCP cap downward, and a permissions boundary caps the assumed role — neither grants anything, they only subtract. Surviving that, the call reaches policy evaluation inside the target account, where the identity policy must Allow and the trust policy must have permitted the assumption in the first place. Only then does it touch a resource in the target account — whose own resource policy may extend access cross-account — with CloudTrail recording the call and, on failure, the exact AccessDenied reason. Above the whole path sit consolidated billing and the management account, which governs but holds no workloads.

Follow the five numbered badges and you have the complete failure map: a leaked or lingering long-lived key (1) on the principals; an AssumeRole denied or session too broad / confused-deputy (2) at STS; an SCP/RCP that blocks a legitimate action — or a missing Deny (3) in the guardrails; a wrong trust policy that lets nobody (or everybody) assume the role (4) in evaluation; and a cross-account Allow that still fails because the resource side never agreed (5) at the target. The legend narrates each as symptom · confirm · fix — the same method as the rest of the article: localise to a layer, read the cause, run the named check, apply the fix.

Real-world scenario

Paywave Fintech is the company from the opening: one shared AWS account, root in a shared vault, thirty engineers, a contractor still holding console access months after their contract ended. Their monthly AWS spend was about ₹9,00,000, all on one bill nobody could attribute. The trigger to act was an audit finding ahead of a payments licence: the auditor asked “prove dev cannot reach the production card-data store,” and the honest answer was “we can’t — it’s the same account.”

The platform team (three engineers) rebuilt the foundation over six weeks, deliberately and in order. Week 1 — the org. They promoted the existing account to a management account, created the organization with All Features, and built the OU tree: Security, Infrastructure, Workloads/Prod, Workloads/NonProd, Sandbox, Suspended. Week 2 — security accounts. They vended a Log Archive account (org-wide CloudTrail to an Object-Lock S3 bucket) and an Audit account (GuardDuty + Security Hub delegated admin), both in the Security OU. Crucially, they moved no workloads into the management account.

Week 3 — identity. They enabled IAM Identity Center, connected it to the company’s Okta via SAML + SCIM, and defined permission sets: ProdReadOnly (4 h) for all engineers, ProdOperator (2 h) for on-call, NonProdAdmin (8 h) for app teams, SandboxAdmin for everyone in sandbox. Every employee’s daily access became “log in to the portal, pick an account and role, get a temporary session.” Week 4 — kill the keys. They inventoried IAM users with generate-credential-report, found 41 human users and 6 with access keys unused for over 90 days (including the departed contractor’s), and deleted all human IAM users — leaving exactly two break-glass admins with MFA. The contractor’s access evaporated the moment their Okta account was disabled.

Week 5 — guardrails. They attached SCPs: org-wide deny on organizations:LeaveOrganization, cloudtrail:StopLogging, and member-account root use; a region-lock SCP pinning operations to ap-south-1 with the global-service NotAction exemption; and a sandbox spend guardrail. They tested each SCP in a PolicyStaging account before attaching it to a live OU. Week 6 — least privilege + delegation. App teams got iam:CreateRole in their own accounts, but gated by an SCP requiring every created role to carry a permissions boundary — so a team could move fast without granting themselves more than their cap.

The day the migration finished, the auditor’s question had a clean answer: the production card-data store lived in its own account in Workloads/Prod, dev lived in Workloads/NonProd, and there was no IAM principal, VPC peering, or resource policy linking them — provably isolated. When an engineer moved teams the next month, the change was a single Okta group edit: no keys to rotate, no orphaned users, no console access left behind. Spend became attributable per account, and Finance finally saw which workload cost what. The lesson the platform lead wrote on the wall: “Accounts are the walls. Identity Center is the door. SCPs are the locks. We stopped guarding one big room and built a building.”

The migration as a sequence, because the order is the lesson:

Advantages and disadvantages

The multi-account-plus-central-identity model both prevents a class of problems and adds some operational surface. Weigh it honestly:

The model is right for any organisation past a single environment or a handful of people, and mandatory for anyone facing an audit. It costs you upfront structure and a steeper mental model (the evaluation chain), but every one of the disadvantages is a one-time or automatable cost, while the advantages compound with every new account and every new hire. The teams that regret it are the ones who built the structure but never automated account vending — which is exactly the gap AWS Control Tower Guardrails: Building a Secure Multi-Account Foundation closes.

Hands-on lab

Build a minimal but real foundation: create an org (if you have a spare standalone account), make an OU, attach a deny-list SCP, create a cross-account role with a hardened trust policy, and assume it. Free to run — you pay nothing for Organizations, IAM, or STS calls. Run with an admin profile, not as root.

Note: create-organization is irreversible-ish (you’d have to delete the org to undo). Use a throwaway/sandbox account, or skip Step 1 and use an existing org’s OU.

Step 1 — Create the organization (all features).

aws organizations create-organization --feature-set ALL
aws organizations describe-organization --query "Organization.{Id:Id,FeatureSet:FeatureSet}"

Expected: an org Id like o-xxxxxxxxxx and FeatureSet: ALL.

Step 2 — Create an OU under the root.

ROOT_ID=$(aws organizations list-roots --query "Roots[0].Id" -o text)
aws organizations create-organizational-unit --parent-id "$ROOT_ID" --name "LabSandbox" \
  --query "OrganizationalUnit.{Id:Id,Name:Name}"

Expected: an OU Id like ou-xxxx-xxxxxxxx.

Step 3 — Enable the SCP policy type, then create and attach a deny-list SCP.

aws organizations enable-policy-type --root-id "$ROOT_ID" \
  --policy-type SERVICE_CONTROL_POLICY 2>/dev/null || echo "already enabled"

cat > /tmp/scp-deny-leave.json <<'JSON'
{ "Version": "2012-10-17",
  "Statement": [{ "Sid":"DenyLeaveOrg","Effect":"Deny",
    "Action":["organizations:LeaveOrganization"],"Resource":"*" }] }
JSON

POLICY_ID=$(aws organizations create-policy --name lab-deny-leave \
  --type SERVICE_CONTROL_POLICY --description "lab" \
  --content file:///tmp/scp-deny-leave.json --query "Policy.PolicySummary.Id" -o text)

OU_ID=$(aws organizations list-organizational-units-for-parent --parent-id "$ROOT_ID" \
  --query "OrganizationalUnits[?Name=='LabSandbox'].Id | [0]" -o text)

aws organizations attach-policy --policy-id "$POLICY_ID" --target-id "$OU_ID"

Expected: no error; the SCP is now attached to LabSandbox.

Step 4 — Create a cross-account role with a hardened trust policy.

ACCT=$(aws sts get-caller-identity --query Account -o text)
cat > /tmp/trust.json <<JSON
{ "Version":"2012-10-17","Statement":[{
  "Effect":"Allow",
  "Principal":{"AWS":"arn:aws:iam::${ACCT}:root"},
  "Action":"sts:AssumeRole",
  "Condition":{"StringEquals":{"sts:ExternalId":"lab-12345"}} }] }
JSON

aws iam create-role --role-name LabAssumeMe \
  --assume-role-policy-document file:///tmp/trust.json
aws iam attach-role-policy --role-name LabAssumeMe \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

Step 5 — Assume the role and confirm temporary credentials.

aws sts assume-role --role-arn "arn:aws:iam::${ACCT}:role/LabAssumeMe" \
  --role-session-name lab --external-id lab-12345 \
  --query "Credentials.{AKID:AccessKeyId,Expiry:Expiration}"

Expected: an AccessKeyId starting ASIA… (temporary) and an expiry timestamp. Omit --external-id and you’ll get AccessDenied — proof the condition is the gate.

Step 6 — Teardown.

aws iam detach-role-policy --role-name LabAssumeMe \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam delete-role --role-name LabAssumeMe
aws organizations detach-policy --policy-id "$POLICY_ID" --target-id "$OU_ID"
aws organizations delete-policy --policy-id "$POLICY_ID"
aws organizations delete-organizational-unit --organizational-unit-id "$OU_ID"

Common mistakes & troubleshooting

This is the differentiator. Most IAM pain is one of these failure modes — match your symptom to the row, run the confirm step, apply the fix. The playbook as a table:

Reading an AccessDenied properly

The error message tells you almost everything if you read it. AWS now returns which policy type produced the deny:

For an encoded message (common with explicit denies), decode it:

# Turn the opaque "encoded authorization failure message" into readable JSON
aws sts decode-authorization-message --encoded-message <the-long-blob> \
  --query DecodedMessage --output text | python3 -m json.tool

And to predict a decision before shipping, simulate it:

# Will this principal be allowed to do this action on this resource?
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::444455556666:role/AppRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::kloudvin-app-data/key

Best practices

• Treat the account as the unit of isolation. One account per environment/workload/blast-radius unit; never run dev and prod in the same account.
• Keep the management account empty. No workloads, a tiny set of admins, MFA-protected root with no access keys.
• Humans use Identity Center, never IAM users. Federate to your IdP; enforce MFA; keep only a couple of MFA’d break-glass IAM users.
• Roles for everything machine. Instance/execution roles for compute; cross-account roles (with ExternalId) for third parties; no long-lived keys baked anywhere.
• The trust policy is the gate — make it specific. Name exact principals; add aws:PrincipalOrgID, sts:ExternalId, and MFA conditions; never Principal: "*".
• SCPs are guardrails, not a permissions system. Start deny-list; protect logging, root, and org membership; remember they only cap.
• Exempt global services in any region-lock SCP. NotAction for iam, sts, route53, cloudfront, support, organizations.
• Least privilege via customer-managed policies. Avoid blanket AdministratorAccess; scope actions and resources; review with Access Analyzer.
• Delegate IAM with a permissions boundary, and require it via SCP so teams can’t create roles without the cap.
• Centralise audit. Org-wide CloudTrail to a locked-down Log Archive account; you cannot debug AccessDenied without it.
• Test SCPs in a staging account first. A bad guardrail breaks everyone; the IAM Policy Simulator and a PolicyStaging account prevent org-wide outages.
• Rotate or eliminate access keys. If a key must exist, rotate ≤90 days and scope it hard; prefer Roles Anywhere for on-prem.

Security notes

Least privilege, encryption-in-transit and identity hygiene for this foundation, concretely:

Cost & sizing

The good news: the foundation itself is free. The cost lives in what runs inside the accounts and in the audit/logging you (rightly) turn on.

Sizing guidance, not dollars: the dominant foundation cost is CloudTrail data events + Log Archive storage, which scales with API volume and retention, not with how many accounts you have. Adding accounts is free; isolating workloads into more accounts does not raise your IAM/Org bill. The one trap is enabling CloudTrail data events (S3 object-level, Lambda invoke) org-wide on high-traffic buckets — that can surprise you; scope data events to the buckets that need them, and lifecycle the log bucket to Glacier after 90 days. For a ~30-account fintech, expect the foundation overhead (logging + security tooling) to be a low-single-digit percentage of total spend — cheap insurance for provable isolation.

Interview & exam questions

Q1. What is the security boundary on AWS, and why? The AWS account. Accounts share nothing by default — no IAM principal, VPC, or resource crosses an account line unless you explicitly create the path. That makes the account the natural blast-radius container, which is why multi-account design exists. (SAA-C03, SCS-C02.)

Q2. Explain the IAM policy-evaluation order. Start from implicit deny. An explicit Deny anywhere wins immediately. Otherwise the request must pass the SCP/RCP cap, the permissions boundary, any session policy, and then be explicitly Allowed by an identity or resource policy. SCPs/boundaries only subtract; they never grant. (SCS-C02.)

Q3. A role has AdministratorAccess but a call is denied. Name two reasons. (1) An SCP on the account’s OU explicitly denies that action — the management cap overrides the identity grant. (2) A permissions boundary on the role caps it below *. Both subtract from AdministratorAccess. (SCS-C02.)

Q4. What is the difference between a trust policy and a permissions policy on a role? The trust policy says who may assume the role (AssumeRole); the permissions policy says what the assumed role may do. The trust policy is evaluated first and is the real gate — perfect permissions are unreachable if the trust policy doesn’t name your principal. (SAA-C03, SCS-C02.)

Q5. How do SCPs differ from IAM identity policies? SCPs are organization-level caps attached to OUs/accounts that define the maximum permissions for principals beneath them; they cannot grant anything. IAM identity policies attach to a principal and grant permissions. Effective permission = intersection of SCPs and an identity Allow. (SCS-C02.)

Q6. Why use IAM Identity Center over IAM users for employees? Identity Center issues temporary, per-session credentials via STS, enforces MFA centrally, maps one identity to many accounts via permission sets, and makes offboarding a single group removal — no long-lived keys to rotate or leak. IAM users sprawl per account and carry static keys. (SAA-C03, SCS-C02.)

Q7. What is the confused-deputy problem and how do you prevent it? A third party with permission to act on your account could be tricked by another customer into accessing your resources. Prevent it by requiring a unique sts:ExternalId (and/or aws:SourceArn/aws:SourceAccount) in the role’s trust policy, so the third party must present a secret only you and they share. (SCS-C02.)

Q8. What is a permissions boundary and when do you use it? A managed policy that sets the maximum permissions a principal can have, regardless of its identity policies. You use it to safely delegate IAM (e.g. let a team CreateRole) — anything they create is capped by the boundary, so they cannot escalate above it. (SCS-C02.)

Q9. A region-lock SCP broke the console. Why, and how do you fix it? Global services (IAM, STS, Route 53, CloudFront, Support) authenticate through us-east-1, so a blanket deny outside your region blocks them. Fix it with a NotAction exemption listing those global services before the region condition. (SCS-C02.)

Q10. Why must the management account stay empty of workloads? It owns the organization and can administer every account, and SCPs do not restrict it — so anything running there is maximum blast radius with no guardrail above it. Keep it to a tiny set of org-admin tasks. (SCS-C02.)

Q11. Cross-account access: an identity policy allows s3:GetObject but it’s denied. Why? Cross-account requires both sides to Allow: the caller’s identity policy and the resource (bucket) policy. If the bucket policy doesn’t also Allow the external principal, the call is denied. If the objects are KMS-encrypted, the key policy must also grant kms:Decrypt. (SAA-C03, SCS-C02.)

Q12. What does iam:PassRole control, and why does it matter? It governs whether a principal may hand a role to a service (e.g. attach an execution role to a Lambda/EC2). Without a scoped PassRole grant, launching the resource fails; granted too broadly, a user could attach a more privileged role and escalate — so scope PassRole to specific role ARNs. (SCS-C02.)

Quick check

1. What is the primary security/blast-radius boundary on AWS, and what do two accounts share by default?
2. In the policy-evaluation chain, what always wins, and can an SCP ever grant a permission?
3. On a role, which policy decides whether you can assume it at all — the trust policy or the permissions policy?
4. Why should employees use IAM Identity Center instead of IAM users?
5. A region-lock SCP denies everything outside ap-south-1 and the console breaks. What did it forget?

Answers

1. The AWS account is the boundary; two accounts share nothing by default — no IAM principal, VPC, or resource crosses the line unless you create the path.
2. An explicit Deny always wins; an SCP can only cap (subtract) — it never grants, so you still need an identity/resource Allow.
3. The trust policy — if it doesn’t name your principal, you’re denied on sts:AssumeRole before any permission is evaluated.
4. Identity Center issues temporary credentials (no long-lived keys), enforces MFA centrally, spans many accounts with permission sets, and makes offboarding one group edit.
5. It forgot to exempt global services (iam, sts, route53, cloudfront, support) with NotAction — they authenticate via us-east-1 and get blocked.

Glossary

Next steps

• AWS Control Tower Guardrails: Building a Secure Multi-Account Foundation — automate the account vending, OU baselines, and guardrails this article built by hand.
• AWS CloudTrail and Config: Audit and Compliance at Scale — the audit trail that tells you who did what and why a call was denied.
• AWS VPC, Subnets and Security Groups Explained — the network boundary that complements the account boundary.
• AWS Regions and Availability Zones: Resiliency from the Ground Up — where your accounts and resources physically live, and how region-lock SCPs interact with it.
• AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose? — the workloads that run inside the accounts you just isolated, each carrying an execution role.