We close Chapter 30 by bringing together the two major threads of the book: on one hand, Terraform (infrastructure as code, which we mastered in Parts II-V) and, on the other, the multi-account structure we just covered. The natural question is: if we manage all our infrastructure with Terraform, and now we have many accounts, how do we apply Terraform in an orderly way to all that structure? This is where everything you've learned converges into an expert-level practice.

Until now, we've implicitly used Terraform on a single account. But a company with the structure from subchapter 30.1 has dozens of accounts (by environment, team, project). Managing the infrastructure of all of them with Terraform, coherently and without chaos, requires properly applying the techniques you already know. The good news: you already have all the pieces, you just need to combine them at scale.

The beauty of this subchapter is that there's nothing new to learn: it's the culmination of techniques you already master. Let's review them in the multi-account context:

Remember modules (Chapter 18): reusable blocks of infrastructure. In a multi-account environment, they are essential: you define your standard infrastructure (a network, an application...) once as a module, and reuse it in all the accounts that need it. This ensures consistency (all accounts use the same definition) and avoids code duplication.

Remember the importance of state (Chapter 11) and remote backends (Chapter 20). In multi-account, each account (or each account+environment combination) must have its own separate state, just as we separated environments (Chapter 19). This way, managing one account does not affect the others: the isolation of infrastructure as code mirrors the isolation of the accounts.

Remember the techniques for managing multiple environments (Chapter 19): directories per environment, variables per environment (.tfvars), and tools like Terragrunt (subchapter 19.3) to keep code DRY. These same techniques now apply to multiple accounts: each account is, in a way, another "environment" to configure with the same variable patterns and orderly structure.

Remember CI/CD for Terraform (Chapter 22): pipelines that apply changes in a controlled way, with review and plan before apply. At multi-account scale, pipelines deploy to each account automatically and securely, with the appropriate controls (especially strict for production accounts).

The central message: managing Terraform in multi-account does not require new magic, but rather applying with discipline the good practices you already know, at a larger scale. Modules for reuse, separate states for isolation, environment structure for organization, and CI/CD for controlled deployments.

Analogy: managing Terraform in multi-account is like running a restaurant chain with standardized recipes. You don't reinvent the kitchen in each location: you have unique recipes (modules) that each restaurant (account) follows the same way, ensuring the same quality everywhere. Each restaurant has its own cash register and kitchen (separate state), so a problem in one doesn't affect another. You have a common operations manual (environment structure) and a standard process for opening new locations (CI/CD). The secret isn't a new technique, but applying the same good practices with discipline in every location.

Terraform and Control Tower (subchapter 30.2) work together, at different levels:

• Control Tower governs the organizational structure: creates accounts, applies guardrails, sets up the landing zone (the "foundations" and "common rules").
• Terraform deploys the specific infrastructure inside each account: networks, servers, applications (what you "build on top" of the foundations).

They complement each other: one prepares the multi-account ground, the other builds on it reproducibly.

Real-world example: a company with 30 accounts manages all its infrastructure with Terraform by applying the practices it knows. They have a module library (standard network, standard application, standard database) versioned (see subchapter 18.4), which all teams reuse: thus, the network in one team's account is structurally identical to another's, without duplicating code. Each account+environment has its separate state in remote backends (Chapter 20), so deploying to dev-teamA can never affect prod-teamB. They use Terragrunt (subchapter 19.3) to keep everything DRY across accounts, and CI/CD pipelines (Chapter 22) that apply changes with review and prior plan, with extra approvals for production. The result: they manage 30 accounts with the same consistency, security, and control as they would with one, because they applied good practices with discipline at scale. That's expert-level infrastructure as code.

• Managing Terraform across dozens of accounts (multi-account) requires applying with discipline the techniques you already know, not learning new magic. You already have all the pieces.
• The pieces that fit:
  • Modules (Ch. 18): define infrastructure once and reuse it in all accounts → consistency without duplicating code.
  • Separate state per account (Chs. 11, 20): each account with its own state → isolation (changing one doesn't affect another).
  • Environment management (Ch. 19): directories, .tfvars, Terragrunt → orderly organization of many accounts.
  • CI/CD (Ch. 22): pipelines with review and plan → controlled deployments to each account (strict in production).
• Like a restaurant chain with standardized recipes: same recipes (modules), own kitchen per location (separate state), common manual (environments), standard opening process (CI/CD).
• Control Tower (governs the accounts/landing zone) and Terraform (builds the infrastructure inside each account) complement each other at different levels.

You have completed Chapter 30 and mastered multi-account organization and landing zones! In Chapter 31, which closes Part VII, we will look at a very current discipline that takes all this a step further: Platform Engineering and internal developer platforms.