AWS Architecture Series #39 — The account the guardrails cannot reach

Business Challenge

A company has done the multi-account work properly. There are eighty accounts under an organisation, arranged into OUs by environment and business unit, and the SCPs at each level were written carefully and tested on one account at a time. The platform team can answer, precisely, what any account is permitted to do.

Three things also run in the management account. The build pipeline, because that is where the organisation was created and the first CI role was made there in week one. A shared VPC with a Direct Connect attachment, because networking was set up before the account structure settled. And the cost reporting stack, because Cost and Usage Reports are configured from the payer account and it seemed natural to keep the Athena tables beside them.

Every one of those workloads is outside every guardrail the company wrote. Not partially, not in edge cases: SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization. The deny on cloudtrail:StopLogging, the Region restriction, the block on creating IAM users — none of them apply to the pipeline role that can already assume its way into every account in the estate.

Nobody made a mistake here. Each of those three decisions was locally reasonable, made before the guardrails existed, and never revisited because nothing ever failed. That is the characteristic of this problem: the management account does not behave differently in any way you can observe. It behaves differently only in what it would have stopped.

Architecture

AWS states the design rule and the reason in the same breath: we recommend that you use the management account and its users and roles for tasks that must be performed only by that account. Store all of your AWS resources in other AWS accounts in the organization and keep them out of the management account. And then, explicitly, the why — one important reason to keep your resources in other accounts is because Organizations service control policies do not work to restrict any users or roles in the management account.

What the guardrail does reach, which is more than people expect

Inside a member account, an SCP is close to absolute. An SCP restricts permissions for IAM users and roles in member accounts, including the member account's root user, and if a permission is blocked at any level above the account, a user or role in the affected account can't use that permission, even if the account administrator attaches the AdministratorAccess IAM policy.

That is a genuinely strong property and it is the whole value proposition: a local administrator, acting in good faith or otherwise, cannot exceed the ceiling. It is also why the contrast with the management account is so sharp. The same policy that binds a member account's root user does not bind an ordinary IAM role in the management account.

The three other things SCPs do not reach

The management account exemption is the largest, but it is one of four. SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs. There is a short list of root-user tasks outside their scope — Enterprise support registration, CloudFront trusted signer functionality, reverse DNS configuration. And SCPs don't affect resource-based policies directly, and they don't affect users or roles from accounts outside the organization, which is the gap that resource control policies were introduced to close.

Taken together, these define what an SCP is: a ceiling on principals your organisation manages. Not a ceiling on your resources, not a ceiling on AWS's own integrations, and not a ceiling on the account doing the ceiling-setting.

Delegated administration, and the fact that makes it worth doing

The remedy AWS recommends is to move the work out: where possible, we recommend delegating responsibilities and services outside the management account, and you can register multiple delegated administrators for services that support this functionality. For Organizations itself, from the organization's management account, you can delegate policy management for Organizations to specified member accounts to perform policy actions that are by default available only to the management account.

Here is the sentence that decides whether delegation is worth the setup, and it reads at first like a limitation: SCPs apply to member accounts that are designated as delegated administrators.

It is not a limitation. It is the entire point. Delegating SCP management to a security tooling account does not create a second exempt account — it moves privileged work from an account where guardrails are impossible into an account where they apply in full, root user included. The alternative is not "the same work, governed less"; the alternative is doing that work in the management account, where nothing you write can constrain it.

Why This Architecture Holds Up

It makes the recovery path a design input rather than an afterthought

A control plane that can lock itself out is a control plane nobody will use aggressively. Because the management account is exempt, an SCP that turns out to be catastrophically wrong is always removable, from a known place, by a known identity. That is what allows a platform team to write a genuinely restrictive root-level policy instead of a cautious one — and cautious guardrails are the ones that do not prevent anything.

The blast radius of the exemption is a function of one number

How much damage the exemption can do is exactly proportional to how much lives in the management account. That is unusual and useful: most security properties are hard to measure, and this one is a resource count. An organisation whose management account contains an organisation, a billing configuration and nothing else has an exemption with almost nothing behind it.

Delegation scales where management-account access does not

There is only one management account, and access to it is the highest-value credential in the estate — so the number of people who can hold it is small and the queue for their attention is not. Delegated administration converts that into per-account access, in accounts that are governed, with as many delegated administrators as there are services that support them. The bottleneck stops being a single account's access list.

It separates the invoice from the architecture

A quieter benefit AWS names directly: separating your resources from your management account also helps you to understand the charges on your invoices. The management account is the payer, so its own consumption is mixed into the account that aggregates everyone else's. Workloads there are the hardest spend in the organisation to attribute, and the least likely to be noticed growing.

Key Architecture Decisions

What belongs in the management account, and what does not

Reference: the baseline SCP, and where to attach it

The policy AWS now attaches for you on new console-created organisations. If yours predates 10 July 2026 or was created by API, this is the one to add first — it protects the precondition every other guardrail depends on, which is that the account is still in the organisation.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyLeaveOrganizationAndCloseAccount",
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization",
                "account:CloseAccount"
            ],
            "Resource": "*"
        }
    ]
}

Note the shape: an explicit Deny, attached at the root, with no conditions. It is the rare guardrail that needs no exceptions, because leaving the organisation is never something a member account should do on its own initiative — and it is evaluated in the deny sweep, so nothing in any member account can override it. Removal stays possible from the management account, which is exactly the escape hatch this whole post is about.

Closing Thought

Most security architecture is about drawing boundaries and then verifying that things sit on the correct side of them. The management account is unusual because it is a boundary with a hole in it, the hole is deliberate, and no amount of policy will close it. What is left to decide is not whether the hole exists but how much you put behind it.

That reframes the work in a useful way. There is no clever SCP to write here, no condition key that fixes it, and no configuration to review annually. There is an inventory, and the job is to make it shorter. An organisation whose management account holds an organisation and a billing relationship has an exemption that grants an attacker almost nothing; one that also holds the deployment pipeline has an exemption that grants them the estate.

The question to ask of anything running in the management account: if every guardrail we wrote did not exist, would I still be comfortable with this? For that account, the guardrails genuinely do not exist. The answer has to stand on its own, and for most things it does not — which is the answer.

Official AWS Reference

• AWS Documentation — Service control policies (SCPs)
• AWS Documentation — Best practices for the management account
• AWS Documentation — Default security controls in AWS Organizations
• AWS Documentation — Delegated administrator for AWS Organizations
• AWS Documentation — Resource control policies (RCPs)
• AWS Documentation — AWS services that you can use with AWS Organizations