Guardrails an account inherits on day one

The problem

Guardrails had grown account by account: the same rule copied with a different list of ARNs, some accounts at the five-policy quota, new accounts with no guardrails at all. Nobody could say which controls an account actually had without reading every policy on its path.

The approach

One rule lives in one place, at the highest level where it is true. Root protects the audit trail, the root user and the tags that grant privilege. The workloads OU requires permission boundaries, locks regions, enforces IMDSv2 and encryption, and removes interactive host access. Production adds write-path guards: only CI publishes images, only autoscalers start instances, only code changes cluster access and network edges. A resource control policy keeps S3, Secrets Manager and KMS closed to principals outside the organization and to plain HTTP.

Changing guardrails safely

SCPs have no audit mode, so a broken one is found by an outage. Every change passes offline tests for quota, Deny-only content and break-glass exemptions, then a replay of ninety days of CloudTrail against the candidate policy lists every principal it would have denied. New policies attach alongside the old ones for 48 hours before anything is removed, OU by OU, production last.

What changed

Dead and duplicated policies went first, cutting the custom set by a third with no change in effective access. The target layout takes it from nineteen policies to six and from thirteen account-level attachments to one deliberate exception, rolled out OU by OU. The dry run has already paid for itself: it caught a change that would have stopped node autoscaling in production before it shipped.

Described as a pattern: names, numbers of systems and identifiers from the environments where this was built are left out.