We continue in Part VII with Chapter 30: Multi-Account and Landing Zones, which is about how large companies organize AWS. In subchapter 23.1 we saw AWS Organizations and SCPs, and mentioned that companies use multiple accounts. Now we go deeper: why separate things into different accounts instead of putting everything in one? Understanding this is key to designing the foundation of any serious organization in AWS. The central idea: the AWS account is the best separation unit that exists.

An AWS account is a complete and isolated "container" of resources, with its own billing and its own security limits. Until now, we have implicitly worked within a single account. Large companies, on the other hand, use many coordinated accounts (with AWS Organizations, subchapter 23.1). The question is why.

Imagine a company with several teams, several projects, and the development, testing, and production environments, all in a single AWS account. Serious problems arise:

It's like having an entire company working in a single giant room with no walls: the noise, mess, and risks of some affect everyone. You need to put up "walls." And in AWS, the best "wall" is the account.

The recommended practice for companies is to separate different workloads into different accounts. Each team, project, or important environment goes in its own account. The account is AWS's strongest separation unit, because it offers isolation in three dimensions at once:

Analogy: separating into accounts is like dividing a building into independent apartments instead of an open warehouse. Each apartment has its locked door (a problem in one doesn't enter the others: security), its own electricity meter (each pays their own: costs), and its own facilities (one doesn't use up the other's water: limits). Living in separate apartments is much more orderly and secure than sharing a warehouse with no walls. Accounts are those apartments.

If you separate into accounts, a security problem in one account (a breach, an error, an attack) is contained in that account and does not affect the others. It's the ultimate application of the "blast radius" principle: if something goes wrong, the damage is limited.

This is especially valuable for separating production (the critical stuff) from development/testing (where you experiment and there is more risk). A developer's mistake in their test account should never be able to touch production, and separating accounts guarantees this.

With each workload in its own account, each one’s bill is automatically separated (remember consolidated billing in Organizations, subchapter 23.1: you see the total, but also the breakdown by account). Knowing exactly how much each project or team costs is essential for cost management (remember FinOps, subchapter 25.5). In a single account, separating costs is much harder (you depend only on tags).

AWS imposes certain limits per account (how many resources of a certain type you can create, etc.). If everything is in one account, a project could exhaust those limits and affect the others. With separate accounts, each workload has its own limits and doesn't interfere with the others.

How do companies decide what goes in each account? Common patterns:

These accounts are neatly grouped into Organizational Units (OU) within AWS Organizations (remember subchapter 23.1), and common rules are applied to them with SCP.

Real-world example: a company with three product teams decides on its multi-account structure. Each team gets two accounts: one for development (where they experiment freely) and one for production (with strict controls). In addition, they create a central security account (for the security team) and a logs account (where all logs are centralized). Result: when a developer breaks something in their development account, production doesn't even notice; each team sees exactly what their product costs; and an incident in one team is isolated from the others. The company went from a risky "everything mixed together" to an orderly, secure structure with clear costs. That separation is the foundation for operating at scale.

• Putting everything in a single AWS account doesn't scale: it mixes environments (an error in testing affects production), confuses costs, complicates permissions, concentrates risk, and shares limits. Like a company in a warehouse with no walls.
• The recommended practice is to separate workloads into different accounts (by environment, team, or project). The account is AWS's strongest isolation unit. Like dividing a building into independent apartments.
• Separating into accounts isolates in three dimensions: security (a problem doesn't jump between accounts; the most important), costs (separate bill per account), and limits (each account has its own).
• The most valuable: separating production from development/testing, so that an error or breach in testing can never touch production.
• Accounts are grouped into OUs and governed with SCP (Organizations, subchapter 23.1). Patterns: by environment, team, project, plus special accounts (security, logs).

In the next subchapter, we’ll see how to create and manage all these accounts automatically and with best practices from the start, with AWS Control Tower and landing zones.