AWS Organizations + IAM Identity Center: The ‘multi-account + access’ combo I use everywhere

#aws #cloud #iam #security

If you’re running more than a couple AWS accounts, two services show up again and again:

AWS Organizations: how you structure accounts and apply org-wide governance.

AWS IAM Identity Center (formerly AWS SSO): how humans sign in once and get the right access across those accounts.

Together, they’re the backbone of a clean multi-account setup: governance on top, access in the middle, workloads underneath.

Why multi-account is the default

One AWS account feels simple… until you have:

multiple environments (dev / staging / prod)
multiple teams
different compliance boundaries
and a real need for blast-radius control

A multi-account strategy gives you isolation by default, and AWS Organizations gives you the control plane to manage it all.

AWS Organizations:

Think of AWS Organizations as your “org chart” for AWS.

You get:

A management account (the top-level admin account for the org)
Member accounts (where workloads live)
Organizational Units (OUs) (folders to group accounts like Prod, Dev, Security, Sandbox)

Consolidated billing (aka “one bill, many accounts, also you can benefit from savings”)

Organizations lets you consolidate billing so you can:
receive a single bill
track costs per account
benefit from pooled usage/discount sharing across accounts (depending on the discount model)

This is where governance meets FinOps: you keep accounts separated, but you don’t fragment your billing.

“All features” mode
Organizations has an “all features” mode that unlocks deeper governance controls. Most real-world orgs end up enabling it because it’s required for advanced policies like SCPs.

The real power: Service Control Policies (SCPs)

SCPs are guardrails.
A simple mental model:

IAM policies in an account say “what can this principal do?”
SCPs say “what is this account (or OU) allowed to do at all?”

So even if someone has AdministratorAccess in an account, an SCP can still block certain actions (like disabling CloudTrail, changing regions, or deleting security tooling).

Important nuance: SCPs are not permission grants. They only limit.

Beyond SCPs: other org policies you should know

Organizations supports additional policy types that help standardize at scale, like:

Tag policies (enforce tag keys/values)
Backup policies (baseline backup rules)
AI services opt-out policies (control data usage for certain AI services)

If you’re building a platform, these are your “consistency levers”.

Permission boundaries (the missing middle layer)

SCPs are great for account/OU-wide guardrails, but they apply to everyone in that scope.

When you need guardrails for specific IAM roles/users (especially roles that can create other roles/policies), use IAM permission boundaries.

A permission boundary is a managed policy that sets the maximum permissions an IAM user or role can ever have—no matter what identity-based policies you attach later.

Effective permissions become the intersection of: identity-based policy ∩ permission boundary ∩ SCP (and an explicit deny anywhere wins).

Where it shines:

Delegating IAM to teams safely (e.g., allow developers to create roles, but only within an approved boundary).
Preventing privilege escalation in “self-service” environments.

IAM Identity Center: how humans access all those accounts

IAM Identity Center is what you use when you want:

one place for users to sign in
centralized assignments across accounts
consistent role patterns without hand-crafting IAM roles everywhere

Permission sets = reusable access templates

Permission sets are the core concept.

They’re basically “role recipes” you can stamp across accounts:

ReadOnly
PowerUser
Billing
SecurityAudit
PlatformAdmin (careful with this one)

When you assign a permission set to a user/group for an account, Identity Center provisions the corresponding roles in that account and keeps them aligned when you update the permission set.
Identity sources: where your users live

You can plug Identity Center into:

its built-in directory
Active Directory
an external identity provider (often SAML for SSO, SCIM for provisioning)

Pick what matches how your company already manages identities.

How Organizations + Identity Center fit together

This is the pattern I see most:

Use Organizations to create/organize accounts into OUs (Prod, NonProd, Security, SharedServices).
Apply SCP guardrails at the OU level (strong in Prod, relaxed in Sandbox).
Use Identity Center permission sets to standardize human access.
Assign access by groups, not individuals (e.g., Developers, SRE, Security, Finance).
Optionally use delegated administration so a non-management account can administer Identity Center day-to-day (common in a dedicated “Identity” or “Shared Services” account).

That’s how you keep the management account locked down while still enabling operational ownership.
A practical baseline (what I’d implement first)

If I’m starting from scratch, I usually do this in order:

Create an Organization + enable all features.
Design OUs: Security, Infrastructure/Shared, Prod, NonProd, Sandbox.
Add SCPs:
- deny leaving the org (optional but common)
- protect logging/security services
- restrict regions if required
Enable IAM Identity Center.
Create permission sets:
- ReadOnly
- DeveloperPowerUser (no IAM)
- OpsAdmin (tightly controlled)
- SecurityAudit
Assign by groups to the right accounts/OUs.
Common mistakes (that hurt later)
Putting workloads in the management account.
Treating SCPs like IAM (they don’t grant permissions).
Giving broad permission sets and trying to “fix it later”.
Assigning access directly to users instead of groups.
No OU strategy → you end up with “policy spaghetti”.