Day 4 - AWS Organizations, SCP, Control Tower: The Skeleton of Multi-Account Governance

📚 Case study: In 2019, a fintech startup operating in a single account had a developer accidentally delete the prod RDS. The same IAM Role held permissions in both dev and prod. Had the accounts been separated, dev-account credentials couldn't even have touched the prod RDS. After this incident, the company adopted per-environment account separation as its standard. A similar case is the 2017 GitLab.com incident — a human error where an operator deleted the prod DB instead of the backup. On AWS, if prod and backup live in the same account, the same accident is possible with a single IAM mistake.

💡 Related theory: Separation design that minimizes blast radius is a core SRE principle, emphasized in the "Embracing Risk" chapter of the Google SRE Book. The concept originates from the military's "compartmentalization" (information compartmentalization) — bulkhead design so that a breach in one part doesn't spread through the whole system. AWS account separation is the strongest implementation of this in the cloud domain.

The Structure of Organizations

Organizations is a service that groups multiple AWS accounts into a tree structure.

[ Management Account (root) ]
        │
        ├── OU: Security
        │     ├── Account: Log Archive
        │     └── Account: Audit
        ├── OU: Workloads
        │     ├── OU: Prod
        │     │     ├── Account: prod-payments
        │     │     └── Account: prod-web
        │     └── OU: NonProd
        │           ├── Account: dev
        │           └── Account: staging
        └── OU: Sandbox
              └── Account: dev-individual-1

An OU (Organizational Unit) is a folder for accounts. Maximum tree depth is 5 levels. An account is subject to SCPs wherever it sits in the OU tree (a parent OU's SCPs are inherited by all children). Move an account's position in the tree and the applicable SCP set changes automatically. This property — "governance changes just by moving OUs" — is an AWS strength absent from other clouds' IAM.

💡 Related theory: Applying policies over a tree structure is nearly identical to Microsoft Active Directory's OU/Group Policy model. Just as GPOs in AD are inherited by OUs and combined by precedence (LSDOU: Local → Site → Domain → OU), AWS SCPs are inherited from parent OUs to children and combined with a deny-overrides algorithm. The "centralized logs + distributed workloads" pattern recommended by NIST SP 800-92 (Log Management) and SP 800-137 (Continuous Monitoring) is implemented precisely on this structure.

🔍 Going deeper: GCP's Folder/Organization hierarchy is a similar tree structure and supports IAM policy inheritance, but GCP is a union model where a child's stronger permission "adds" to the parent, whereas AWS SCP is an "intersection + deny override" model where a child can never become stronger. Same tree structure, opposite semantics. Azure Management Groups follow a deny-override pattern closer to AWS.

SCP: The Permission Ceiling for an Entire Account

An SCP (Service Control Policy) has the same syntax as an IAM policy but a different scope. It sets the permission ceiling at the account or OU level. An SCP doesn't "grant" permissions — it only "sets the limit."

This SCP means "usage of any region other than ap-northeast-2 and us-east-1 is forbidden." Even if a developer accidentally tries to launch an instance in ap-southeast-1, the SCP blocks it. No matter how much an IAM policy Allows, if the SCP Denies, it's over.

⚠️ Pitfall: SCPs do not apply to the Management account itself. This shows up often on the exam. It's one of the core reasons the Management account must not hold workloads. Being an account unprotected by SCPs, it carries the largest blast radius in an incident. One more pitfall — SCPs also partially don't apply to service-linked roles (e.g., AWSServiceRoleForOrganizations).

🔍 Going deeper: SCPs are operated with two strategies. The Deny List strategy (keep the default FullAWSAccess and Deny only what's forbidden) and the Allow List strategy (remove FullAWSAccess and keep only explicit Allows). Allow List is stricter but requires adding explicit allowances every time a new service launches, creating heavy operational burden. Most organizations use Deny List + core guardrails. Also, SCPs have limits of "up to 5MB" and "up to 5 per entity," making policy consolidation and modular design important.

📚 Case study: In 2020, a media company operating without SCPs had a junior developer randomly launch instances in every region outside us-east-1, and within a month the bill hit 4x the usual. With an SCP region restriction, the incident would have been impossible in the first place. After the incident, the company standardized a triple guard: "region restriction + monthly Sandbox account limits + Budgets alarms."

Control Tower: Automating the Landing Zone

Control Tower is a service that sets up everything we saw above automatically at once. Launched in 2019, it automatically creates the following:

• The Organizations structure (Management + Security OU + Sandbox OU)
• Automatic creation of Log Archive and Audit accounts
• Centralized CloudTrail (all accounts → Log Archive)
• Centralized Config (aggregated into the Audit account)
• IAM Identity Center integration
• Account Factory (self-service account provisioning)
• Guardrails: Predefined bundles of SCPs + Config Rules

Guardrails come in two kinds: Preventive (SCP-based, blocks in advance) and Detective (Config Rule-based, detects after the fact). For example:

Control Tower's value lies in "finishing in a few clicks the standard baseline that would take days to set up by hand." There's also a more sophisticated solution called Landing Zone Accelerator (LZA), an open-source offering that adds governance as CloudFormation code on top of Control Tower (official AWS Solutions).

💡 Related theory: The term "Landing Zone" itself was coined by AWS, meaning "the secure foundational environment that must be in place before a customer puts workloads on it." The analogy is that a runway must be ready before a plane can land on it. It's conceptually the same as ITIL's "Foundation Service Layer" and CIS Benchmark's "Baseline Configuration."

Account Factory and Service Catalog

Control Tower's Account Factory creates new AWS accounts from a standard template. It's exposed internally as a Service Catalog product, so dev teams can request accounts self-service. Each account is automatically placed in an OU, connected to IAM Identity Center permissions, and given baseline guardrails.

📚 Case study: In 2021, a Capital One affiliate received a request to "provision 50 accounts per week," and automated it in 30 minutes by adopting Control Tower Account Factory. Previously, operators had to configure IAM Identity Center permission sets, CloudTrail, Config, and GuardDuty one by one, taking 2-3 hours per account. After automation, the account provisioning SLA dropped from "1 week" to "10 minutes," and the ops team members shifted to other security work.

🔍 Going deeper: An extension called Account Factory for Terraform (AFT) launched in 2021. It makes Control Tower's Account Factory callable as a Terraform module, tying account creation and deletion into the PR review flow, GitOps-style. "Controlling account provisioning through code review" is becoming the standard pattern in large organizations.

RAM: Resource Access Manager

AWS RAM is what you use to share resources among a company's own accounts within Organizations. It shares VPC subnets, Transit Gateways, Route 53 Resolver Rules, License Manager configurations, and more with other accounts.

The most common pattern is the Networking account + Workload account split. Create the VPC and Transit Gateway in the Networking account and share subnets with Workload accounts via RAM, and every workload account uses the same network topology while the workloads themselves stay isolated. It's far simpler than cross-account VPC peering.

🔍 Going deeper: An account that receives a VPC subnet via RAM can create ENIs/EC2 directly in that subnet, but cannot touch the subnet's own routing or NACLs. That means network design and workload operations can be cleanly separated. This pattern is the heart of the "Networking account" concept. Note, however, that the cost of ENIs created in the shared VPC is paid by the ENI-owning account, while infrastructure costs like NAT Gateway and Transit Gateway fall to the Networking account — fail to agree on this cost split in advance and inter-departmental accounting disputes arise.

The Real Benefits of Consolidated Billing

Joining Organizations automatically enables Consolidated Billing. The effect is not mere invoice consolidation.

1. Volume discounts: Usage-based services like S3 and CloudFront aggregate usage across all accounts, entering larger discount tiers.
2. Reserved Instance/Savings Plan sharing: RIs/SPs bought in one account automatically apply to EC2 in other accounts (depending on settings).
3. Consolidated Cost & Usage Report: Analyze all accounts' costs in one place.
4. Free tier aggregation: A new account's 12-month free tier merges into the parent account's limits (caution — free tiers don't stack).

💡 Related theory: Consolidated Billing decouples the cloud's "shared resource pool" model from IAM boundaries. Accounts of the same company are fully isolated in IAM but pooled for costs, enjoying economies of scale. This is a variant of the "resource pooling" in the NIST cloud definition (SP 800-145). Even more interesting is the RI/SP sharing policy — turning off "RI Sharing" in the Organizations console makes each account operate RIs independently, used when you want to strongly separate "per-team cost accountability."

⚠️ Pitfall: Consolidated billing is automatic, but RI/SP sharing defaults to "shared" and turning it off requires separate configuration. Questions like "why is an RI our team didn't buy applying to our account's EC2 and messing up our accounting" come from here. On the exam it appears as questions asking "why one account receives another account's RI benefits."

Automating Account Provisioning: CloudFormation StackSets

When you want to deploy the same infrastructure identically to every account in a multi-account environment, you use CloudFormation StackSets. A single command deploys the same stack to all OUs or selected accounts.

SERVICE_MANAGED is the Organizations-integrated mode, deploying automatically when new accounts are added. With auto-deployment set to true, when an account enters the OU it's applied automatically. Internally, StackSets creates a separate Stack per account, but changes are managed in bulk at the StackSet level — this two-layer structure is confusing at first but powerful once familiar.

🔍 Going deeper: StackSets concurrency is configured via "Concurrency mode." STRICT_FAILURE_TOLERANCE halts everything when one account fails; SOFT_FAILURE_TOLERANCE tolerates failures up to a set ratio. When deploying to hundreds of accounts, use the latter so that transient failures in a few accounts (e.g., throttling) don't halt the whole run.

Wrapping Up

Organizations + SCP + Control Tower are the 3 axes of multi-account governance. SCP is the permission ceiling, Control Tower the automated best practices, RAM the cross-account sharing, and StackSets the bulk deployment. With these five pictured in your head, multi-account scenario questions solve themselves almost automatically. On the exam, when keywords like "dozens to hundreds of accounts," "self-service account provisioning," "region restrictions," or "centralized log aggregation" appear, you must be able to quickly map the scenario language to which of these tools is the answer.

The next article is the Week 1 summary and review.