Step 1 — Multi-Account Strategy

If you passed the Associate exam, you already know how to secure a single account: IAM policies, MFA, maybe a bucket policy or two. The Professional exam throws that mental model out and replaces it with a harder question — how do you run governance, networking, and security consistently across fifty accounts instead of one? This step is about that shift in altitude. Nothing here is a new service exactly; it’s the same primitives applied at a scale where manual processes collapse.

Why a Single Account Stops Working

A single AWS account is a blast radius. Put your production database, your dev sandbox, and your data science team’s experimental Lambda functions in the same account, and a misconfigured IAM policy in one workload can expose another. Enterprises separate accounts along a few common boundaries: environment (prod/staging/dev), business unit, compliance scope (PCI, HIPAA), and blast-radius isolation for anything customer-facing versus internal.

The problem multi-account strategy actually solves isn’t technical isolation — you could get some of that with VPCs and IAM inside one account. It’s billing isolation, policy isolation, and API rate-limit isolation. A runaway Lambda in one account can’t exhaust another account’s service quotas. A compromised credential in the marketing account can’t touch the payments account. That’s the entire argument, and the exam expects you to reason from it rather than recite it.

AWS Organizations and the Account Hierarchy

AWS Organizations is the root construct. It gives you a management account (never run workloads here — this is a lesson every organization learns the hard way, usually after an audit) and an organizational unit (OU) tree beneath it.

Management Account (billing + org policies only)
│
├── OU: Security
│   ├── Log Archive Account
│   └── Audit / Security Tooling Account
│
├── OU: Infrastructure
│   ├── Network Account (Transit Gateway, Direct Connect)
│   └── Shared Services Account (AD, CI/CD tooling)
│
├── OU: Workloads
│   ├── OU: Production
│   │   ├── Payments-Prod
│   │   └── Catalog-Prod
│   └── OU: Non-Production
│       ├── Payments-Dev
│       └── Catalog-Dev
│
└── OU: Sandbox
    └── Individual dev sandbox accounts (auto-expiring)

Notice the pattern: OUs mirror how you want to apply policy, not how your org chart looks. If Payments-Prod and Catalog-Prod need identical SCPs, they belong in the same OU regardless of which team owns them. Getting this backwards — modeling OUs after team structure — is the single most common real-world (and exam) mistake.

Control Tower: Landing Zones Without the Manual Toil

AWS Control Tower automates what used to be a bespoke “landing zone” build: it stands up the Organizations structure, the Log Archive and Audit accounts, baseline SCPs called guardrails, and an Account Factory for provisioning new accounts in minutes rather than weeks.

Guardrails come in two flavors, and the exam loves testing which is which:

Guardrail Type	Mechanism	Example	Can be bypassed?
Preventive	Implemented as an SCP	Deny disabling CloudTrail	No — enforced at the API level
Detective	Implemented as an AWS Config rule	Alert if S3 bucket becomes public	Yes — it flags after the fact, doesn’t block

A subtlety worth internalizing: Control Tower does not replace AWS Organizations, it sits on top of it and manages it declaratively. If your organization already has a hand-rolled multi-account setup, Control Tower can adopt existing OUs and accounts through enrollment, but the exam will test whether you know some legacy configurations (custom SCPs that conflict with mandatory guardrails) need to be reconciled first.

Account Factory for Terraform (AFT) extends this further for teams that want infrastructure-as-code account provisioning rather than the built-in console-based Account Factory — expect this to appear as the answer when a question specifies a customer already standardized on Terraform.

Service Control Policies: The Permission Ceiling

SCPs are the single most misunderstood concept coming from the Associate exam, because Associate-level IAM never needed to discuss ceilings — only grants. An SCP attached to an OU does not grant any permission. It defines the maximum permissions available to every account beneath it, including the management account’s own IAM policies layered on top.

Effective Permission = SCP allows it   AND   Identity policy allows it
                        (ceiling)             (grant)

If the ceiling says no, no identity policy in that account — not even one written for the root user of the account — can grant it back. This trips people up because they assume “root user can do anything.” Root can do anything the SCP ceiling permits, full stop.

Common SCP patterns tested on the exam:

Deny leaving the Organization — prevents an account from being pulled out and used to bypass governance
Deny disabling CloudTrail, Config, or GuardDuty — protects audit trail integrity
Region restriction — deny any action outside an approved list of Regions, common for data residency
Deny root user actions entirely except break-glass scenarios

One frequent exam trap: SCPs never affect the management account. If you need a guardrail to apply everywhere including the management account, you must design compensating controls (IAM permission boundaries, resource policies) because SCPs simply don’t reach that account.

Multi-Account Networking: Transit Gateway and RAM

Once you have dozens of accounts, each with its own VPCs, you need them to talk to each other and to on-premises without building a mesh of VPC peering connections that becomes unmanageable past a handful of VPCs (peering doesn’t transit, so a full mesh of N VPCs needs N(N-1)/2 connections).

Transit Gateway (TGW) is the hub-and-spoke answer:

                     ┌─────────────────────┐
                     │   Transit Gateway    │
                     │   (Network Account)  │
                     └──────────┬───────────┘
          ┌───────────┬─────────┼─────────┬───────────┐
          │           │         │         │           │
     ┌────▼───┐  ┌────▼───┐┌────▼───┐┌────▼───┐  ┌────▼────┐
     │ VPC-A  │  │ VPC-B  ││ VPC-C  ││ VPC-D  │  │ Direct   │
     │ (Prod) │  │ (Dev)  ││(Shared)││(Sandbox│  │ Connect  │
     └────────┘  └────────┘└────────┘└────────┘  │ (on-prem)│
                                                   └──────────┘

TGW route tables let you segment traffic — production VPCs might only route to the Shared Services VPC and Direct Connect, never directly to Sandbox, even though they all attach to the same gateway. This is the multi-account equivalent of subnetting: the physical hub is shared, but logical reachability is controlled per route table association.

Resource Access Manager (RAM) is what makes this cross-account without duplicating infrastructure. You create the Transit Gateway once, in the Network account, and share the attachment permission via RAM to every other account in the Organization. Those accounts then attach their own VPCs to a TGW they don’t own and never had to have created for them individually. RAM also shares subnets (VPC sharing), License Manager configurations, and Route 53 Resolver rules — any exam question about “avoid duplicating this resource in every account” should make you think RAM first.

For global footprints, TGW peering (now inter-Region peering) connects Transit Gateways across Regions, and this is how a “multi-Region, multi-account” network gets built without Direct Connect or VPN in every Region pair.

Centralized Logging and Security Baseline

A landing zone isn’t complete without a place where security signal actually lands. The standard pattern centralizes three things into the Security OU’s dedicated accounts:

Log Archive account — CloudTrail organization trail (one trail, applies to every account automatically, can’t be disabled by member accounts), VPC Flow Logs, S3 access logs, all delivered to a bucket this account owns exclusively
Audit/Security Tooling account — GuardDuty delegated administrator, Security Hub aggregation, IAM Access Analyzer organization-wide findings

The delegated administrator pattern deserves attention: rather than every account independently enabling GuardDuty and nobody actually reading the findings, you designate one account (usually in the Security OU) as the GuardDuty/Security Hub administrator. Every member account’s findings automatically flow there. This is how a security team of five people monitors an organization of three hundred accounts without opening three hundred consoles.

An organization-wide CloudTrail trail, once created from the management account with the “apply to organization” flag, cannot be turned off or modified by member accounts — this pairs directly with the “deny disabling CloudTrail” SCP guardrail mentioned earlier, giving you both a policy-level and a technical-level lock on audit continuity.

Exam Focus: What Questions Test From This Step

Distinguishing SCPs (permission ceilings, deny-based, never grant) from IAM identity policies (grants)
Recognizing that SCPs do not apply to the management account, and designing compensating controls for that gap
Preventive guardrails (SCP-based, blocking) versus detective guardrails (Config-based, alerting after the fact)
Why OUs should mirror policy requirements, not organizational charts
Transit Gateway hub-and-spoke design versus VPC peering mesh limitations, including route table segmentation
Resource Access Manager as the mechanism for cross-account resource sharing without duplication
Delegated administrator pattern for GuardDuty/Security Hub across an Organization
Organization-wide CloudTrail trail behavior and why member accounts cannot disable it
Choosing between Control Tower’s built-in Account Factory and Account Factory for Terraform based on stated customer tooling