We begin Part VI: Advanced AWS, focused on the cross-cutting aspects that distinguish a professional: security, observability, and costs. And we start with defense in depth. The first concept is organizational and very powerful: how to manage multiple AWS accounts centrally with AWS Organizations, and how to set up security "guardrails" with Service Control Policies (SCPs).

So far, we've implicitly worked with a single AWS account. That's fine for learning, but real companies soon run into problems if they put everything into one account:

• No isolation: development and production share an account; a testing error can affect production.
• Hard to control costs by team or project (everything is mixed in one bill).
• Complicated permissions: it's hard to separate who can touch what.
• Concentrated risk: if the account is compromised, everything is at risk.

The professional solution is to use multiple accounts (one for production, another for development, another for each team...) and manage them centrally. We'll see the multi-account strategy in depth in Chapter 30; here we look at the basic tool.

AWS Organizations is the service that allows you to create and manage multiple AWS accounts centrally, grouped under an organization. You have a "root" (management) account, and from there you administer all the others.

Main benefits:

• Centralized management of all accounts from one place.
• Consolidated billing: a single bill for the entire organization (and discounts for aggregated volume).
• Centralized security control through SCPs (we'll see this in a moment).

Within an organization, accounts are grouped into Organizational Units (OU), like folders. This allows you to apply rules to groups of accounts in an orderly way:

Analogy: an organization with OUs is like a company with departments. Management (the management account) sets general rules, and each department (OU) groups employees (accounts) to whom certain rules apply. You can give instructions to "the entire production department" at once.

Here's the key security piece. A Service Control Policy (SCP) is a rule that defines the maximum limit of what can be done in an account or OU. They are like security guardrails: they set what is allowed at most, regardless of what individual permissions say.

Important — the difference with IAM: remember IAM (Chapter 7), which grants permissions to users and roles. SCPs are different: they don't grant anything, but set a ceiling. Even if a user has admin IAM permissions, they cannot do something an SCP forbids. The SCP always wins.

Analogy: SCPs are like the laws of a country, and IAM like your work permissions. Your boss can authorize you to do many things (IAM), but no work authorization lets you break the law (SCP). The law sets the absolute limit that no one can cross.

SCPs allow you to impose non-negotiable rules on the entire organization, which no one can bypass, not even an account administrator. Typical examples of security guardrails:

• Restrict regions: "resources can only be created in Europe" (for data regulations, remember sovereignty from subchapter 3.4).
• Protect auditing: "no one can disable CloudTrail or security logs" (so there is always a trace).
• Forbid specific services: "in development accounts, expensive services X or Y cannot be used."
• Prevent dangerous actions: "no one can delete certain critical resources or encryption keys."

A person's real permission is the intersection: they can only do what IAM grants AND what the SCP allows. If either forbids it, they can't do it.

Real-world example: a company with European data protection requirements applies an SCP to the entire organization: "forbidden to create resources outside EU regions." From that moment, it doesn't matter if a developer has admin permissions: if they try to launch a server in the US, AWS will deny it. The compliance rule is technically guaranteed, not just in a written policy that someone could ignore.

SCPs are the outermost layer of your organization's security, the framework within which all others operate (IAM, Security Groups, WAF...). Remember defense in depth from subchapter 16.4: multiple reinforcing layers. SCPs set the maximum limits at the organization level; within them, IAM fine-tunes specific permissions, and other controls protect each resource.

• A single AWS account does not scale for companies (no isolation, mixed costs, concentrated risk); the solution is to use multiple accounts managed centrally.
• AWS Organizations allows you to create and manage multiple accounts centrally, with consolidated billing and grouped into Organizational Units (OU) (like departments).
• Service Control Policies (SCP) are security guardrails that define the maximum limit of what is allowed in an account or OU. Unlike IAM (which grants permissions), SCPs set a ceiling that no one can exceed, not even an administrator.
• Like the laws of a country versus your work permissions: no authorization lets you break the law.
• The real permission is the intersection of IAM and SCP. Typical uses: restrict regions, protect auditing, forbid services or dangerous actions.
• SCPs are the outermost layer of defense in depth at the organization level.

In the next subchapter, we'll see how to ensure your resources continuously comply with the rules using AWS Config.