AWS Organizations and SCPs: Guardrails Before Permissions

Somebody created an account, left it outside the organisation, and it was mining cryptocurrency for eleven days before anyone noticed.

That is the incident that convinces people to adopt AWS Organizations, and it is a fine reason. It is just not the main one. The main one is subtler: IAM is very good at answering "can this principal do this," and it is structurally incapable of answering "can this account do this, even if the person inside it has full admin."

Because the answer to the second question, without guardrails, is always yes.

SCPs are a ceiling, not a grant

A service control policy attaches to an organisational unit or an account. It does not give permissions — it removes the possibility of a permission. If an SCP does not allow an action, no principal in that account can perform it, regardless of what their identity policy says.

That inversion is the whole idea, and it is why SCPs catch the class of mistake IAM is blind to. A leaked root credential, a well-meaning admin, a compromised CI role — none of them can exceed a ceiling that no identity policy controls.

Two practical consequences:

• An SCP with no Allow for an action disables it entirely, including for the account root user. The first team that discovers this does so during an incident.
• SCPs never grant. An account with a permissive SCP and no permissions at all can still do nothing. You still need IAM; SCPs only bound it.

The evaluation order that confuses everyone

Requests are evaluated roughly like this:

Request → SCP allow/deny (org level)
        → permission boundary
        → identity policy allow/deny (the role/user)
        → session policy, resource policy
        → explicit Deny wins at every layer

The part people get wrong is the first line. If the SCP does not contain an Allow for s3:GetObject, the request is dead before any identity policy is read — and the error message will be an AccessDenied that mentions neither SCPs nor the org at all. Hours disappear into IAM troubleshooting for a policy attached three levels up.

The five I attach everywhere

These are preventive, cheap, and almost never regretted:

1. Deny leaving the organisation — stops unattachments and stops data leaving the boundary entirely.
2. Deny disabling CloudTrail in any region, including through the console.
3. Deny disabling GuardDuty or Config. Detection you can switch off is decoration.
4. Deny root-user actions other than the few you genuinely need. Nobody needs root for anything routine.
5. Region restriction on the accounts that should only ever run in approved regions.

Then there is the one everyone writes first: deny everything outside your approved region list, and deny the services you have decided not to use. This is where the VPC work and the org boundary meet — an account cannot accidentally grow a public footprint in a region you have never billed for.

Where SCPs will burn you

They apply to the account root user too. The classic outage is a region-restriction SCP blocking a break-glass action that only root can perform. Test your emergency paths against your guardrails while it is boring.

They are not a substitute for structure. A single flat OU with fifteen SCPs is worse than three OUs with two each. Structure the tree by how the accounts actually behave — production, staging, security, sandbox — and attach policy by membership rather than by hand.

They hide from the console's helpful defaults. New AWS services are not automatically covered by a Deny you wrote last year. Review the SCP set quarterly, the same way you would review an allowlist.

They will not catch a mistake inside a permitted action. Deleting the correct bucket in the correct account is fully allowed. Guardrails bound the blast radius; credential hygiene and not locking yourself out handle the rest.

Summary

IAM governs principals; SCPs govern what an account is capable of at all, which is the boundary leaked credentials and over-broad admin roles cannot cross. Attach the five preventive policies, attach them by OU rather than by account, and — critically — test your break-glass procedures against them before you need them. Guardrails that have never been exercised are just constraints waiting to become an incident.