Day 4 - Multi-Account Strategy: The Real Picture of Organizations, Control Tower, and IAM Identity Center

Reason 4: Compliance Requirements

Regulations like PCI-DSS, HIPAA, and FedRAMP require "isolating production workloads from other environments." IAM separation alone rarely satisfies auditors; a separate account is the most definitive isolation.

Reason 5: The Limits of IAM Policies

IAM policies struggle to express complex cross-team permissions. Using the account itself as the boundary reduces permission management to the simple model of "who can enter this account."

💡 Related theory: The essence of multi-account strategy is the bulkhead pattern. Made famous by the Resilience4j library, this pattern isolates components so that one component's failure doesn't propagate to others. Like a ship's bulkheads: even if one compartment floods, the others survive. An AWS account is the cloud-infrastructure version of that.

AWS Organizations — The Foundation of Multi-Account

AWS Organizations (launched 2017) is the service that manages multiple AWS accounts as a single entity. Core components:

Typical OU Structure (the AWS-Recommended Model)

Root
├── Security OU
│   ├── Log Archive Account (CloudTrail, Config log aggregation)
│   └── Security Tooling Account (GuardDuty, Security Hub administrator)
├── Infrastructure OU
│   ├── Network Account (Transit Gateway, Direct Connect)
│   └── Shared Services Account (DNS, AD, CI/CD)
├── Workloads OU
│   ├── Prod OU
│   │   ├── Prod-App-A Account
│   │   └── Prod-App-B Account
│   ├── Non-Prod OU
│   │   ├── Staging Account
│   │   └── Dev Account
└── Sandbox OU (personal experimentation)

This structure is the AWS-recommended best practice. When the exam presents a "which account should this go in" scenario, answer with this pattern as the baseline.

🔍 Going deeper: An SCP is a policy that only has effect on deny. Even if an SCP says Allow, that alone grants no permission — it means the SCP "permits" what IAM policies already grant. The real power of SCPs is Deny. For example, Deny ec2:RunInstances if region != ap-northeast-2 forces every account in that OU to be unable to launch EC2 outside the Seoul region. No matter how broad the IAM permissions, if the SCP blocks it, it cannot be done.

SCP Evaluation Order

AWS permission evaluation happens in this order:

1. Explicit Deny (a deny anywhere means immediate rejection)
2. SCP (rejected if it violates organization policy)
3. Permission Boundary (if present, rejected if it violates the boundary)
4. Session Policy (additional policy at AssumeRole time)
5. Resource-based Policy (S3 bucket policies, etc.)
6. Identity-based Policy (IAM user/role policies)

An explicit Deny anywhere in this chain means rejection; the request must pass all of them and have an Allow somewhere to be permitted.

⚠️ Pitfall: A common confusion is "I created an Allow policy in the SCP but it still doesn't work." An SCP is a guardrail, not a permission grant. Even if the SCP says Allow, permissions must be granted separately in IAM. Exam options like "granting permissions with SCP alone" are traps.

Control Tower — The Automation Wrapper Around Organizations

AWS Control Tower (launched 2019) is a landing zone service that sets up Organizations + IAM Identity Center + Config + CloudTrail + ... all at once. Use it when you want to "start with a best-practice OU structure from day one."

Control Tower's core trade-off:

• Pros: Rapidly sets up the standard structure; automatic governance for new accounts
• Cons: Hard to migrate an already-operating Organizations into it; only some regions supported

📚 Case study: A large enterprise spent six months trying to consolidate 50 existing AWS accounts into Control Tower. Existing SCPs, CloudTrail trails, and IAM policies conflicted with Control Tower's standards, making migration extremely complex. Lesson: if you already run multi-account, a PoC is mandatory before deciding to adopt Control Tower. For greenfield adoption, starting with Control Tower is much faster.

Core Composition of the Landing Zone

Accounts Control Tower creates automatically:

• Management Account (the Organizations root)
• Log Archive Account (central storage for all accounts' CloudTrail + Config logs)
• Audit Account (Security Hub, GuardDuty administrator + audit tooling)

And the OU structure:

• Security OU (Log Archive + Audit)
• Sandbox OU (personal experimentation)
• Additional OUs are created freely via Account Factory

Guardrails

Control Tower guardrails come in two kinds:

1. Preventive (SCP-based) — blocks the action. Example: "Prohibit deleting CloudTrail in the Log Archive account"
2. Detective (Config Rule-based) — detects violations and alerts. Example: "Alert when an S3 bucket becomes public"

Each guardrail is classified as mandatory, strongly recommended, or elective. New accounts get mandatory guardrails applied automatically.

🔍 Going deeper: The preventive-vs-detective trade-off is "automatability vs side effects." Preventive (SCP) blocks the action itself, so incident prevention is guaranteed, but a badly written one blocks legitimate work too (e.g., blocking all root logins — including emergency access). Detective detects after the fact, so side effects are fewer, but the incident has already happened. In practice: preventive for critical, detective for monitoring-grade concerns.

IAM Identity Center — The Definitive Answer for Multi-Account SSO

Formerly named AWS Single Sign-On (SSO), it was renamed IAM Identity Center in 2022. The core capability: "one login for access to all your accounts."

How It Works

[ IAM Identity Center flow ]

User → Identity Provider (Okta/AzureAD/AWS Directory)
         |
         ↓ SAML/SCIM
       IAM Identity Center (installed in the organization's management account)
         |
         ↓ AssumeRole (automatic)
       Permission Set Role in the Member Account

• Permission Set: One role + a set of policies. Examples: "AdminAccess," "ReadOnlyAccess," "BillingAccess"
• User/Group: Sourced from the Identity Provider (synchronized via SCIM)
• Account Assignment: Which user can enter which account with which permission set

From the user's perspective, logging in at https://.awsapps.com/start shows cards for every account+role they can access; clicking one enters that account's console. For the CLI, aws sso login obtains a token.

💡 Related theory: IAM Identity Center is essentially AssumeRole automation. When the user clicks a card, IAM Identity Center calls STS AssumeRole, obtains temporary credentials, and launches the console/CLI with them. Because all credentials are temporary (typically 1 to 12 hours), it is far safer than static IAM users.

IAM User vs IAM Identity Center

AWS explicitly recommends "use IAM Identity Center for new workloads." On the exam, "multi-account + SSO" scenarios almost always have IAM Identity Center as the answer.

⚠️ Pitfall: The misconception that "with IAM Identity Center, you no longer need IAM." Human users move to IAM Identity Center, but machine principals (EC2, Lambda, ECS tasks) still use IAM Roles. IAM is not going away.

Cross-Account Patterns — What the Exam Asks Most Often

The heart of multi-account is "how does one account access resources in another account." There are three patterns.

Pattern 1: STS AssumeRole (the most common)

[ Cross-Account AssumeRole ]

Account A (CI/CD)              Account B (Prod)
  IAM User/Role  ──AssumeRole──→  CrossAccountRole
   (sts:AssumeRole)                (trust policy: Account A)
                                   (permission: ECS deploy)

Account B's role explicitly states "trust Account A's ARN" in its trust policy. Account A's principal calls sts:AssumeRole to obtain temporary credentials and access Account B's resources.

ExternalId is for preventing the confused deputy problem. It is especially important when integrating with external SaaS (e.g., when Datadog or PagerDuty enters your account).

💡 Related theory: The confused deputy problem is a security issue discovered by Norm Hardy in 1988 — a vulnerability where "a privileged deputy performs an unprivileged party's request using its own privileges." In AWS, when integrating a SaaS, the SaaS's AWS account becomes the deputy accessing your resources; ExternalId provides isolation so that other customers of the same SaaS cannot access your resources through it.

Pattern 2: Resource-Based Policy (S3 bucket policies, SNS, KMS, etc.)

S3 buckets, SNS topics, and KMS keys can carry policies attached to the resource itself, explicitly allowing principals from other accounts.

Cross-account access is possible even without AssumeRole. However, only some services support it — S3, SNS, SQS, KMS, Lambda, and a few others.

Pattern 3: RAM (Resource Access Manager)

Some resources — VPCs, Subnets, Transit Gateways, License Manager — can be shared with other accounts via RAM. On the exam it frequently appears in "share a Transit Gateway across multiple accounts" scenarios.

CloudTrail Organization Trail — All Account Auditing in One Place

CloudTrail is per-account by default, but with an Organization Trail, the management account captures the API calls of every member account at once and stores them in a single S3 bucket. The Log Archive account is that bucket's owner.

[ Organization Trail flow ]

All Member Accounts → CloudTrail Events → Organization Trail → 
  → S3 Bucket in the Log Archive Account (immutable, MFA delete)
  → CloudWatch Logs (optional)
  → EventBridge (optional)

The essence of this architecture:

1. Single source of truth: Every account's API calls in one place
2. Tamper prevention: No one outside the Log Archive account can delete logs (enforced by SCP)
3. Search efficiency: Audit the entire organization with a single Athena query

📚 Case study: During an internal audit, a company investigated "who changed the prod IAM policies in the last three months," but each member account stored its CloudTrail separately, so manually collecting logs from 30 accounts took a week. After switching to an Organization Trail + Log Archive account, the same query finished in 10 minutes with Athena.

Multi-Account CI/CD Patterns — The Exam's Core Scenario

The most common multi-account CI/CD topology:

[ Hub-Spoke model ]

Shared Services Account (Hub)
  - CodeCommit / GitHub
  - CodeBuild
  - CodePipeline (orchestrator)
  - ECR (shared image registry)
  - S3 (artifact bucket, KMS encrypted)
        |
        ├─AssumeRole──→ Dev Account (Spoke)
        │                  - ECS/Lambda deployment target
        │                  - CrossAccountDeployRole
        |
        ├─AssumeRole──→ Staging Account
        │                  - same pattern
        |
        └─AssumeRole──→ Prod Account
                           - deploy after manual approval
                           - CrossAccountDeployRole (restricted)

Core security principles:

1. Pipelines in one place: Pipelines scattered across many places break consistency
2. Deployment permissions via cross-account roles: Spoke accounts trust the Hub's pipeline role
3. KMS key sharing: Share the artifact S3 bucket's KMS key with spoke accounts (via key policy)
4. Centralized logging: All deployment logs go to the Log Archive account

🎯 Scenario: The exam frequently asks, "a company runs separate dev/staging/prod accounts — where should CodePipeline live?" The answer: "in a separate Shared Services account, deploying into each environment account via AssumeRole." Putting a prod-only pipeline inside the prod account means ① the prod account's permissions become too powerful ② consistency across environments breaks ③ change management gets fragmented. Hub-Spoke is the standard.

SCPs in Practice

Frequently used SCP examples:

⚠️ Pitfall: In SCP example 1, excluding global services (IAM, CloudFront, Route 53) via NotAction is the key. If you don't exclude them, that account can't even create IAM resources and becomes inoperable. In exam options, "region restriction without excluding global services" is a trap.

Organizations via the CLI

New account creation is asynchronous and usually takes 5-10 minutes. Meanwhile, Control Tower's Account Factory applies the baseline.

Wrapping Up

Remember today's three pictures. First, multi-account is the standard — blast radius isolation, quota separation, and compliance requirements are its justification. Second, Organizations + Control Tower is the foundation — standard OU structure + landing zone + guardrails. Third, IAM Identity Center is the definitive answer for authentication/authorization, and cross-account resource access is solved by three patterns: STS AssumeRole + resource policies + RAM.

The next post wraps up Week 1: we'll comprehensively review the first week's material through 10 scenario questions.