Module 7: Detective Vs Preventive Guardrails

6. SCPs and multi-account, named

Description

This lesson names, without building, the step that naturally follows everything this module built: Service Control Policies really applied to an account hierarchy, orchestrated by AWS Organizations and, optionally, AWS Control Tower. This isn't a hidden omission — it's, precisely, a documented gap at the ecosystem level, not just this guide's, and this lesson explains exactly why Andes Cargo, as it exists today, doesn't need it yet.

Connection to the module

This module's lesson 2 already previewed half the vocabulary: an SCP is, conceptually, the same mechanism as a permission boundary (a ceiling, never a grant) applied at a different scale — a whole account, or several, instead of a single role. This lesson picks that comparison back up and extends it to the question that really matters for Andes Cargo: when, if ever, would it make sense to really build this?

Why this is an ecosystem-level gap, cited with its own source

src/paths/aws-cloud-ecosystem/VALIDACION.md — the same market audit that set the relative weight of every module in this guide since Module 1 — says it directly: "in-depth multi-account AWS (Organizations, Control Tower, Landing Zone built end to end) is a HIGH-priority gap in VALIDACION.md with no guide assigned yet in the ecosystem." This guide names the pattern — because it's the natural preventive guardrail that follows single-account IAM, this entire module's central theme — but doesn't build it, for two independent reasons, not just one:

LocalStack Hobby/Community doesn't fully support Organizations or Control Tower. Neither one appears confirmed in the free plan's coverage this entire ecosystem uses, the exact same reason this module's lesson 4 already explained for GuardDuty and Config.
Andes Cargo, as defined across this ecosystem's four guides, is a single AWS account (000000000000). Building an account hierarchy for a case that doesn't need one would mean inventing scope the case study never had — exactly the kind of over-engineering this guide avoids in every one of its earlier modules.

AWS Organizations: the structure that makes an SCP possible

An SCP doesn't exist in a vacuum — it needs, as a precondition, an organization. AWS Organizations' official documentation summarizes it this way: "AWS Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources. Using Organizations, you can create accounts and allocate resources, group accounts to organize your workflows, apply policies for governance, and simplify billing by using a single payment method for all of your accounts."

   MINIMUM STRUCTURE THAT WOULD MAKE AN SCP POSSIBLE (which Andes Cargo does NOT have today)

                    ┌───────────────────────────┐
                    │   Management Account        │
                    │   (the account that creates   │
                    │    the organization)          │
                    └─────────────┬─────────────┘
                                  │
              ┌───────────────────┼───────────────────┐
              ▼                   ▼                   ▼
      ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
      │  OU: Prod       │    │  OU: Staging   │    │  OU: Sandbox   │
      │  (SCP here:      │    │  (SCP here:     │    │  (SCP here:     │
      │   deny region      │    │   allow anything  │    │   deny costs      │
      │   outside           │    │   within           │    │   beyond a          │
      │   us-east-1)         │    │   staging)          │    │   budget)            │
      └────────┬─────────┘    └────────┬─────────┘    └────────┬─────────┘
               │                       │                       │
               ▼                       ▼                       ▼
      Andes Cargo's                Andes Cargo's           a developer's
      production account            staging account         test account

   Andes Cargo, TODAY: a single account (000000000000), no Management Account,
   no organization, no OUs — no SCP has anywhere to attach yet.

Each branch of this diagram — Prod, Staging, Sandbox — could have a different SCP, applied by AWS Organizations to every user and role in that branch at once, without anyone having to replicate the same rule account by account. It's exactly the same scaling principle you already saw in conftest (one rule, evaluated against any plan) and in Trivy/Checkov (one rule base, applied to any project) — just applied to whole accounts instead of code.

AWS Control Tower: the orchestration layer, not a new mechanism

It's worth one precision that avoids a common mistake: Control Tower isn't a policy mechanism separate from an SCP — it's an orchestration layer over Organizations. The official documentation confirms it: "AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour," and adds a precise definition of what it calls "controls": "A control (sometimes called a guardrail) is a high-level rule that provides ongoing governance for your overall AWS environment [...] Three kinds of controls exist: preventive, detective, and proactive."

Notice something that connects directly to this module's lesson 1: AWS's own documentation uses, word for word, the preventive/detective vocabulary that governs this entire guide — and adds a third category, proactive, worth naming even though this guide doesn't develop it: a Control Tower proactive control evaluates a resource before it's created, similarly to how conftest evaluates a plan (Module 4), but integrated directly into Control Tower's account-provisioning flow, not as a separate CI/CD step.

	AWS Organizations	Service Control Policies (SCP)	AWS Control Tower
What it is	The service that groups accounts and enables centralized policies	The policy mechanism — a ceiling applied to an account, an OU, or the entire organization	An orchestration layer over Organizations — automates creating accounts with SCPs and other controls already applied
Relationship between the three	Precondition for the other two	Lives inside Organizations	Uses Organizations and SCPs underneath, without being a new mechanism
In this guide	Named	Named (introduced in lesson 2, revisited here)	Named

When Andes Cargo would need this, and where it would live

This is the concrete criterion, not a generic "when it grows" answer: Andes Cargo would have a real reason to build this the day it stopped being a single account with a single environment. The most common market scenarios that justify taking that step — none present today in this ecosystem's case study — are:

Separating environments by account, not by tag or prefix. Today, Andes Cargo doesn't distinguish production from staging with any separate account — everything lives in 000000000000. If that separation ever came to exist, an SCP in the "Sandbox" OU could, for example, deny any iam:CreateUser outside a read-only role, without depending on every developer remembering not to create users in a test environment.
Isolating blast radius between teams or customers. If Andes Cargo ever operated infrastructure for multiple logistics customers (multi-tenant at the account level, not just the application level), one account per customer, governed by shared SCPs, would limit even the theoretical possibility of an incident in one customer's infrastructure touching another's resources.
Meeting a regulatory segregation requirement. Some compliance standards (not cited here because they don't apply to this guide's case study) explicitly require separate AWS accounts for certain data types — a requirement no policy within a single account, however well designed, can satisfy on its own.

When any of these scenarios applied, the mechanism that would solve the problem is exactly this lesson's: an organization with all features enabled, structured into OUs by environment or by customer, with SCPs attached to each OU — never replacing lesson 3's permission boundaries (which remain necessary within each account), but adding on as an extra layer, above them.

Common mistakes

Thinking an SCP replaces lesson 3's permission boundaries, instead of adding to them (wrong-hierarchy mistake). What happens: someone, after this lesson, assumes that if Andes Cargo ever built SCPs, AppServerRole's boundary (lesson 3) would stop being necessary. How to spot it: if your multi-account migration plan includes "remove the existing permission boundaries." How to fix it: AWS's own documentation already confirmed it in this module's lesson 2: "If both a permissions boundary [...] and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action" — they're independent layers that intersect, not one substituting for the other. An SCP protects at the account level; a boundary protects at the individual role level within that account; both remain necessary at once.

Confusing "Control Tower" with "a third type of policy," instead of an orchestration layer (vocabulary mistake). What happens: someone, reading about Control Tower's three types of "controls" (preventive, detective, proactive), assumes Control Tower introduces a technically new enforcement mechanism, distinct from SCPs. How to spot it: if your explanation of Control Tower never mentions that it relies on Organizations underneath. How to fix it: Control Tower automates applying controls that are, mostly, still SCPs (for the preventive ones) or other already-existing AWS mechanisms (Config for the detective ones) — its value isn't a new mechanism, it's the orchestration of creating a new account with those controls already applied from minute one, instead of configuring them manually every time.

Concluding "this guide doesn't cover multi-account" means nobody in the ecosystem covers it (ecosystem-scope mistake). What happens: someone, after reading this is a VALIDACION.md gap, assumes no future guide in this ecosystem will ever build it. How to spot it: if your conclusion is "multi-account simply isn't part of this ecosystem." How to fix it: VALIDACION.md explicitly documents it as a HIGH-priority gap with no guide assigned yet — an open design decision, not a permanent omission. It's exactly the same kind of honesty this guide practices at its own boundary (see Module 1, lesson 1): naming what's missing, precisely, instead of pretending the current scope already covers everything a reader might need.

Exercises

Exercise 1 — Decide whether each scenario justifies multi-account, using this lesson's criterion. For each one, decide whether it's a real reason for Andes Cargo to build Organizations/SCPs, or whether the problem is better solved with what this guide already built (M2-M7, a single account): (a) Andes Cargo wants the development team to not be able to touch the production Shipments table; (b) Andes Cargo starts operating separate infrastructure for a second logistics customer, with its own data; (c) Andes Cargo wants no role to have broader permissions than its code actually uses.

See solution

(a) Isn't, by itself, a reason for multi-account. This guide's Module 4 (no-destroy-shipments.rego) already solves exactly this problem within a single account, evaluating the plan before apply — no separate account is needed to block a specific destructive change. (b) Really is a valid reason, and one of the most common in practice: separating customers with their own data is exactly the "isolate blast radius between customers" scenario this lesson named — one account per customer, governed by shared SCPs, is the standard market pattern for this case. (c) Isn't a reason for multi-account. It's, literally, the problem Module 2 (trimming roles to least privilege) and this module's lesson 3 (permission boundaries) already solve within a single account — least privilege is an IAM policy design problem, not an account architecture one.

Exercise 2 — Explain the relationship between this lesson's three concepts without using any diagram. In two or three sentences, without drawing anything, explain the dependency relationship between AWS Organizations, SCPs, and AWS Control Tower.

See solution

A complete explanation sounds, roughly, like this: "AWS Organizations is the foundation — without an organization with all features active, no SCP has anywhere to attach. SCPs are the policy mechanism that lives inside that organization: ceilings applied to individual accounts or groups of accounts (OUs). AWS Control Tower isn't a third, independent mechanism — it's an automation layer that uses Organizations and SCPs (along with other services like Config) underneath, so creating a new account, already governed by those controls, takes minutes instead of being configured manually every time."

Exercise 3 — Defend, in front of a technical interviewer, why this guide doesn't build multi-account, without sounding like you're avoiding the topic. An interviewer asks you: "why doesn't your portfolio project include Organizations or SCPs, if you clearly know they exist?" Respond using this lesson's criterion.

See solution

A solid answer distinguishes knowledge from applied scope: "I know the mechanism — Organizations as the precondition, SCPs as the account-level policy ceiling, Control Tower as the orchestration layer over both — and I know exactly when it's justified: when a business case needs to separate environments or customers by whole account, not just by role or tag. This portfolio project is a single account, with a single customer and a single operating environment, so building multi-account there would have meant inventing complexity the case didn't call for — the same scope discipline I applied in every earlier module of this project, where every control got built because a concrete risk justified it, documented in a real THREAT-MODEL.md, not because the tool existed." This answer demonstrates engineering judgment, not a knowledge gap.

Summary and next step

In this lesson you named, without building, AWS Organizations (the structure that groups accounts), Service Control Policies (the ceiling mechanism applied to that structure, a larger-scale cousin of lesson 3's permission boundary), and AWS Control Tower (the orchestration layer over both, with its own official preventive/detective/proactive control vocabulary). You confirmed, with VALIDACION.md's exact source, why this is an ecosystem-level gap and not an omission specific to this guide, and with what concrete criterion — environment separation, customer isolation, regulatory requirements — you'd know when Andes Cargo, or any real project, should take this step.

Before moving on you should be able to: explain the dependency relationship between Organizations, SCPs, and Control Tower with no diagram; distinguish, with a concrete example, when a problem gets solved within a single account (as this guide already did) and when it needs multi-account; and defend, against a direct question, why this guide doesn't build what it names here.

Lesson 7 returns to completely executable ground: a real alarm, with terraform validate/plan, on a sensitive IAM event — this module's last new resource before the project that closes it.

Resources

AWS Docs — What is AWS Organizations? — the complete official source cited in this lesson.
AWS Docs — Service control policies (SCPs) — already cited in this module's lesson 2, revisited here for the SCP + permission boundary interaction.
AWS Docs — What Is AWS Control Tower? — the complete official source cited in this lesson, including the preventive/detective/proactive "controls" definition.
src/paths/aws-cloud-ecosystem/VALIDACION.md — the exact source for the HIGH-priority gap with no assigned guide, cited at the start of this lesson.
This course, Module 7, lesson 2 — AppServerRole's permission boundary, the layer an SCP would complement, never replace.

← Previous5. Hands-on: CloudTrail, as far as LocalStack goes Next →7. Hands-on: an alarm on a sensitive IAM event