← Design Secure Architectures

▶ Play from here · 270 min

Starts this lesson and continues through 24 more to the end of certification prep.

Multi-account guardrails

Why this lesson matters

Task statement 1.1 asks for skills in "Designing a security strategy for multiple AWS accounts (for example, AWS Control Tower, service control policies [SCPs])" and "Access controls and management across multiple accounts".

Exam questions in this area are nearly always the same shape: a company has many accounts, a requirement that must hold everywhere, and four options — an SCP, an IAM policy applied everywhere, a Config rule, or a custom Lambda. The answer usually hinges on one distinction: is the requirement a ceiling, or is it a grant? And on one list: the things an SCP cannot restrict.

What an SCP is, precisely

"SCPs offer central control over the maximum available permissions for the IAM users and IAM roles in your organization." — SCPs, verified 2026-09-21

And, twice on the same page in case you missed it:

"SCPs do not grant permissions to the IAM users and IAM roles in your organization. No permissions are granted by an SCP."

"An SCP never grants permissions. Instead, SCPs are access controls that specify the maximum available permissions for the IAM users and IAM roles in your organization."

Two gating facts before you can use them at all:

• All features must be enabled. "SCPs are available only in an organization that has all features enabled. SCPs aren't available if your organization has enabled only the consolidated billing features."
• Users still need IAM permissions. "A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions."

The five things SCPs cannot restrict

This is the list. Learn it — it converts several exam questions into one-glance answers, and it is also the list that explains real incidents.

From "Tasks and entities not restricted by SCPs" (verified 2026-09-21), you can't use SCPs to restrict:

1. Any action performed by the management account. Stated three times on the page: "SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization."
2. Any action performed using permissions attached to a service-linked role. "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."
3. Registering for the Enterprise support plan as the root user.
4. Providing trusted signer functionality for CloudFront private content.
5. Configuring reverse DNS for a Lightsail email server or EC2 instance as the root user.

Plus tasks on a handful of AWS-related services the page lists (Alexa Top Sites, Alexa Web Information Service, Amazon Mechanical Turk, Amazon Product Marketing API).

⚠️ Numbers 1 and 2 are the ones that matter. They have a direct architectural consequence: run no workloads in the management account. If you do, they sit above your entire guardrail model and no SCP will contain them. This is why AWS Control Tower creates separate accounts rather than building in the management account — and why "put the security tooling in the management account" is a wrong answer even though it sounds tidy.

Two more scoping facts from the same page:

• SCPs restrict "the member account's root user" too. The account root user is not an escape hatch from an SCP — unlike the management account, which is.
• "If both a permissions boundary (an advanced IAM feature) and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action." Three intersections stacked. Lesson 1's arithmetic, applied.

Allow-lists, deny-lists, and FullAWSAccess

This is the mechanic most people get wrong, so read the quotes rather than the summary.

Allow requires an explicit allow at every level:

"For a permission to be allowed for a specific account, there must be an explicit Allow statement at every level from the root through each OU in the direct path to the account (including the target account itself). This is why when you enable SCPs, AWS Organizations attaches an AWS managed SCP policy named FullAWSAccess which allows all services and actions. If this policy is removed and not replaced at any level of the organization, all OUs and accounts under that level would be blocked from taking any actions." — SCP evaluation

Deny needs only one level:

"For a permission to be denied for a specific account, any SCP from the root through each OU in the direct path to the account (including the target account itself) can deny that permission."

So the asymmetry is: allow is an AND down the whole path; deny is an OR down the whole path.

That asymmetry is why the deny-list strategy is the default in practice. You leave FullAWSAccess attached everywhere, and you add Deny statements for the things that must never happen. AWS puts it as: "Deny statements are a powerful way to implement restrictions that should be true for a broader part of your organization or OUs because when they are applied at the root or the OU-level they affect all the accounts under it."

And it warns against the opposite: "Relying solely on allow statements and the implicit deny-by-default model can lead to unintended access, because broader or overlapping Allow statements can override more restrictive ones."

⚠️ The single most dangerous SCP operation is detaching FullAWSAccess. AWS says it in a boxed note: "You should not remove the FullAWSAccess policy unless you modify or replace it with a separate policy with allowed actions, otherwise all AWS actions from member accounts will fail." Not "some actions". All of them.

AWS's worked scenario 3 is the cleanest illustration: when the root has only a Deny statement and no FullAWSAccess allow, "all member accounts get no service access". A deny-only SCP at the root, with the allow removed, is an organization-wide outage.

The canonical deny-list SCP from the docs, and a good one to be able to write from memory:

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

Testing, and the order to do it in

"AWS strongly recommends that you don't attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key services."

The documented ways to work out what an account actually uses before you restrict it:

• Service last accessed data in IAM — visible for an Organizations entity or policy in the Organizations section of the IAM console when signed in with management account credentials.
• CloudTrail, to log service usage at the API level.

Then use the same data to tighten: "The service last accessed data in IAM tells you which AWS services are allowed by the SCP but are never used. With that information, you can update the SCP to deny access to services that you don't need."

The quotas, and the one people get wrong

From Quotas and service limits for AWS Organizations, verified 2026-09-21:

⚠️ The default account limit is 10, not unlimited. A new organization cannot onboard 40 accounts without a quota increase, and AWS notes "Newly created accounts and organizations might experience a quota below the default of 10 accounts." Only the management account can request the increase.

⚠️ SCP size is 10,240 characters; RCP size is 5,120. These get confused constantly, in both directions. The console strips white space for you, but the CLI and SDK do not: "If you save the policy using an SDK operation or the AWS CLI, then the policy is saved exactly as you provided and no automatic removal of characters occurs." So the same policy can fit via the console and fail via CI — a genuinely nasty, genuinely real failure.

Two more worth noting: inherited policies don't count against attachment limits ("Policies that affect an OU or account by inheritance do not count against these limits"), and Organizations is global but "physically hosted in the US East (N. Virginia) Region (us-east-1). Therefore, you must use us-east-1 to access these quotas".

Where Control Tower and IAM Identity Center fit

The exam guide names both. What I can state from sources fetched for this lesson is limited, so here's the honest boundary:

• Control Tower's account limit is 10,000 and is not adjustable, per the Organizations "Limits by AWS service" table (verified 2026-09-21). The same table gives IAM Identity Center 7,000 accounts, adjustable.
• Beyond that, I did not verify Control Tower's control library, landing-zone structure or guardrail types against a fetched page for this lesson. Read docs.aws.amazon.com/controltower/latest/userguide/ before relying on specifics, and treat any claim about "mandatory vs strongly recommended vs elective" controls as unverified here.

What you can safely reason about for the exam is the shape: Control Tower builds and governs the multi-account landing zone (it creates the OUs and accounts and applies controls); Identity Center is where workforce identities get mapped to permission sets across those accounts; and SCPs are the ceiling underneath both. If a question offers "an IAM user in each account" against "IAM Identity Center with permission sets", the second is the lower-overhead answer nearly every time.

Check yourself

1. A requirement says "no account may disable CloudTrail". SCP or IAM policy?
2. You attach an SCP to the root that denies s3:*, and detach FullAWSAccess from the root while you're there. What is the state of the organization?
3. An engineer in the management account deletes a production bucket that an SCP protects. How?
4. Your organization has 6 accounts and you need 30. What do you do first?
5. A policy passes in the console and fails in your Terraform pipeline with a size error. Why?

Answers

1. SCP. It's a ceiling — a thing that must be true everywhere regardless of what account admins grant themselves. An IAM policy is a grant, and an account admin can change it.
2. Every member account can do nothing. Removing FullAWSAccess with no replacement allow means there is no explicit Allow at the root, and allow requires an explicit allow at every level. AWS's scenario 3 exactly: "all member accounts get no service access."
3. Because SCPs don't apply to the management account. This is the argument for running no workloads there. (A service-linked role would be the other exception.)
4. Request a quota increase — the default maximum is 10 accounts per organization, and only the management account can ask. Doing anything else first wastes the day.
5. The console silently strips white space before saving; the CLI and SDK save the policy exactly as provided. Minify the JSON in the pipeline, or keep the policy well under 10,240 characters.

Teaching this section

• Open with the "cannot restrict" list, not with SCP syntax. The management-account and service-linked-role exceptions are what make the design decision (don't run workloads in the management account), and design decisions are what the exam scores.
• Demo: show FullAWSAccess attached at every level in a real organization, then talk through what detaching it at the root would do. Don't actually detach it.
• Best discussion prompt: "Write an SCP that allows only EC2 and S3 in the sandbox OU." Let them do it, then ask what happens to the accounts if they forget the root level. The allow-at-every-level rule only sticks once someone has been bitten by it.
• Watch for: the phrase "the SCP gives them access". Correct it every time, as in lesson 1.
• Timing: 25 min presented, 20 on the SCP-writing exercise. The exercise is the lesson.